I am trying to load device tree overlays based on the state of certain input pins connected to id resistors that encode the board variant.
Ideally, I would like to apply a device tree overlay at runtime without reboot as can be done through sysfs with a certain TI patch. I realised fairly quickly though that this would be a disproportionately large challenge and that there must be a better way.
The next best thing would be to modify the bootloader environment so that the input pins are evaluated at boot time using u-boot’s gpio command, but I can’t see how to make this modification with torizoncore-builder? Is it possible? Any suggestions?
Hi @lblackbeard ,
TorizonCore Builder doesn’t support modifying the kernel nor the bootloader of an image, so you’d have to create a custom image with your changes through Yocto, usually with a custom layer, as detailed here:
We have a general article about U-Boot and some of the variables in it that we add for our images. You can also take a look at our Yocto layers to see how we implement U-Boot variables, and based on that run a command like gpio when starting U-Boot.
Best regards,
Lucas Akira
Related to automatically applying device tree overlays on start-up, another customer did a similar setup, though it was done with a systemd service that detected the hardware followed by a quick reboot to apply the correct overlays:
Although it wasn’t done on U-Boot, perhaps the setup above can be suitable for your use-case.
Best regards,
Lucas Akira
2 Likes
Thanks Lucas,
I’d prefer to leave the Yocto build in the hands of Toradex if I can. I’m looking now at writing a service to modify /boot/uEnv.txt, but I can’t find anything on how this file is loaded by U-Boot in the first place? I take it there’s a call made somewhere to do so because both fw_printenv and printenv exclude the contents of uEnv.txt?
Best regards,
Lloyd
I managed to dump boot.scr and find the line where uEnv.txt is loaded. I’m sure it’s platform specific, but for others:
This command shows the boot script:
ls mmc 0
This command loads the script into memory for subsequent display:
load mmc 0 0x81000000 boot.scr
This command displays the contents of the first 0x400 bytes :
md 0x81000000 400
After a little bit of formatting:
Hi @lblackbeard ,
If I understood this correctly, you’re planning to write a systemd service that modifies /boot/loader/uEnv.txt so that you can check the hardware and apply the correct overlays. These two actions would be executed inside U-Boot.
If that’s correct, you would still need to reboot the module to apply the overlays, given that systemd services are only executed after the bootloader.
If that’s the case, could you do the hardware check in the systemd service and change /boot/ostree/torizon-<hash>/dtb/overlays.txt, like detailed in the topic I’ve referenced? That would also require a reboot to apply the overlays, but it will probably be simpler and safer to alter overlays.txt compared to changing uEnv.txt.
Best regards,
Lucas Akira
Hi Lucas,
It’s a good point that it would be safer to leave uEnv.txt alone, but I’m a little wary of architectures that reboot themselves as part of their standard operation - in my experience it opens the door to bootloops / excessive reboots (I’m imagining a dry joint on one of the id resistors) and I would also prefer to avoid dealing with co-existence with the upgrade system as was documented in the topic you referenced.
What I’m intending is a modification to /boot that would only need to be done once in production as part of an existing “first boot” routine which is already in place. Subsequent reboots would then both read the variant and apply the overlay at the same time.
Best regards,
Lloyd
Hi @lblackbeard ,
Right, so in this case you don’t plan on doing a systemd service at all.
In this case I’d suggest continue looking into the U-Boot scripts and the documentation we have as a basis. For instance, you can set a U-Boot variable with commands to be executed, as shown here:
Best regards,
Lucas Akira