Serial console seems to give a incorrect baudrate. Overriding frequencies to previous Raspberries in /boot/config.txt helps: everything works as normal. After some iterations, I found that setting ‘gpu_freq=300’ solves the problem, although that is the default setting on a rpi 3. Probably someone reads that value to initialise the baudrate generator, and uses the old default ‘gpu_freq=250’ if the value is not set. This is almost certainly done in the closed-source /boot/start*.elf files. All those files do contain the texts ‘config.tst’ as well as ‘gpu_freq’. Please repair this issue..

• If the console is on UART1 (mini-UART) – the default case on Pi3 – you get serial output if and only if enable_uart=1. The core frequency is fixed at 250MHz, unless force_turbo=1 in which case it is fixed at 400MHz (provided there is sufficient power and cooling).
• If the console is on UART0 (PL011) – the default case on Pi0, Pi1, Pi2 and CM – you get serial output unless enable_uart=0. The core frequency is not restricted.

The only implication for Raspbian is that raspi-config should toggle enable_uart when the serial console is configured. It is safe to continue to send output to the UART when it is “disabled” because the UARTs are configured but disconnected from the GPIO pins. From today, a clean Raspbian install that has been rpi-updated will output to the serial port by default unless it is a Pi3, in which it is disabled unless enable_uart is set; it should never output corrupted data (unless you get over-temperature or under-voltage with force_turbo=1).

I’m in favour of making enable_uart=0 the default on all Pis, once people have had time to get used to the idea and we’ve not thought of any gotchas.

@pelwell mkknlimg does indeed allow the DT overlay to switch the RPi 3 console UART back to the PL011.

I’ve tested firmware.git commit 046effa “firmware: arm_loader: emmc clock depends on core clock See: #572” and found no blocking issues. From my perspective this bug can be closed, but I’ll leave that up to @josn0 since they filed the bug.

I did find one quirk, but I’m not sure there’s anything that can/should be done about it: On the RPi 3, if config.txt specifies enable_uart=0, or has no enable_uart line at all, then the mini UART is still enabled (so as not to hang SW that transmits data on it). However, the RX pinmux is not set up, so the UART continually receives 0x00 bytes (I didn’t actually verify the value; I assume 0x00). Perhaps the RX pinmux could still be set up to avoid this, leaving enable_uart simply as a flag that the user actively wants to use the UART so clock rates should be fixed? I suppose it’s quite plausible these days that a U-Boot user would only use HDMI+usbkbd, in the same way we assume a user of Linux GUI would.

My test matrix:

RPi B+
HDMI: OK
UART: OK
MMC: OK
Net: OK

RPi 2 B
HDMI: OK
UART: OK
MMC: OK
Net: OK

RPi 3 B 32-bit
MU (rpi_3_32b build):
HDMI: OK
UART: OK
MMC: OK
Net: OK
enable_uart=0 or no enable_uart stanza work: OK, with quirk
PL01x (rpi_2 build w/ DT overlay to switch UARTs):
HDMI: OK
UART: OK
MMC: OK
Net: OK

RPi 3 B 64-bit
MU (rpi_3 build):
HDMI: OK
UART: OK
MMC: OK
Net: OK