How automatic dtb selection works?


We have a Verdin Development board and a Dahlia board and using them with Verdin iMX8M-Plus module and tdx-reference-multimedia-image for our evaluations.

I have noticed that when I insert the SoM module to the development board, it boots by using imx8mp-verdin-wifi-dev.dtb.

But the same SoM module with the same image, when I plug it into Dahlia board, it automatically boots using imx8mp-verdin-wifi-dahlia.dtb.

We recently designed a custom carrier board from scratch, not yet received but I wonder that how it will be recognized by the same image? Can you briefly explain the mechanism behind? Are there some GPIOs responsible to select the carrier board?

Thank you.

I went down this road with the wifi and non-wifi versions of the 6ULL SOMs. There are some uboot environment variables that were used for detection. You might display all of your uboot variables on both boards and compare.

1 Like

Hello @Fide,
The two mentioned verdin carrier boards contain an eeprom that holds carrier board identification information.
You can check more details about how this information is read here:

For your custom carrier board you’ll probably not have the eeprom and will need to setup the u-boot environment variables to load the proper device tree according to your needs.

Best Regards,
Rafael Beims

1 Like

Nice trick, thank you.

Hello @Fide, I checked my response internaly and figured out it’s not completely right. Here’s the correct answer:
The verdin modules are able to read some information from our carrier boards eeprom, and because of that they are able to print this message in u-boot:

Carrier: Toradex Verdin Development Board V1.1B, Serial# 10866136

We also set environment variables like this:


However, this detection and the variables have no influence on the boot process and also don’t influence the device tree file selection. For that we still rely on the usual environment variables:

preboot=setenv fdtfile imx8mm-verdin-${variant}-${fdt_board}.dtb

Sorry for the confusion on my part!
Best regards,
Rafael Beims

@rafael.tx I’ve been wondering exactly the same thing as @Fide. Your answer is helpful, but with your correction, the question still is not answered: If the carrier board EEPROM is not used to decide the FDT file, then what does? You say it is the fdtfile env var, but how does that var change the boot process? Or does the carrier board EEPROM contain a u-boot env var block maybe?

Hello @matthijs,
You can see from my response that the fdtfile variable is being set under the preboot environment variable. preboot is a variable that has special meaning in u-boot and is evaluated after u-boot finished initializing and is ready to start the cli (under the main_loop() function):

        if (IS_ENABLED(CONFIG_USE_PREBOOT))                                                                                                 

On our current configs, we’re setting this variable like this (as an example this one):

CONFIG_PREBOOT="test -n ${fdtfile} || setenv fdtfile imx8mp-verdin-${variant}-${fdt_board}.dtb"

The fdt_board variable comes with a default value from u-boot config as well (here).
The variant is the only one that has special treatment. We use the toradex config block (also located on the eMMC, still nothing to do with the EEPROM) to detect if the module has wifi or not:

To summarize how it will behave:

  1. if the u-boot variable fdtfile was not saved as part of your environment (by typing saveenv), it will be set when u-boot finishes initializing using the variables variant and fdt_board.
  2. if the u-boot variable fdtfile was saved as part of your environment then it will not be touched

Based on this, you have two ways to influence the name of the device tree file that will be loaded:

  1. set the fdt_board variable to the name of the carrier board you’re using, saveenv and reset
  2. set the fdtfile variable with the full name of the device tree file you want to load, which will be located by default on the /boot partition of your rootfs. In this case you also need to saveenv and reset before the changes will be activated.

Hopefully this clarifies your questions,

Thanks for your detailed reply!

If I understand what you’re saying correctly, that would mean that the carrier board (e.g. dev vs dahlia) is something that must be configured manually (e.g. by setting fdt_board in the udev environment, or by setting fdtfile)? That would make sense, except that I could not find any documentation at all that mentions this is needed and how this is done. Also, in the first post in this thread, @Fide said:

Which is (AFAICS) not consistent with what you are describing.

Does this mean that the behavior that @Fide describes does not exist? Or is there some additional mechanism involved? Note that I have not tested this behavior myself, but I do recall that I never had to explicitly configure dev board vs dahlia in our test setups.

Hello @matthijs,

Does this mean that the behavior that @Fide describes does not exist? Or is there some additional mechanism involved?

I believe the automatic selection of fdtfile was something that worked in older versions of u-boot. Currently this is implemented in the way that @rafael.tx described previously. If you need to change this variable, you will have to do so by manually modifying the uboot environment variables.

This is also described on this article with some examples: U-Boot | Toradex Developer Center

Note that I have not tested this behavior myself, but I do recall that I never had to explicitly configure dev board vs dahlia in our test setups.

For most of the usual use-cases, you don’t have to change the fdtfile or fdt_board variable in the uboot as almost everything defined for dev board should also work with dahlia. This might be the reason that you never noticed it.

1 Like