Devicetree overlays with vanilla OpenWRT 25.12.x

Anyone knows or figured out how to use devicetree overlays with U-Boot? Or any other method which can be used to add extra nodes to the device tree without recompiling OpenWRT?

The big picture is simple, I would like to create a 3D printable chassis for myself which looks like any other off-the-shelf desktop router. Most of this devices have some or more front panel LEDs. Some signals already on the board (and can be hijacked) but for the missing ones, I need a couple new device nodes with “gpio-leds” type to attach triggers to it.

Normally dtbo were loaded from fit image so on regular way you have to add them there and set them in uboot as bootconf (bootm $loadaddr#bootconf).

I know dtoverlay command in raspberry pi which can apply dtbo at runtine,but have not found it for non raspbian os.

Source seems to be this:

I also did some tests on dynamicly loading dtbo,works so far,but unloading is a problem.

Compilation should be easy when you do not need any specific headers.

I just digged down into the u-boot sources. I reckon if I place the compiled dtb somewhere where u-boot can access it, I can apply it from there. The main dtb was compiled with “-@” so clearly it should work somehow. Because this weekend is a long weekend where I live, I have plenty of time to figure this out :D.

The base devicetree is also loaded from fit image…you can do stuff in uboot,but you have to load base-dt and overlays manually and merge with fdt apply afair and then load non-fit image and initramfs from openwrt. Imho it is easier packing your overlay into the fit and add its config name to bootconf.

Finally figured it out! So, the main “thing” which will boot the device is the “bootm” magic command. I found this, doc/usage/cmd/bootm.rst · 36239d348ffdbf14c3792a2fc0b3f2ac7e6daffc · U-Boot / U-Boot · GitLab about some sub-commands which can be used to do the work step by step. So, the single “bootm $loadaddr#$bootconf#$bootconf_emmc#$bootconf_extra” can be replaced with these commands:

bootm start $loadaddr#$bootconf#$bootconf_emmc#$bootconf_extra
bootm loados
bootm ramdisk
bootm fdt
bootm prep
fdt set /chosen u-boot,bootconf $bootconf#$bootconf_emmc#$bootconf_extra
bootm go

I did not know why, but “bootm prep” sets the /chosen/u-boot,bootconf to a single 0x00 byte, which prevents the system from booting, but setting this up by hand fixes the issue, and the device came up perfectly fine.

On my device, the second partition on the eMMC (which was named “factory”) is empty, so that will be the perfect place to store the compiled overlay, which can be copied there with a simple dd, which can be loaded from U-boot with those commands:

part start mmc 0 factory devicetree_address
part size mmc 0 factory devicetree_sizeinblocks
mmc read 0x60000000 $devicetree_address $devicetree_sizeinblocks

My first concern is where to load this. The original FIT image will be loaded to 0x50000000, so I simply chose 0x60000000 for mine. I did not know if it’s okay, or not, but it works. The next thing will be to apply the overlay on the original devicetree with “fdt apply”.

The whole process will look like this:

bootm start $loadaddr#$bootconf#$bootconf_emmc#$bootconf_extra
bootm loados
bootm ramdisk
bootm fdt
part start mmc 0 factory devicetree_address
part size mmc 0 factory devicetree_sizeinblocks
mmc read 0x60000000 $devicetree_address $devicetree_sizeinblocks
fdt apply 0x60000000
bootm prep
fdt set /chosen u-boot,bootconf $bootconf#$bootconf_emmc#$bootconf_extra
bootm go

My next concern is around the size of the device tree binary. There is a command to resize the “container” of the devicetree (fdt resize: Device Tree Overlays — Das U-Boot unknown version documentation), but using it with even a small value (16384), the device will crash on the “bootm prep” stage. If I calculated correctly, just around ~8k is still free in the “original” space and because my compiled dtb is less than 1k I assume it’s safe to use without a resize.

The devicetree source can be compiled on the device if ‘dtc’ is installed.

1 Like

Not really vanilla, but see this:

Yeah, I saw this, but this entry point was too late to hijack and redirect the system LEDs in “/aliases” (led-boot, led-upgrade, led-running, led-failsafe) to a GPIO pin.