Firmware 0f315f8 regressed (garbled) serial output in u-boot

[nullr0ute]

The 0f315f8 firmware (build date: 2017-05-30 15:24) regressed serial output when using u-boot. You just get a series of "�����������������������������" until the kernel starts to boot. This continues right through to the latest firmware 4b29d95. The last good firmware for u-boot output was 73f44c6

[pelwell]

Are you sure about that last known good firmware hash? I see three commits between your LKG and the breaking commit you list:

73f44c6 - LKG
89ec375 - ???
b9dbf8c - ???
32c2899 - ???
0f315f8 - BAD

Looking at the corresponding source commit history for the firmware I don't see anything that would obviously have caused a UART issue, so narrowing this down further would help.

Can you also include an indication of which platform you are using, and any relevant (uncommented) config.txt settings.

[nullr0ute]

While there were a number of commits between the good and the bad they were all kernel updates/changes.

89ec375 - Pure kernel - vc4 fix
b9dbf8c - kernel 4.9.29 plus kernel config changes
32c2899 - kernel 4.9.30 plus kernel config changes

So yes, if you check there was no firmware updates between the two commits I mentioned above.

[pelwell]

Can you also include an indication of which platform you are using, and any relevant (uncommented) config.txt settings.

[nullr0ute]

Fedora 26. The only config.txt options we use are:
kernel=u-boot.bin
enable_uart=1
gpu_mem=16
boot_delay=1

These options haven't changed (for probably a year), the only thing that changed between the two was the firmware, I tested it backwards and forwards through all firmware commits from May 15th to the latest (4b29d95 - June 26th)

[pelwell]

And which model of Pi?

[nullr0ute]

Pi 2 and Pi 3

[nullr0ute]

the ARMv7 version of the Pi 2 for reference (2836)

[pelwell]

The firmware chooses which UART to configure based on the combined (.dtb + overlays) Device Tree. Which .dtb are you using on the Pi 3? I'm asking because using the standard RPi configurations Pi 2 configures UART0 while Pi 3 configures UART1, making a regression on both less likely.

[nullr0ute]

This has worked just fine in u-boot for well over a year, if breaks with that firmware. This has regressed in the firmware, there is nothing else that has changed.

[pelwell]

Yes, of course. I was gathering more information to help pin it down.

Anyway, I've found the cause and it will be fixed in the next firmware release. Until then init_uart_baud=115200 will work around the bug.

[popcornmix]

rpi-update firmware should now have the fix

[nullr0ute]

I can confirm init_uart_baud=115200 fixes the issue for me on a bcm2836 RPi2 on the "2017-06-13 14:50" firmware. I'll test the lastest firmware now.

[nullr0ute]

Confirmed the new firmware fixes the issue for me (removing the work around from config.txt) on the bcm2836 RPi2 I've been testing on,will test the RPi3 shortly too but this look good. Thanks!

[lategoodbye]

@popcornmix Could you please explain your change?
This looks like a U-Boot issue to me.

[popcornmix]

The firmware does set up the uart divisors to match "init_uart_baud" and that got unintentionally changed on the firmware side.
Now ideally uboot should be setting these up explicitly so it isn't dependent on the firmware initialisation, but i guess that is not currently done.

[lategoodbye]

Thanks