Select different devicetree at startup

I have 3 different version of my custom carrier board which use different GPIO configurations. this means I have three different version of the device tree

the board version is codified in the state for 3 BOARD_ID switch pins.

my questions are:

  1. is it possible to include the three versions of the device tree in TorizonCore?
  2. is it possible to modify uboot behaviour so it can check the state of the BOARD_ID pins and select the appropriate device tree? which changes are required?
    3)is there a better way to select the appropriate device tree?


1 Like

Hello @RoccoBr ,
Maybe you could adapt the information contained here to your needs:

Best regards,

Hi @RoccoBr,

Another way might be as follows:

If you check your u-boot environment you will see that the name of the devicetree file is dynamically generated.

It looks something like this setenv fdtfile ${soc}-${board}${boardver}.dtb

Now one way that I could think of is that you define the variable ${board} depending on your GPIO.

One place where I could imagine you could do that is probably in the boot.scr file. This file is present when you prepare any image for the Toradex Easy Installer. You can also find it on the target in the /boot directory.

There I am sure you could modify it in a way that it would set the device tree according to the GPIOs.

Best Regards

thanks for both answers those are very great starting point for me

I’m using TorizonCore v5.7.0 and I pass my devicetree file to torizoncore-builder through the tcbuild.yaml file

I had a look at the uEnv.txt file in /boot/loader.1 on one of my device and I can see that fdtfile is not generate dynamically:

bootargs=quiet logo.nologo vt.global_cursor_default=0 plymouth.ignore-serial-consoles splash fbcon=map:3 ostree=/ostree/boot.1/torizon/3e9ae8ff68335bb2f820a9c93a1a26f5eff56b70f1b25730253770709a9c3de2/0

it comes directly from the tcbuild.yaml file

      - baseOS/device-trees/include/
      - baseOS/device-trees/dts-arm64/
    custom: baseOS/device-trees/dts-arm64/imx8mm-verdin-nonwifi-v1.1-cloudbox_v3.dts
        - baseOS/m4/dt/imx8mm-verdin-cloudbox_v3-rpmsg-overlay.dts
     - baseOS/changes/

maybe I can have a single devicetree file with all common parts between board revision and different overlays file with the specific configuration for each revision?
I can see in the uEnv.txt:

apply_overlays=fdt addr ${fdt_addr_r} && fdt resize 0x20000 && \
               for overlay_file in ${fdt_overlays}; do \
                   echo "Applying Overlay: ${overlay_file}" && \
                   load ${devtype} ${devnum}:${otaroot} ${loadaddr} /boot${fdtdir}/overlays/${overlay_file} && fdt apply ${loadaddr}; \

maybe instead of a for loop, I can load the overlay conditionally , according to the board?
what do you think?

Hello @RoccoBr ,

That’s also a good approach, maybe more modular and flexible.

Best regards,

instead of modifying uBoot, what about loading the proper overlay dynamically using configfs?
is it something doable with TorizonCore?

Hello @RoccoBr,

Is this issue still blocking you from your development?
I had some internal discussions recently regarding this and would like to share with you the outcome of those:

Disclaimer: This is still an idea, we have not tested it. Probably, the easiest way would be to modify e.g. /usr/lib/ostree-boot/uEnv.txt. If the gpios are already muxed correctly you could use gpio get in U-Boot to read the gpio configuration and then based on that decide what device tree overlays to load. You would just have to modify the load_overlay command:

load_overlay=load ${devtype} ${devnum}:${otaroot} ${loadaddr} /boot${fdtdir}/${overlays_file}; env import -t ${loadaddr} ${filesize}

To something (pseudocode) like this:

load_overlay=if configuration0; then overlays_file=overlays1.txt; elif configuration1; then overlays_file=overlays2.txt; else overlays_file=overlays3.txt; fi; load ${devtype} ${devnum}:${otaroot} ${loadaddr} /boot${fdtdir}/${overlays_file}; env import -t ${loadaddr} ${filesize}

This exact code will not work but it should be possible to find a mechanism to decide which overlays to load based on the gpio configuration. However, this would also mean that if you modify the uEnv.txt file, you will have to think about the maintenance burdens. Also, we need to clarify on our side how we would maintain this file on Torizon OS.

As a point of reference, we ended up doing something similar but in our case we managed it as outlined in this thread - rather than changing the uboot environment I elected to make a script that manages overlays.txt on the fly by appending a variant-specific DTBO file, which is fully achievable within the current confines of TorizonCore builder.

But I would be very interested in an official mechanism to support this sort of dynamic hardware configuration if it becomes available, be it via either run-time selection of a particular full DTS file or just dynamic selection of any additional overlay(s) to apply. The base mechanics are already in place as done using the toradex config block logic to do carrier board/SoM variant detection; enabling the HW developer to extend this with additional definitions might be a very nice/clean way to do this.

1 Like