Hello
I’m currently facing the challenge of integrating a new hardware revision into an existing Torizon system. Basically the device-tree will be a bit different.
I wanted to ask if there is a recommended way of having two device-trees for two very similar boards.
I imagined to deploy two device-trees and then letting the application decide which is needed do some settings and rebooting into the right one. However torizoncore-builder dt apply is only deploying one dt 
Thanks in advance for your suggestions.
Philippe
Greetings @philschenker,
Just to make sure I understand correctly. You basically want to create a custom Torizon image that contains 2 distinct device tree binaries, is that correct?
I did some experimenting and there is a way to do this. As usual start with a standard Torizon OS base image and add one of your device trees. From this point create a new custom image. Then use this new custom image as your new base image for TorizonCore Builder. From here you can add your second device tree. The resulting custom image should now container both your custom device trees.
You can see from my own test I was able to add foo.dtb and bar.dtb to my system:
torizon@verdin-imx8mp-06849059:~$ ls /boot/ostree/torizon-9244e2e3212dfaf5ecad7bb1e8176db61fd7aeae8bd2b7afcfcf5471370d3a52/dtb/
bar.dtb imx8mp-verdin-nonwifi-dev.dtb imx8mp-verdin-wifi-dahlia.dtb imx8mp-verdin-wifi-yavia.dtb
foo.dtb imx8mp-verdin-nonwifi-mallow.dtb imx8mp-verdin-wifi-dev.dtb overlays/
imx8mp-verdin-nonwifi-dahlia.dtb imx8mp-verdin-nonwifi-yavia.dtb imx8mp-verdin-wifi-mallow.dtb overlays.txt
In summary:
images unpack base Torizon OS imagesdt apply first device tree- Create new custom image
images unpack on this custom imagedt apply second device tree- Create final custom image that should have both device trees.
Now as for your overall use-case, I have some questions. You will be releasing a new hardware revision for your product that requires some device tree changes. You stated the two revisions will be “very similar boards”. Would it be possible to do the device tree changes via device tree overlays, rather than full device trees?
In this way you could have a base device tree for all revisions, then depending on the detected hardware revision you load different device tree overlays to make the necessary device tree changes for that revision. Or would this not work for your architecture you think?
Best Regards,
Jeremias
Hi Jeremias,
Thank you for this perfect answer. Yes, we want to have one Torizon image that should fit for multiple hw-revisions.
We decided to go with overlays for now and hope they will work. If we deploy two overlays one for each hw-rev it’s not really feasible to have them activated by default (like torizoncore-builder does).
I came up with that docker snippet to remove all overlays from autoloading before executing torizoncore-builder union command.
docker run --rm -v ${DOCKER_VOLUME_NAME}:/mnt alpine sh -c 'sed -i "s/fdt_overlays=.*/fdt_overlays=/" /mnt/dt/usr/lib/modules/*/dtb/overlays.txt'
What do you think, is that too hacky? Or is there even another way that I overlooked maybe?
Thanks in advance and have a nice weekend!
Philippe
What do you think, is that too hacky? Or is there even another way that I overlooked maybe?
I see, so you want to add multiple overlays to your image, but don’t want them enabled by default. This is because you’ll have some special logic to your system that will pick and choose which overlay to enable depending on the hardware revision that is being used. Is that correct?
Yeah I suppose this isn’t something that was considered in the design of TorizonCore Builder originally. We assumed if a user was applying a new overlay to the custom image that they would want it to be autoloaded by default.
That said, I did some more experimenting and I found a way around this. It actually works similar to the process from before:
images unpack base Torizon OS imagedto apply your overlaysunion to create an intermediate custom image images unpack this intermediate imagedto remove --all to prevent any overlays from being autoloaded on bootunion to create a final custom image that containts your overlays but nothing will be autoloaded.
I tried this and got the following result, my test overlay was deployed to the image:
ls /boot/ostree/torizon-9997489fbeb8fab53d45ebbbedf900f70e19473d304316dd7bdd49cba12d2df9/dtb/overlays/
test.dtbo verdin-imx8mp_hdmi_overlay.dtbo verdin-imx8mp_mezzanine_panel-cap-touch-10inch-lvds_overlay.dtbo verdin-imx8mp_panel-cap-touch-10inch-dsi_overlay.dtbo
verdin-imx8mp_dsi-to-hdmi_overlay.dtbo verdin-imx8mp_hmp_overlay.dtbo verdin-imx8mp_mezzanine_panel-lvds-dual-channel-1080p_overlay.dtbo verdin-imx8mp_panel-cap-touch-10inch-lvds_overlay.dtbo
verdin-imx8mp_dsi-to-lvds_panel-cap-touch-10inch-lvds_overlay.dtbo verdin-imx8mp_mezzanine_ov5640-alt-jumpers_overlay.dtbo verdin-imx8mp_nau8822-btl_overlay.dtbo verdin-imx8mp_spidev_overlay.dtbo
verdin-imx8mp_dsi-to-lvds_panel-lvds-dual-channel-1080p_overlay.dtbo verdin-imx8mp_mezzanine_ov5640-default-jumpers_overlay.dtbo verdin-imx8mp_ov5640_overlay.dtbo
But, the overlays.txt file has no entries so no overlays were autoloaded on boot:
torizon@verdin-imx8mp-06849059:~$ cat /boot/ostree/torizon-9997489fbeb8fab53d45ebbbedf900f70e19473d304316dd7bdd49cba12d2df9/dtb/overlays.txt
fdt_overlays=
This works because when you do dto remove --all it removes all entries from overlays.txt and any custom overlay binaries that were added by TorizonCore Builder. This is why we use an intermediary image as the base. Since the intermediary image becomes the new base image then test.dtbo is considered part of the base image. Meaning dto remove --all will blank out overlays.txt, but importantly not remove test.dtbo.
Best Regards,
Jeremias
Hi Jeremias,
Thanks again for your support. I went with the sed solution started in an alpine container that way seems to work pretty well. I now have two overlays one for our “rev.1” hardware and one for “rev.2”. We default to rev.2 which also works on rev.1 and the application can then edit overlays.txt accordingly. This will be overwritten in case of an update but not on a reboot which is exactly what we want.
Now we of course hope this behavior does not break at some point.
Best Regards,
Philippe
Your method sounds okay to me, as long as it fulfills your needs and requirements. The only thing I can think of is to make sure you sync your file writes after touching overlays.txt, especially if you’re going to issue a reboot/power-cycle right after writing this file. I’ve seen others do a similar mistake and wonder why their file edits weren’t persisting after the reboot.
Other than that I don’t imagine we’ll do anything to break this behavior, the interface with overlays.txt is pretty straightforward and simple. Of course everything is always subject to change between major versions of our software, but I’m not aware of anything yet that would affect this, just something to note.
Best Regards,
Jeremias
