Need help with editing the device-tree for a AD7606-8 device


I am working on my first yocto and toradex project.
For that I use the Colibri Evaluation V3 Board and bitbake.

I have to add a AD7606-8 device and overwrite the gpios for the device.
Therefore I need to make changes to the device-tree.
I made changes to the colibri-eval-e3.dtsi files in /build/tmp/work-shared/colibri-imx6ull/kernel-source/arc/arm/boot/dts but with no impact. I also added a new file and included it in the makefile what either had not effect.
I don’t find other folders with dts files that I could change. I also don’t have an /opt folder on the target system, where I could test editing the dts files.

Maybe someone can help me and tell me where I have to look for the correct dts files to change?

Hello @doelken ,
I think you are making the changes in the wrong place. The changes should be made in the “layers” folder, not in the “build” folder.
Also you can see from the path (/build/tmp) that these are temporary folders.
Here you can find more information about this topic:[…]ernel

Best regards,

Thanks for the response.
I’m still having problems finding a solution, although I followed several guides from Toradex.

I followed every step here, created a layer and a recipe, also an image, but my device-tree changes have no impact and are nowhere to be found in the created image.

I also followed this guides, compiled my own device-tree-overlay, copied it onto my device, created a /boot/overlays folder and a overlays.txt with: “fdt_overlays=my_overlay.dtbo”, set the env variables in u-boot (overlays_file, fdt_overlays, overlays_prefix), still no effect.

To simplify it, I just want to deactivate some device (like i2c-1) to see that my overlay has any impact.
In most tutorials i found, there always is a /opt-folder and an /boot/overlays-folder. I do not have that folders and I don’t know how to get those, so…

  1. How can I deactivate f.e. i2c-1 with an overlay, that I compile, copy onto my device and set the env variables in u-boot?
  2. Why is the /boot/overlays folder and the overlays.txt not created automatically? What do I have to do for that?

Maybe my overwrite is totally wrong? (at least it compiles without problems - if I implement an error, the compiler instantly reports that it is unable to parse the input tree - as it should)

/ {
compatible = “toradex, colibri-imx6ull-emmc”;

&i2c1 {
status = “disabled”;

Hi @doelken !

To add a device tree overlay to your Yocto build, the Device Tree Overlays (Linux) | Toradex Developer Center article has the section Production: Add Your Overlays to a Custom Yocto Project Build that might help you on this.

You shouldn’t have to create the /boot/overlays folder if you use the default machine configurations from Toradex (the default MACHINE=colibri-imx6ull-emmc, in your case).

Your overlay is actually correct:


/ {
    compatible = “toradex, colibri-imx6ull-emmc”;

&i2c1 {
    status = “disabled”;

It should be created during your Yocto build.

Could you please share more information on your Yocto build configuration?

Best regards,

I will have another look into that section.

Already found one error, I had to use “colibri-imx6ull” instead of “colibri-imx6ull-emmc” in my overlay, but that did not fix the problem.

Yes the layers were downloaded according to the guide.

bsp: 5.7.0
distro: tdx-xwayland
machine: colibri-imx6ull
image: tdx-reference-minimal-image

Another question: can I somehow check, if the overlay was included in the image without having to copy it to the board? (like there has to be my overlay-file or the overlays.txt somewhere in the image?)

Hi @doelken !

If you are using Colibri iMX6ULL 1GB, which has eMMC, please keep using “colibri-imx6ull-emmc”. Otherwise, keep the change to “colibri-imx6ull” .

If you are using a Colibri iMX6ULL 1GB, please use the machine colibri-imx6ull-emmc instead of colibri-imx6ull.

Best regards,

imx6ull is correct as I am using the 512MB version

Can you tell me how I can notice, if my overlay is included in the image tar file? Should there be my overlay file or a overlays.txt, sth like that?

Hi @doelken ,

Thanks again for the interesting call today.

So the reality is the following. In the article here:

Overlays are not supported on NAND modules.

So what remains is to create a custom device tree: (the following link was already shared by you)

In this article you can see on how to create the bbappend file that would include the custom device tree:

A bit further down the article there’s also an example of a custom device tree:

In our call I talked about the different levels of device tree (SoC level, SoM level and carrier board). If you include the board level device tree in the beginning of the custom device tree, the module should boot as expected.

There you can add the changes that you want to apply to the device tree and then rebuild.

You can try to follow these steps and then if you want we can arrange another call, where we can look at it together in case it wont work.

Another question we talked about was the location of the uncompiled device tree files. You should be able to find them here:

Let me know if you have questions about any of it.

Best Regards

Thanks for the reply,

another call would be helpful, as I already tried to follow this article.

Maybe the problem is with the defconfig, as I don’t know which is the correct one to use. I tried to go with unsetting KBUILD_DEFCONFIG or using no defconfig at all in my bbappend, but that did not help.

I also tried to make changes to files in /build/tmp/work-shared/colibri-imx6ull/kernel-source/arch/arm/boot/dts in order to get my changes into the image, but as those files a temporary, that had no effect.

Hi @doelken ,

Hope you had a good weekend.

After our call on Friday, we noticed something that we wanted to add.

It occurs that to make this setup work (after removing the _append from the KERNEL_DEVICETREE variable) there is another change needed successfully make it work.

The change would be done in your custom .conf file that we looked at together.

This would be the change (my-custom.dtb is a placeholder for your specific filename):

KERNEL_DEVICETREE = "my-custom.dtb"
TORADEX_PRODUCT_IDS[XXXX] = "my-custom.dtb"

The first line should already be present (as mentioned before). The second line is responsible to tell the Toradex Easy Installer, which device tree file will be stored to the specific address (we briefly looked at this during the meeting) for a specific PID4 (Product ID) . In the codeline above you can see XXXX, which should then be replaced with your product’s PID4.

Even if you are only using one specific PID4 right now, you can add additional lines with different PID4s and other custom device tree files to be ready in case you use other products in the future.

If you add all PID4s that are currently available for Colibri iMX6ULL with Raw-Nand memory, it might look something like this:

KERNEL_DEVICETREE = "my-custom.dtb"
TORADEX_PRODUCT_IDS[0036] = "my-custom1.dtb"
TORADEX_PRODUCT_IDS[0040] = "my-custom2.dtb"
TORADEX_PRODUCT_IDS[0044] = "my-custom3.dtb"
TORADEX_PRODUCT_IDS[0045] = "my-custom4.dtb"

Best Regards

Hello Kevin,

this did work.

Thank you

Hi @doelken ,

Great to hear!
Thanks for letting us know.

Best Regards

Hello, I hope you can help me one more time with this issue.

I’m able to handle the device tree now, but still having problems to integrate the ad7606.

I have activated the drivers for ad7606 analog devices and tried different approaches in my dts like changing the node / child node name (f.e. ad7606-8@0, adc3: adc@ad7606-8) or unit address. But the adc just does not appear in my devices (adc 1 (2198000) is already present). I checked that the gpios are not used by another device and also tried just to only set status = “okay” with no other properties.

My current dts:


#include "imx6ull-colibri-wifi.dtsi"
#include "imx6ull-colibri-eval-v3.dtsi"
#include <dt-bindings/gpio/gpio.h>

/ {
	model = "Toradex Colibri iMX6ULL 512MB";
	compatible = "toradex,colibri-imx6ull", "fsl,imx6ull";

&ecspi1 {
	status = "okay";

	adc3: adc@0 {
		status = "okay";
		compatible = "adi,ad7606-8";
		reg = <0>;
		spi-max-frequency = <1000000>;
		label = "ad7606";
		interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
		interrupt-parent = <&gpio4>;
		adi,conversion-start-gpios = <&gpio1 26 GPIO_ACTIVE_HIGH>;
		reset-gpios = <&gpio2 7 GPIO_ACTIVE_HIGH>;
		adi,first-data-gpios = <&gpio5 4 GPIO_ACTIVE_HIGH>;
		adi,oversampling-ratio-gpios = <&gpio2 2 GPIO_ACTIVE_HIGH
			&gpio5 1 GPIO_ACTIVE_HIGH
			&gpio2 0 GPIO_ACTIVE_HIGH>;
		standby-gpios = <&gpio2 1 GPIO_ACTIVE_LOW>;

Hi @doelken !

Sure :slight_smile:

By default, Toradex’s device trees enable the spidev for SPI interfaces on the modules. Colibri iMX6ULL also has this. This spidev helps to make it easier evaluation and tests with SPI interface.

Using find_in_dt is easy to see this:

[ 11:47 ]  [ ~/linux-toradex(toradex_5.4-2.3.x-imx✔) ] 
 $ find-in-dt arch/arm/boot/dts/imx6ull-colibri-eval-v3.dts ecspi1 spidev "reg = <0>"
search_in: all, returning: all
searching in:


        99 : &ecspi1 {
        102 :   pinctrl-0 = <&pinctrl_ecspi1 &pinctrl_ecspi1_cs>;
        104 :   spidev0: spidev@0 {
        106 :           reg = <0>;
        356 :           pinctrl_ecspi1_cs: ecspi1-cs-grp {
        362 :           pinctrl_ecspi1: ecspi1-grp {
        364 :                           MX6UL_PAD_LCD_DATA20__ECSPI1_SCLK       0x000a0 /* SODIMM 88 */
        365 :                           MX6UL_PAD_LCD_DATA22__ECSPI1_MOSI       0x000a0 /* SODIMM 92 */
        366 :                           MX6UL_PAD_LCD_DATA23__ECSPI1_MISO       0x100a0 /* SODIMM 90 */

        46 :            spi0 = &ecspi1;

As we can see above, by default, this spidev has reg = <0>, which collides with your adc3 node.

So, disabling spidev node is needed. You can add this to your device tree/device tree overlay outside of any node:

&spidev {
    status = "disabled";

Let us know if this solves your issue.

Best regards,

Thanks for the response, I also saw that and this was indeed one of the problems. The other was a conflicting gpio.
Now I finally have my adc :slight_smile:


Thanks for the update, @doelken!

Best regards,