U-Boot (2020.10) fails to boot without enable_uart=1 after switch to 5.4 (rpi3-b-plus)

[ricardosalveti]

I'm using U-Boot 2020.10 and I noticed I'm unable to get it to boot unless I set enable_uart=1 when using the device tree files from the 5.4 firmware release (it stays in the rainbow screen).

I'm using CONFIG_OF_BOARD=y so I can rely on the device-tree provided by the firmware. My target device is a rpi3-b-plus.

I get the impression that u-boot might be having issues when parsing or handling the device-tree blob from the firmware, but hard to debug without really having any logs.

If I copy back the latest dtb from the 4.19 release it is able to boot just fine.

[ricardosalveti]

Also reported at https://lists.denx.de/pipermail/u-boot/2020-October/429533.html.

[pelwell]

We pushed a new firmware to the firmware repo yesterday that includes two potentially relevant patches - one fixes a problem when using an explicit armstub file, the other corrects the way clock speeds are reported to the ARM using the mailbox interface. You can grep the new version using sudo rpi-update.

[pelwell]

s/grep/grab/ - you can guess which tool I've been using recently.

[ricardosalveti]

We pushed a new firmware to the firmware repo yesterday that includes two potentially relevant patches - one fixes a problem when using an explicit armstub file, the other corrects the way clock speeds are reported to the ARM using the mailbox interface. You can grep the new version using sudo rpi-update.

Tried 2d83e2c and while I get a different behavior, it doesn't yet work right. With vc4-fkms-v3d or vc4-kms-v3d I don't get a rainbow screen, but it stays all black (probably u-boot hanging). Without those overlays it stays at the rainbow screen.

U-boot file I'm using http://rsalveti.net/tmp/u-boot.bin (standard 2020.10 with CONFIG_OF_BOARD=y instead of CONFIG_OF_EMBED=y).

[agners]

We experience the same behaviour with U-Boot 2020.10 in Home Assistant Operating System on Raspberry Pi 4 (probably on 3 as well, but I did not test that yet). What I noticed is when adding brcm,bcm2835-pl011 to compatible string the system boots fine, no matter if enable_uart=1 is set or not...

[pelwell]

brcm,bcm2835-pl011 doesn't exist in our current source trees, and from what I can tell it never did anything useful, so I can't explain why it would make a difference to you apart from moving things in memory.

[agners]

Upstream U-Boot has a driver which binds to it: https://gitlab.denx.de/u-boot/u-boot/-/blob/v2020.10/drivers/serial/serial_bcm283x_pl011.c ...

[agners]

What is enable_uart=1/0 exactly doing to the device tree? Is 0 actively disabling the UART nodes? Then U-Boot should not bind the device.

[pelwell]

enable_uart=0 has quite a few side effects, but one of them is to set dtparam=uart0=off if UART0 is the primary/console UART, or dtparam=uart1=off if UART1 is the primary. With the existing Pi DTBs this toggles the status of the nodes with the corresponding labels - uart0/uart.

[pelwell]

Note that this is currently only a disable - enable_uart=1 doesn't enable the relevant nodes.

[pelwell]

Upstream U-Boot has a driver which binds to it.

That would only work with old downstream DTBs - that compatible string has never appeared upstream AFAIK.

[vianpl]

FYI see patch ba61479e1ee9462 ("ARM: dts: bcm283x: Remove brcm,bcm2835-pl011 compatible") in Linux.

[agners]

@pelwell ok thanks for the information. Is absence of enable_uart=1 the same as enable_uart=0 or does absence imply another behaviour?

[agners]

@vianpl yes, I am aware of the patch and the fact that upstream Linux never made use of it. Still, upstream U-Boot has a driver which uses the compatible string to bind to a device with the brcm,bcm2835-pl011 compatible.

[pelwell]

The absence of enable_uart=1 implies the default behaviour, which varies with the primary UART. To match pre-Pi 3 systems, if UART0 is the primary UART then enable_uart defaults to 1, otherwise it's 0.