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?
Regards,
Rocco
1 Like
Hello @RoccoBr ,
Maybe you could adapt the information contained here to your needs:
Best regards,
Josep
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
Kevin
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:
kernel_image=/boot/ostree/torizon-3e9ae8ff68335bb2f820a9c93a1a26f5eff56b70f1b25730253770709a9c3de2/vmlinuz-5.4.193-5.7.0+git.f78299297185
ramdisk_image=/boot/ostree/torizon-3e9ae8ff68335bb2f820a9c93a1a26f5eff56b70f1b25730253770709a9c3de2/initramfs-5.4.193-5.7.0+git.f78299297185.img
fdtdir=/boot/ostree/torizon-3e9ae8ff68335bb2f820a9c93a1a26f5eff56b70f1b25730253770709a9c3de2/dtb
bootargs=quiet logo.nologo vt.global_cursor_default=0 plymouth.ignore-serial-consoles splash fbcon=map:3 ostree=/ostree/boot.1/torizon/3e9ae8ff68335bb2f820a9c93a1a26f5eff56b70f1b25730253770709a9c3de2/0
**fdtfile=imx8mm-verdin-nonwifi-v1.1-cloudbox_v3.dtb**
kernel_image_type=Image.gz
overlays_file="overlays.txt"
otaroot=1
it comes directly from the tcbuild.yaml file
customization:
device-tree:
include-dirs:
- baseOS/device-trees/include/
- baseOS/device-trees/dts-arm64/
custom: baseOS/device-trees/dts-arm64/imx8mm-verdin-nonwifi-v1.1-cloudbox_v3.dts
overlays:
add:
- baseOS/m4/dt/imx8mm-verdin-cloudbox_v3-rpmsg-overlay.dts
filesystem:
- 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}; \
done;
maybe instead of a for loop, I can load the overlay conditionally , according to the board?
what do you think?
Regards,
Rocco
Hello @RoccoBr ,
That’s also a good approach, maybe more modular and flexible.
Best regards,
Josep
instead of modifying uBoot, what about loading the proper overlay dynamically using configfs?
is it something doable with TorizonCore?