11.2dev (rpi): u-boot crashes with miniuart-bt and rpi-rf-mod dtbo enabled with latest stable_2023XXXX kernels

[jens-maus]

Describe the issue you are experiencing

I just recognized that when enabling the necessary miniuart-bt and rpi-rf-mod device tree overlay together using:

# Uncomment this to enable GPIO support for RPI-RF-MOD/HM-MOD-RPI-PCB
enable_uart=1
dtparam=i2c_arm=on
dtoverlay=miniuart-bt
dtoverlay=rpi-rf-mod

in the /mnt/boot/config.txt in the 11.2dev development builds, the u-boot bootloader does seem to crash badly with leaving the system unbootable. When just enabling miniuart-bt or rpi-rf-mod device tree overlay alone, the system boots thought, but functionality is of course missing.

After some more investigation, it seems the cultrip of the issue seems that with newer RaspberryPi kernels (all with stable_XXXXXXX tags) and new/different board dtb is supplied (e.g. bcm2711-rpi-4-b.dtb). When replacing the dtb file in /mnt/boot with the one of the official 11.1 HAos build the system continues to boot with miniuart-bt and rpi-rf-mod enabled and even with the newer kernel from the stable_XXXXXX raspberrypi/linux project tags.

Furthermore and to rule out issues with the rpi-rf-mod dtoverlay definition itself, I tried to reproduce the issue with a vanilla RaspberryPiOS (bookworm) installation which also comes with the same updated board dtb and the miniuart dtbo. When using the same rpi-rf-mod dtbo there the system boots nicely but there of course no u-boot second stage bootloader is used but just the default raspberrypi bootloader.

To summarize: It seems u-boot is running in some issues when the miniuart-bt and rpi-rf-mod dtbo are enabled together with the newer board dtb (e.g. bcm2711-rpi-4-b.dtb). Unfortunately I could not identify the root cause in u-boot yet, but without u-boot the system advances and boots and the device tree looks normal. Just u-boot itself does not like the combination of miniuart-bt and rpi-rf-mod dtbo being enabled anymore if the board dtb is coming from the newer stable_XXXXXX raspberrypi/linux compiles.

What operating system image do you use?

rpi4-64 (Raspberry Pi 4/400 64-bit OS)

What version of Home Assistant Operating System is installed?

11.2dev

Did you upgrade the Operating System.

No

Steps to reproduce the issue

1. Install 11.2dev (rpi version)
2. enable minuart-bt and rpi-rf-mod dtbo at the same time
3. try to get the system booted
4. note, that the system does not boot anymore and that no u-boot output is shown
5. disable either minuart-bt OR rpi-rf-mod dtbo again and note the system boots again
6. also try to revert to an older board dtb from the last official 11.1 HAos and then the system also boots
7. also try to omit/not use u-boot and there also the system boots.

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

RaspberryPi platform (tested with pi3, pi4, etc.).

Additional information

n/a

[jens-maus]

After some more investigation on the actual dtb differences between older raspberrypi/linux kernel sources I identified the following potential changes resulting in the actual issue reported here:

        chosen {
                bootargs = "coherent_pool=1M 8250.nr_uarts=1 snd_bcm2835.enable_headphones=0";
-               phandle = <0x3d>;
+               phandle = <0x50>;
+               stdout-path = "serial0:115200n8";
        };

So it seems the raspberrypi folks have added a dedicated stdout-path definition in the chosen section of their dtbs. And when using the rpi-rf-mod (which redefines the uart0 section, see https://github.com/jens-maus/RaspberryMatic/blob/master/buildroot-external/package/rpi-rf-mod/dts/rpi-rf-mod.dts#L77-L86) this causes u-boot to try to use the redefined uart for serial console/output, which of course does not work.

However, adding the following dtbo overlay section to wipe the stdout-path definition u-boot is able to continue and not crash:

    fragment@4 {
        target = <&chosen>;
        __overlay__ {
            stdout-path = "";
        };
    };

So this might be able to solve the issue. Question remains, however, if this would be an appropriate workaround the issue or if we should takle this issue in a different manner (e.g. remove that stdout-path definitions in the board dts in the kernel sources or patch u-boot to not use stdout-path at all, etc.)? Open to hear suggestions to it, thought.

[sairon]

Thanks for the thorough investigation, your patch looks sound, however we're currently looking into Bluetooth issues that emerged on some RPis after the kernel update as well and I'm not sure if we won't be reverting any of the DTS patches, as it seems to share some common grounds with your issue. I'll keep you posted!

[github-actions]

There hasn't been any activity on this issue recently. To keep our backlog manageable we have to clean old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant OS version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.