← Back · part of NextBSD Research · companion to the 40-pin serial console
It is a 3-pin JST-SH on the main board, it carries UART10 inside the BCM2712, and it is the console you want before doing any PCIe work. No teardown of a Pi 500+ showing it had ever been published — several sources, this one included, had concluded it was not fitted.
Confirmed on hardware The connector exists, it is UART10, and it is not behind PCIe. Linux reports the console as ttyAMA10 and the device-tree alias resolves to /soc@107c000000/serial@7d001000 — soc@, not pcie@.
The 40-pin console is excellent and needs no disassembly, but its pins are RP1 UART0 — and RP1 sits behind PCIe. The moment a driver takes ownership of that controller the console moves out from under itself and the board goes silent mid-boot, which on the wire is indistinguishable from a crash.
That is not a fault that can be patched around. The console’s address depends on both the PCIe outbound window and RP1’s BAR assignment, and bringing up the controller necessarily changes both. Measured: the first attach to pcie2 killed the console exactly as the native-boot plan predicted it would.
This connector is on the other side of that problem. It is inside the SoC, so PCIe can be reset freely.
On the main board, immediately above the 40-pin header, between a small square QFN and the black BOURNS ethernet magnetics. Small, cream-coloured, with three metal contacts.
Do not confuse it with BATTERY There is a second small connector at the far left of the board, near the M.2 slot, silkscreened BATTERY. It has two contacts and is the real-time-clock cell — a power input. Driving a probe into it would be a bad idea. Count the contacts: three, not two. A 4-contact connector, if present, is a fan header.
The case is designed to come apart — a tool is supplied for swapping the SSD. Undo the case screws, lift the keyboard half, and remove the metal heatspreader over the main board. The board itself does not need to come out, which is just as well: it is retained by plastic clips, the rear ports pass through the case wall, and the keyboard ribbon tethers it.
The keyboard ribbon can be unplugged entirely while you work. Nothing needs it — and the board still powers on without it, because the bootloader reports WAIT_FOR_POWER_BUTTON 0: applying USB-C power is enough.
This is the other lead in the Debug Probe box — the one with a keyed plug at both ends, usually described as the Pi 5 debug cable. Not the three loose jumper wires. There are no pins to count and no orientation to get right: it is keyed.
U is the UART port; D is SWD and is not used.Simpler than the 40-pin case, because this is the firmware’s default debug UART. In config.txt, only:
enable_uart=1and crucially remove the three lines that redirect the console to the 40-pin header:
enable_rp1_uart=1 # RP1 UART0 -- not this connector
pciex4_reset=0 # its required companion
dtparam=uart0_console # sends the console to the 40-pin headerThen 115200 8N1 as before. Worth doing this through tryboot.txt rather than config.txt the first time, so a power cycle always reverts.
Strictly more than the 40-pin console, which only ever picked up mid-bootloader. This one starts at the boot ROM:
RPi: BOOTSYS release VERSION:57db150d DATE: 2025/11/05
BOOTMODE: 0x06 partition 0 ... boardrev e04190
POWER_OFF_ON_HALT: 1 WAIT_FOR_POWER_BUTTON 0
RP1_BOOT chip ID: 0x20001927
SDRAM_CONFIG: 1b
Initialising SDRAM rank 2 total-size: 128 Gbit 4267
OTP boardrev e04190
RP1_BOOT: fw size 31248
PCI2 init / PCI2 reset / PCIe scan 00001de4:00000001
...
NOTICE: BL31: Built : 12:55:13, Dec 4 2024
Debian GNU/Linux 13 pi ttyAMA10Why that log proves it Read the order. SDRAM initialisation prints before RP1 is loaded with firmware and before PCIe is scanned. A UART living behind PCIe could not produce those lines. You also get TF-A’s BL31 banner, which the 40-pin console never showed.
It is worth being concrete, because “a second serial port” undersells it. The bring-up was hard blocked without this, not merely slowed.
| 40-pin header | This connector | |
|---|---|---|
| Which UART | RP1 UART0 | UART10 |
| Lives in | RP1, behind PCIe | the BCM2712 itself |
| Survives a PCIe reset | no | yes |
| Earliest output | mid-bootloader | boot ROM, before SDRAM is trained |
| Needs the case open | no | yes |
Everything that makes this machine usable hangs off RP1 — and RP1 is precisely what could not be touched while the console lived inside it:
pcie2 -> RP1 -+- ethernet [raspberrypi,rp1-gem]
+- usb -> xhci-hcd.0
\- usb -> xhci-hcd.1 -> the built-in keyboardWriting the RP1 bridge driver means resetting that link repeatedly and watching what happens. On the 40-pin console the board simply goes quiet at the first reset, and a working driver looks exactly like a dead one. That is not a debugging inconvenience; it is a dead end. With the console in the SoC, the link can be reset as often as the work requires and the kernel keeps talking.
It also retires a workaround. Until now the only way to make progress on PCIe at all was a device-tree overlay masking pcie2 off entirely, so that FreeBSD never touched the controller the console depended on. That bought pcie1 — the NVMe enumerates, and storage works — but it deliberately fenced off the half of the machine with the keyboard and the network on it. The overlay can now go.
Independently of PCIe, this connector sees more of the boot: the boot ROM, SDRAM training, OTP, USB-PD negotiation, boot-device selection and TF-A’s BL31 banner all appear here and none of them ever reached the 40-pin header. For diagnosing a board that will not boot at all — as opposed to an OS that will not boot — that is the difference between evidence and guesswork.
It is internal. The 40-pin header is on the rear edge and needs nothing opened; this one is inside the case, so the machine either stays open or the thin cable has to be routed out past the case seam. For bring-up work that is a fair price; for casual use the 40-pin header remains the better answer.
Rule of thumb: use the 40-pin header until you start touching PCIe, then move here. The native-boot plan says to find this connector before the PCIe work rather than during it, and that advice is correct — we learned it the slow way.
Measured on a Raspberry Pi 500+, revision e04190, board Raspberry Pi 500 R4 (PVT), with a Raspberry Pi Debug Probe on macOS. Tracked as nextbsd-kernel#80.