Adding Device Tree to EEPROM config file.

[orchardaudio]

Hello,

I have read this post here: viewtopic.php?f=29&t=108134#p744050

I am still not sure how to combine the device tree into the eeprom file. I need to add I2S sound functionality. Is there a more detailed write up that I can read somewhere? Can somebody here give me some additional steps that are required.

Thanks;
Leo

[PhilE]

That's about the most user friendly documentation there is. The steps are:
1. Create/locate overlay as a .dts file.
2. Compile .dts file into a .dtbo file (but the actual filename doesn't matter here, so the guide isn't wrong).
3. Pass the .dtbo file name to the eepmake script.

At which step do you get lost?

[orchardaudio]

That's about the most user friendly documentation there is. The steps are:
1. Create/locate overlay as a .dts file.
2. Compile .dts file into a .dtbo file (but the actual filename doesn't matter here, so the guide isn't wrong).
3. Pass the .dtbo file name to the eepmake script.

At which step do you get lost?

I have no issue with that portion of it. What I am missing is how to create the overlay itself.

[PhilE]

Most people use one or more of the existing overlays in the kernel tree (source here) as a starting point. The complexity of the overlay, and whether or not you need a driver, very much depends on your hardware.

Something else you need to know is that it is now possible to put the name of an overlay into the EEPROM - which then works like an automatic "dtoverlay=<overlay-name>" directive. This makes it easier to change an overlay after release but does depend on you getting the overlay included in the raspberrypi/linux tree in the first place.

[orchardaudio]

Most people use one or more of the existing overlays in the kernel tree (source here) as a starting point. The complexity of the overlay, and whether or not you need a driver, very much depends on your hardware.

Something else you need to know is that it is now possible to put the name of an overlay into the EEPROM - which then works like an automatic "dtoverlay=<overlay-name>" directive. This makes it easier to change an overlay after release but does depend on you getting the overlay included in the raspberrypi/linux tree in the first place.

How do you go about adding an overlay to the rpi/linux tree?

Also if I compile one of the existing overlays into the eeprom config. Does that mean that overlay will not require a line in the /boot/config.txt.

[PhilE]

How do you go about adding an overlay to the rpi/linux tree?

You can create a Pull Request, or an Issue if that's easier.

Also if I compile one of the existing overlays into the eeprom config. Does that mean that overlay will not require a line in the /boot/config.txt.

Yes - that's the main reason for the built-in overlay - all you have to do is plug in the HAT and the necessary kernel modules are loaded automatically.

[orchardaudio]

Yes - that's the main reason for the built-in overlay - all you have to do is plug in the HAT and the necessary kernel modules are loaded automatically.

Ok, does this occur even if the overlay is not built into the rpi/Linux device tree?

[PhilE]

Yes, if the overlay content is programmed into the EEPROM, but not if only the name is. However, any modules required by the overlay will need to be part of the standard RPi firmware distributions.

Don't think of getting an overlay into the kernel as problematic - essentially, you ask through one of the channels mentioned above and, provided it is correctly written and documented, I'll approve it (and if it isn't I'll help you get there). Additional module support - especially adding a custom driver - is harder but still nothing to be daunted by.

[orchardaudio]

I found this overlay in another forum:

Code: Select all

/dts-v1/;
/plugin/;

/ {
    compatible = "brcm,bcm2708";

    [email protected] {
        target = <&sound>;
        __overlay__ {
            compatible = "simple-audio-card";
            simple-audio-card,name = "Dual";

            status="okay";

            capture_link: simple-audio-card,[email protected] {
                format = "i2s";

                r_cpu_dai: cpu {
                    sound-dai = <&i2s>;

/* example TDM slot configuration
                    dai-tdm-slot-num = <2>;
                    dai-tdm-slot-width = <32>;
*/
                };

                r_codec_dai: codec {
                    sound-dai = <&codec_in>;
                };
            };

            playback_link: simple-audio-card,[email protected] {
                format = "i2s";

                p_cpu_dai: cpu {
                    sound-dai = <&i2s>;

/* example TDM slot configuration
                    dai-tdm-slot-num = <2>;
                    dai-tdm-slot-width = <32>;
*/
                };

                p_codec_dai: codec {
                    sound-dai = <&codec_out>;
                };
            };
        };
    };

    [email protected] {
        target-path = "/";
        __overlay__ {
            codec_out: spdif-transmitter {
                #address-cells = <0>;
                #size-cells = <0>;
                #sound-dai-cells = <0>;
                compatible = "linux,spdif-dit";
                status = "okay";
            };
            codec_in: spdif-receiver {
                #address-cells = <0>;
                #size-cells = <0>;
                #sound-dai-cells = <0>;
                compatible = "linux,spdif-dir";
                status = "okay";
            };
        };
    };

    [email protected] {
        target = <&i2s>;
        __overlay__ {
            #sound-dai-cells = <0>;
            status = "okay";
        };
    };
};

/* compile with:
   dtc [email protected] -H epapr -O dtb -o dual.dtbo -Wno-unit_address_vs_reg dual.dts
*/

I only need and I2S output device so do I just delete the input device portions to make it look like this:

Code: Select all

/dts-v1/;
/plugin/;

/ {
    compatible = "brcm,bcm2708";

    [email protected] {
        target = <&sound>;
        __overlay__ {
            compatible = "simple-audio-card";
            simple-audio-card,name = "I2S_DAC";

            status="okay";

            playback_link: simple-audio-card,[email protected] {
                format = "i2s";

                p_cpu_dai: cpu {
                    sound-dai = <&i2s>;
                    dai-tdm-slot-num = <2>;
                    dai-tdm-slot-width = <32>;
                };

                p_codec_dai: codec {
                    sound-dai = <&codec_out>;
                };
            };
        };
    };

    [email protected] {
        target-path = "/";
        __overlay__ {
            codec_out: spdif-transmitter {
                #address-cells = <0>;
                #size-cells = <0>;
                #sound-dai-cells = <0>;
                compatible = "linux,spdif-dit";
                status = "okay";
            };
        };
    };

    [email protected] {
        target = <&i2s>;
        __overlay__ {
            #sound-dai-cells = <0>;
            status = "okay";
        };
    };
};

/* compile with:
   dtc [email protected] -H epapr -O dtb -o dual.dtbo -Wno-unit_address_vs_reg dual.dts
*/

[PhilE]

If your DAC has no (I2C) control interface and just adapts to the I2S clocks and data stream then that overlay should be fine. Try it from config.txt and if it works there it should wqrk in the EEPROM.

[orchardaudio]

I was able to compile the overlay and add it to the eep file loaded onto the eeeprom.

I do have some additional questions though.

Per my understanding the two lines of code below from the overlay set the BCLK to be 64 x of WCLK. This is exactly what I need.

Code: Select all

dai-tdm-slot-num = <2>;
dai-tdm-slot-width = <32>;

The question however comes to how to configure the bit depth 16-bit vs 24-bit or is this automatically determined based on the content that is being played?

Is there a way to configure 24-bit no matter what?

[HiassofT]

The available sample formats (plus numbers of channels and samplerates) are determined from what both the CPU dai (bcm2835-i2s) and the codec (in your case the spdif transmitter "codec" spdif-dit) support.

The intersection of the capabilities then leads to 2 channels, 16 or 24 bit and the standard 8kHz-192kHz rates.

This means you can play eg CD audio files (44.1kHz, 16bit, stereo) directly, without any needed software conversion.

The TDM parameters determine the physical format of the transmitted I2S data:

If you don't specify these 16bit data will be transmitted using 16bits per sample (32x fs) and 24bit data using 24bits per sample (48x fs).

If you configure a TDM slot width of 32 it means both 16bit and 24bit data will be automatically padded up to 32bits per sample (64x fs) - usually by adding zero bits.

Although you could limit the available formats to 24-bit only (either via a soundcard driver, or by using a different codec, or via an .asoundrc using a fixed configuration) this is not a good idea. If you then want to play eg a CD audio file the CPU has to convert the 16bit data to 24bit (usually also by adding zero bits), something you otherwise get "for free" from the bcm2835 I2S hardware.

so long,

Hias

[orchardaudio]

If you configure a TDM slot width of 32 it means both 16bit and 24bit data will be automatically padded up to 32bits per sample (64x fs) - usually by adding zero bits.

This is exactly what I was looking for, I believe that is achieved with:

Code: Select all

dai-tdm-slot-num = <2>;
dai-tdm-slot-width = <32>;

The last question is can the sampling frequency be locked in? For example 96kHz or is it determined by the type of file being played?

[HiassofT]

Handling of sample rates is the same as for sample formats: the default (plughw) PCM will choose the best match available from the hardware (hw PCM), if there's no exact match it'll do software conversion - which usually isn't too great in case it needs to resample - also this needs a bit of CPU power.

Software that accesses the hw PCM directly typically has to do the same steps - check if the hardware supports a given format and if no match is found either abort with an error or automatically convert to a suitable format.

You can lock the config via an .asoundrc (that eg only uses a fixed samplerate on the hardware and resamples all other rates) or via the soundcard driver (not possible with the simple-card overlay) or codec driver.

In general the codec driver already sets up the correct constraints so only formats/rates supported by a specific codec will be made available.

If you have a special setup, eg can't support rates below 32kHz because you want to hook up a S/PDIF transceiver, you can further limit available configurations by adding constraints to the soundcard (machine) driver.

This configuration scheme ensures that only formats/rates supported by the hardware will be made available to applications. Applications can then choose among these and use the setup they prefer (eg decide themselves if they want to output 44.1kHz directly or resample everything to 96kHz).

so long,

Hias

[orchardaudio]

You can lock the config via an .asoundrc (that eg only uses a fixed samplerate on the hardware and resamples all other rates) or via the soundcard driver (not possible with the simple-card overlay) or codec driver.

Could you please show the steps that are required to setup the .asoundrc for limiting to samples rates above 32kHz.

If it is at all possible to do in the overlay I would prefer that, but I am not familiar enough with the overlays to be able to modify that either.

[HiassofT]

I don't think that's possible via .asoundrc. I'm only aware of the rate alsa plugin which allows you to use a fixed rate.

The only thing you can do in the simple-card overlay is to use a different codec driver which comes with the correct constraints.- but I'm also not aware of any "generic" driver that does that.

Alternative is to write either a codec driver or a soundcard driver and setup the correct constraints there.

so long,

Hias

[orchardaudio]

I don't think that's possible via .asoundrc. I'm only aware of the rate alsa plugin which allows you to use a fixed rate.

The only thing you can do in the simple-card overlay is to use a different codec driver which comes with the correct constraints.- but I'm also not aware of any "generic" driver that does that.

Alternative is to write either a codec driver or a soundcard driver and setup the correct constraints there.

so long,

Hias

After doing some digging I see that there is a codec driver for the PCM1794A which is the chip that I am using in my design, but I do not know how to modify the overlay to include this codec instead of the simple-card one.

Please walk me though it.

[PhilE]

Have a look at this simple-card-based overlay. The compatible string you need for the codec is "ti,pcm1794a", as used in the rpi-dac overlay which may also help.

[orchardaudio]

I still do not understand, I am not a software person. I am trying to decipher it.

Code: Select all

/*
Do I just replace every line that says comapatible = ??? with compatible = "ti,pcm1794a";

To get the following:
*/

/dts-v1/;
/plugin/;

/ {
    compatible = "brcm,bcm2708";

    [email protected] {
        target = <&sound>;
        __overlay__ {
            compatible = "ti,pcm1794a";
            simple-audio-card,name = "I2S_DAC";

            status="okay";

            playback_link: simple-audio-card,[email protected] {
                format = "i2s";

                p_cpu_dai: cpu {
                    sound-dai = <&i2s>;
                    dai-tdm-slot-num = <2>;
                    dai-tdm-slot-width = <32>;
                };

                p_codec_dai: codec {
                    sound-dai = <&codec_out>;
                };
            };
        };
    };

    [email protected] {
        target-path = "/";
        __overlay__ {
            codec_out: spdif-transmitter {
                compatible = "ti,pcm1794a";
                status = "okay";
            };
        };
    };

    [email protected] {
        target = <&i2s>;
        __overlay__ {
            #sound-dai-cells = <0>;
            status = "okay";
        };
    };
};

[HiassofT]

I think you might also need #sound-dai-cells = <0>; like in the rpi-dac overlay https://github.com/raspberrypi/linux/bl ... ts#L15-L24

Plus better change the name of the node. eg:

Code: Select all

    [email protected] {
        target-path = "/";
        __overlay__ {
            codec_out: pcm1794a-codec {
                #sound-dai-cells = <0>;
                compatible = "ti,pcm1794a";
                status = "okay";
            };
        };
    };

so long,

Hias

[PhilE]

Something like this:

Code: Select all

/dts-v1/;
/plugin/;

/ {
    compatible = "brcm,bcm2708";

    [email protected] {
        target = <&sound>;
        __overlay__ {
            compatible = "simple-audio-card";
            simple-audio-card,name = "I2S_DAC";

            status="okay";

            playback_link: simple-audio-card,[email protected] {
                format = "i2s";

                p_cpu_dai: cpu {
                    sound-dai = <&i2s>;
                    dai-tdm-slot-num = <2>;
                    dai-tdm-slot-width = <32>;
                };

                p_codec_dai: codec {
                    sound-dai = <&codec_out>;
                };
            };
        };
    };

    [email protected] {
        target-path = "/";
        __overlay__ {
            codec_out: pcm1794a-codec {
                #sound-dai-cells = <0>;
                compatible = "ti,pcm1794a";
                status = "okay";
            };
        };
    };

    [email protected] {
        target = <&i2s>;
        __overlay__ {
            #sound-dai-cells = <0>;
            status = "okay";
        };
    };
};

/* compile with:
   dtc [email protected] -H epapr -O dtb -o dual.dtbo -Wno-unit_address_vs_reg dual.dts
*/

[orchardaudio]

I think you might also need #sound-dai-cells = <0>; like in the rpi-dac overlay https://github.com/raspberrypi/linux/bl ... ts#L15-L24

Plus better change the name of the node. eg:

Code: Select all

    [email protected] {
        target-path = "/";
        __overlay__ {
            codec_out: pcm1794a-codec {
                #sound-dai-cells = <0>;
                compatible = "ti,pcm1794a";
                status = "okay";
            };
        };
    };

so long,

Hias

Something like this:

Code: Select all

/dts-v1/;
/plugin/;

/ {
    compatible = "brcm,bcm2708";

    [email protected] {
        target = <&sound>;
        __overlay__ {
            compatible = "simple-audio-card";
            simple-audio-card,name = "I2S_DAC";

            status="okay";

            playback_link: simple-audio-card,[email protected] {
                format = "i2s";

                p_cpu_dai: cpu {
                    sound-dai = <&i2s>;
                    dai-tdm-slot-num = <2>;
                    dai-tdm-slot-width = <32>;
                };

                p_codec_dai: codec {
                    sound-dai = <&codec_out>;
                };
            };
        };
    };

    [email protected] {
        target-path = "/";
        __overlay__ {
            codec_out: pcm1794a-codec {
                #sound-dai-cells = <0>;
                compatible = "ti,pcm1794a";
                status = "okay";
            };
        };
    };

    [email protected] {
        target = <&i2s>;
        __overlay__ {
            #sound-dai-cells = <0>;
            status = "okay";
        };
    };
};

/* compile with:
   dtc [email protected] -H epapr -O dtb -o dual.dtbo -Wno-unit_address_vs_reg dual.dts
*/

Thank you, I will be trying this out.

[orchardaudio]

Don't think of getting an overlay into the kernel as problematic - essentially, you ask through one of the channels mentioned above and, provided it is correctly written and documented, I'll approve it (and if it isn't I'll help you get there). Additional module support - especially adding a custom driver - is harder but still nothing to be daunted by.

Is there an instruction somewhere to add the overlay to the kernel? I got an overlay working.

What would I need to do?

[PhilE]

Create a pull request here: https://github.com/raspberrypi/linux/pulls

If you search the closed PRs you will find other overlays being added. If that seems too complicated, create an issue instead, including the overlay content and a description for the overlay README.

[orchardaudio]

Create a pull request here: https://github.com/raspberrypi/linux/pulls

If you search the closed PRs you will find other overlays being added. If that seems too complicated, create an issue instead, including the overlay content and a description for the overlay README.

I have created an issue here: https://github.com/raspberrypi/linux/issues/2302

I could not figure out how to do a pull request.

Let me know if I need to do anything else.