RPi3: serial console

[Stefan Agner <stefan@agner.ch>]

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 at 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