RPi3: serial console
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 observe this both with rpi_3_defconfig and rpi_arm64_defconfig, v2020.10 and current origin/master.
config.txt:
arm_control=0x200 enable_uart=1 upstream_kernel=1 kernel=u-boot.bin
boot.scr: setenv autoload no dhcp load mmc 0:1 $fdt_addr_r bcm2710-rpi-3-b-plus.dtb load mmc 0:2 $kernel_addr_r EFI/debian/grubaa64.efi bootefi $kernel_addr_r $fdt_addr_r
Best regards
Heinrich
On Mon, Oct 12, 2020 at 3:56 PM Heinrich Schuchardt xypron.glpk@gmx.de 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.
I observe this both with rpi_3_defconfig and rpi_arm64_defconfig, v2020.10 and current origin/master.
config.txt:
arm_control=0x200 enable_uart=1 upstream_kernel=1 kernel=u-boot.bin
boot.scr: setenv autoload no dhcp load mmc 0:1 $fdt_addr_r bcm2710-rpi-3-b-plus.dtb load mmc 0:2 $kernel_addr_r EFI/debian/grubaa64.efi bootefi $kernel_addr_r $fdt_addr_r
Best regards
Heinrich
On 10/12/20 6:50 PM, Peter Robinson wrote:
On Mon, Oct 12, 2020 at 3:56 PM Heinrich Schuchardt xypron.glpk@gmx.de 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.
Using the most current files from https://github.com/raspberrypi/firmware does not solve the problem for me.
In bcm283x_mu_serial_setbrg() we divide a clock rate by the baudrate. divider = plat->clock / (baudrate * 8);
If we do not have the correct clock rate, the actual baudrate will be wrong.
Best regards
Heinrich
I observe this both with rpi_3_defconfig and rpi_arm64_defconfig, v2020.10 and current origin/master.
config.txt:
arm_control=0x200 enable_uart=1 upstream_kernel=1 kernel=u-boot.bin
boot.scr: setenv autoload no dhcp load mmc 0:1 $fdt_addr_r bcm2710-rpi-3-b-plus.dtb load mmc 0:2 $kernel_addr_r EFI/debian/grubaa64.efi bootefi $kernel_addr_r $fdt_addr_r
Best regards
Heinrich
Hello,
Em seg., 12 de out. de 2020 às 15:39, Heinrich Schuchardt xypron.glpk@gmx.de escreveu:
On 10/12/20 6:50 PM, Peter Robinson wrote:
On Mon, Oct 12, 2020 at 3:56 PM Heinrich Schuchardt xypron.glpk@gmx.de 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.
Using the most current files from https://github.com/raspberrypi/firmware does not solve the problem for me.
In bcm283x_mu_serial_setbrg() we divide a clock rate by the baudrate. divider = plat->clock / (baudrate * 8);
If we do not have the correct clock rate, the actual baudrate will be wrong.
It seems if you have the dtb files next to the firmware, the firmware loads it and the baudrate seems right. We've been struggling with this at our side as well and this was the only way we got it to work.
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).
Both of these seem to be due to firmware changes as opposed to U-Boot changes, as it was working fine on the firmware from Apr 1st, but there's been various other issues there like the 8Gb model doesn't completely work.
[1] https://lists.denx.de/pipermail/u-boot/2020-September/428156.html
Using the most current files from https://github.com/raspberrypi/firmware does not solve the problem for me.
In bcm283x_mu_serial_setbrg() we divide a clock rate by the baudrate. divider = plat->clock / (baudrate * 8);
If we do not have the correct clock rate, the actual baudrate will be wrong.
Best regards
Heinrich
I observe this both with rpi_3_defconfig and rpi_arm64_defconfig, v2020.10 and current origin/master.
config.txt:
arm_control=0x200 enable_uart=1 upstream_kernel=1 kernel=u-boot.bin
boot.scr: setenv autoload no dhcp load mmc 0:1 $fdt_addr_r bcm2710-rpi-3-b-plus.dtb load mmc 0:2 $kernel_addr_r EFI/debian/grubaa64.efi bootefi $kernel_addr_r $fdt_addr_r
Best regards
Heinrich
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).
Cheers,
-- Ricardo Salveti de Araujo
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?
-- Stefan
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
participants (5)
-
Heinrich Schuchardt -
Otavio Salvador -
Peter Robinson -
Ricardo Salveti -
Stefan Agner