rpi5: overlay_prefix required in config.txt for dtoverlay support

[jens-maus]

Describe the issue you are experiencing

Due to the changed bootloading chain in the current RaspberryPi5 support it seems loading device tree overlays specified in the /mnt/boot/config.txt bootloader config file seems to be broken at the moment.

Even thought the documentation on the tryboot functionality in the RaspberryPi bootloader states that os_prefix is added to the existing overlay_prefix option (default: overlays/), this seems to be NOT the case at the moment (cf. https://www.raspberrypi.com/documentation/computers/config_txt.html#overlay_prefix)

This has become visible in the optional support for the RPI-RF-MOD Homematic RF module which requires to adapt the /mnt/boot/config.txt file, adding a dtoverlay=rpi-rf-mod statement to it. However, doing so in the current config.txt of the rpi5 version of HomeAssistantOS does not load the rpi-rf-mod.dtbo file. After looking at the output of the RaspberryPi bootloader one can see that the bootloader tries to load that dtoverlay, but fails:

After adding the following additional (usually not required) overlay_prefix line to the config.txt file:

overlay_prefix=slot-A/overlays/

the bootloader can correctly load the rpi-rf-mod.dtbo (not the number of bytes mentioned in the rpi-rf-mod line):

Thus, it seems that with the tryboot functionality in place the stated ${os_prefix}${overlay_prefix} prefixing (cf. https://www.raspberrypi.com/documentation/computers/config_txt.html#overlay_prefix) does not seem to be in place or work correctly in the context of HomeAssistantOS.

BTW: It can also be seen in the bootloader that it is also not able to load the vc4-kms-v3d.dtbo with the missing overlay_prefix line.

What operating system image do you use?

RaspberryPi 5

What version of Home Assistant Operating System is installed?

11.4

Did you upgrade the Operating System.

No

Steps to reproduce the issue

1. See that the bootloader is NOT loading the vc4-kms-v3d.dtbo dtoverlay
2. Add overlay_prefix=slot-A/overlays/ to config.txt.
3. See that the bootloader is NOW able to load the vc4-kms-v3d.dtbo dtoverlay during bootup.

Anything in the Supervisor logs that might be useful for us?

n/a

Anything in the Host logs that might be useful for us?

n/a

System information

n/a

Additional information

The issue has already been reported and investigated accordingly. See:

#3069
jens-maus/RaspberryMatic#2618

[agners]

Even thought the documentation on the tryboot functionality in the RaspberryPi bootloader states that os_prefix is added to the existing overlay_prefix option (default: overlays/), this seems to be NOT the case at the moment (cf. https://www.raspberrypi.com/documentation/computers/config_txt.html#overlay_prefix)

So this is a bug in the Raspberry Pi firmware then right?

The issue has already been reported and investigated accordingly. See:

Ah I see those are all our investigations.

Have you reported it upstream to the Raspberry Pi developers?

[jens-maus]

Even thought the documentation on the tryboot functionality in the RaspberryPi bootloader states that os_prefix is added to the existing overlay_prefix option (default: overlays/), this seems to be NOT the case at the moment (cf. https://www.raspberrypi.com/documentation/computers/config_txt.html#overlay_prefix)

So this is a bug in the Raspberry Pi firmware then right?

That's a good question. I first wanted to share this here with you so that you can try to reproduce this yourself first. If done, then we could of course open up a new issue ticket at the upstream project.

The issue has already been reported and investigated accordingly. See:

Ah I see those are all our investigations.

Have you reported it upstream to the Raspberry Pi developers?

Nope, not yet. As said, I first want to see if you guys could reproduce that issue. Another question would be where to issue this issue afterwards? rpi-firmware or rpi-eeprom?

[sairon]

Not sure if we all missed it before or if it's been added recently, but the overlay_prefix now has a note in the docs:

Unless ${os_prefix}${overlay_prefix}README exists, overlays are shared with the main OS (i.e. os_prefix is ignored).

I can confirm that adding an empty README file to the overlays directory does the trick, and overlays are then loaded fine. Kind of strange feature, but the fix is easy (and on the way).

[jens-maus]

I can confirm that adding an empty README file to the overlays directory does the trick, and overlays are then loaded fine. Kind of strange feature, but the fix is easy (and on the way).

Really? This sounds indeed like a strange feature or side-effect. Can't be real that just adding an empty README fixes this issue. In fact, this might IMHO later end up in a potential regression in case someone else might think removing the README might be ok and then the issue appears again. Perhaps instead explicity adding overlay_prefix=slot-A/overlays/ to the config.txt might be a better or more sustainable approach in the end?