fix: BOOT_UART on Raspberry Pi 5 does not use GPIO 14/15

[christopher-besch]

Related to #3239 and #3938 .

We were pulling our hair out at getting UART to work on the Raspberry Pi 5 Compute Module. After a lot of trying around we concluded that there are mistakes in:

• the docs, which this PR fix,
• the datasheet and
• raspi-config.

I wrote an article explaining this in-depth: https://chris-besch.com/articles/raspberry_pi_5_uart
We're not entirely sure our understanding of all this is completely correct and we base our explanation on some tests we did only with a Raspberry Pi 5 Compute Module IO Board. We'd of course be very interested in any mistakes we might have done.

[lurch]

There's also https://www.raspberrypi.com/documentation/computers/config_txt.html#enable_rp1_uart and https://github.com/raspberrypi/rpi-eeprom/blob/master/firmware-2712/release-notes.md#2025-07-03-enable-firmware-uart-output-on-the-40-pin-header-latest (which doesn't appear to be mentioned in the docs yet).

[katshann-raspberry]

@pelwell Can you have a look at this PR and the linked article and confirm if the understanding and suggested docs changes are correct?
Cheers!

[pelwell]

I think that looks OK. I'm not so keen on the use of "primary UART" to refer to the UART header on Pi 5, since this is more of a configuration-dependent software concept. It's defined as the thing that /dev/serial0 ends up pointing at, which is often the debug UART on Pi 5, but see below.

As suggested in the PR, there are some omissions:

1. enable_rp1_uart will route the later firmware debug messages out through GPIOs 14 & 15 - enough to include all of the file accesses (initramfs, overlays etc.).
2. If config.txt contains the old familiar enable_uart=1 and there is no UART cable plugged into the 3-pin header, the firmware will automatically enable debug output on the 14 & 15, in time to get all of the kernel logging.

In both cases, /dev/serial0 ends up pointing at /dev/ttyAMA0 (UART0), which is the primary in this configuration.