On 2020-11-04 15:05, Stefan Agner wrote:
On 2020-10-16 03:28, Ricardo Salveti wrote:
On Tue, Oct 13, 2020 at 11:04 AM Peter Robinson pbrobinson@gmail.com wrote:
Hello Matthias,
I have upgraded the Raspberry 3 firmware from raspi3-firmware (1.20190215-1+deb10u4) to raspi-firmware (1.20200601-3) [https://packages.debian.org/bullseye/raspi-firmware].
After the upgrade the output of U-Boot on the serial console is complete gibberish as if the baudrate were incorrect. The output from the Linux kernel is fine at 115200 baud.
I've seen similar on all firmware since around mid April up until recently, it seems to be fixed with releases in Oct (I'm using one from Oct 8th), I'm not sure if it can be fixed in U-Boot but it seems to be due to a change in the firmware.
Thanks for confirming the problem.
For reference I have found a number of other problems with recent firmwares and 2020.10 release:
- U-Boot crashes on a RPi4 8Gb model if you don't have a display connected [1]
- It doesn't boot, not sure if it's a crash or something else, you
just get the rainbow screen, if you don't have the uart enabled in config.txt (ie just using a display for output).
Noticed the same as well here (boots fine only with enable_uart=1). While playing over with the files I noticed it works fine with the latest firmware when using an older bcm2710-rpi-3-b-plus.dtb (placed together with the firmware). If I use the latest bcm2710-rpi-3-b-plus.dtb from the 5.4 downstream kernel, it doesn't work (only tested on rpi3-b-plus).
This is with CONFIG_OF_BOARD=y, if I use CONFIG_OF_EMBED instead it works just fine (which gives me the impression that u-boot might not be happy with the dtb generated by the firmware when enable_uart is not set).
What we noticed is adding brcm,bcm2835-pl011 compatible to the UARTs makes U-Boot 2020.10 boot even *without* enable_uart=1. dm shows that with this change CONFIG_BCM283X_PL011_SERIAL is in use...
From what I understand, this driver checks if the UART is muxed, and if not bails out. So I guess without that compatible string, when the regular PL011 driver is used, it seems that U-Boot tries to initialize UART and fails?
I looked a bit more into this and I think I made some progress.
This is with downstream Linux 5.4, but I don't think it is relevant as downstream uses now the same UART bindings as upstream.
It seems when U-Boot is falling back to the Bluetooth (mini) UART and crashes when using it as serial console. I noticed when setting "enable_uart=0" and "dtoverlay=disable-bt" U-Boot does show a serial console on the GPIO pins 14/15. The console is running on UART0, the first PL011 UART: serial 0 [ + ] serial_pl01x | |-- serial@7e201000
Another method which works using "dtparam=uart0=off" and "enable_uart=0", which essentially disables UART0 and UART1 in device tree. U-Boot won't show a serial console, but the system boots...
I think the reason why adding "brcm,bcm2835-pl011" to compatible works is because it makes probing of uart0 (the PL011 UART) in U-Boot fail, and hence U-Boot won't fallback to this UARTs.
Note that "enable_uart=0" is equal to *not* setting enable_uart at all according to documentation and confirmed in the discussion at https://github.com/raspberrypi/firmware/issues/1483 (on RPi 3/4 anyways).
What I also noticed that uart2 makes trouble (which is also PL011 in RPi4): "dtparam=uart0=off", "enable_uart=0" and "dtoverlay=uart2" make sure that only uart2 is available to U-Boot. It makes the system crash well...
Disabling CONFIG_PL01X_SERIAL (which is only possible with a Kconfig change in arch/arm/Kconfig) makes the system boot in all cases...
-- Stefan