Hello,
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:
is it possible to include the three versions of the device tree in TorizonCore?
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?
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.
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:
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:
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.