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?
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.
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.
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:
carrier_serial#=10866136
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:
@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?
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.
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:
set the fdt_board variable to the name of the carrier board you’re using, saveenv and reset
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.
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.
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.
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.
