I used a two step approach to solve this issue for a commercial product based on the CM4 and U-Boot.
The first step is to produce a flattened device tree rather than try to have the boot firmware load the various required overlays. This is reasonably straight-forward as long as you aren't trying to dynamically change the hardware between reboots. For a fixed set of overlays, you can simply update the dtb built with the kernel to include the hardware you need enabled for your device. I did this using a patch file for the Linux kernel which was built by Buildroot.
The second step is copying some modified DT entries from the firmware blob loaded device-tree into your runtime device tree. This is required because the device tree built along with the Linux kernel will not typically result in a fully functional system. You may need to update DMA ranges based on silicon revision, and the RPi firmware modifies a variety of other device-tree entries: https://forums.raspberrypi.com/viewtopi ... s#p1974233
I have a patch series I use with U-Boot that copies various device-tree nodes from the firmware loaded/modified device-tree to a "stock" Linux device-tree loaded from the root filesystem along with the Linux kernel. Some of this functionality is now included in the newer mainline U-Boot code, but depending on exactly what you're doing you may need more nodes copied than what U-Boot does by default. The U-Boot patches can be found as part of my br2rauc project on github. They have been removed from the most recent code because they are no longer required for a bootable system (thanks to newer mainline U-Boot copying a few device-tree nodes) but I still use these patches for our CM4 based embedded devices. https://github.com/cdsteinkuehler/br2ra ... ches/uboot
Note that the RPi 5 / CM5 is a completely different beast and the RPi folks went crazy with how much the firmware blob is modifying the device-tree for these boards. The RPi 5 based product I'm working on is just going to use the firmware modified device-tree rather than try to copy the changes (not ideal, but it seems to be the least bad option). The base device-tree is still customized, so the RPi firmware isn't actually loading any overlays to enable new features, it's just modifying an ever growing list of nodes in the device tree loaded from the file system.
The first step is to produce a flattened device tree rather than try to have the boot firmware load the various required overlays. This is reasonably straight-forward as long as you aren't trying to dynamically change the hardware between reboots. For a fixed set of overlays, you can simply update the dtb built with the kernel to include the hardware you need enabled for your device. I did this using a patch file for the Linux kernel which was built by Buildroot.
The second step is copying some modified DT entries from the firmware blob loaded device-tree into your runtime device tree. This is required because the device tree built along with the Linux kernel will not typically result in a fully functional system. You may need to update DMA ranges based on silicon revision, and the RPi firmware modifies a variety of other device-tree entries: https://forums.raspberrypi.com/viewtopi ... s#p1974233
I have a patch series I use with U-Boot that copies various device-tree nodes from the firmware loaded/modified device-tree to a "stock" Linux device-tree loaded from the root filesystem along with the Linux kernel. Some of this functionality is now included in the newer mainline U-Boot code, but depending on exactly what you're doing you may need more nodes copied than what U-Boot does by default. The U-Boot patches can be found as part of my br2rauc project on github. They have been removed from the most recent code because they are no longer required for a bootable system (thanks to newer mainline U-Boot copying a few device-tree nodes) but I still use these patches for our CM4 based embedded devices. https://github.com/cdsteinkuehler/br2ra ... ches/uboot
Note that the RPi 5 / CM5 is a completely different beast and the RPi folks went crazy with how much the firmware blob is modifying the device-tree for these boards. The RPi 5 based product I'm working on is just going to use the firmware modified device-tree rather than try to copy the changes (not ideal, but it seems to be the least bad option). The base device-tree is still customized, so the RPi firmware isn't actually loading any overlays to enable new features, it's just modifying an ever growing list of nodes in the device tree loaded from the file system.
Statistics: Posted by cdsteinkuehler — Fri May 09, 2025 12:42 am