← Back · part of NextBSD Research · sub-plan of the Pi 500+ native-boot plan
Phase 0, in full. Three wires from a Raspberry Pi Debug Probe to the rear GPIO header — no disassembly. This is the only input channel the machine has until PCIe, RP1, dwc3, xHCI and USB-HID all work, so everything else in the plan is gated on getting it right.
Result This wiring produced a working console on the first attempt: firmware output, kernel messages, a login: prompt and a root shell over the wire — and later carried the entire NextBSD bring-up through phases 1–3.
It is external. A common wrong turn is to look for the 3-pin JST-SH debug connector a Pi 5 B exposes between its micro-HDMI ports — that one is inside the keyboard enclosure on a 500+, and whether it is even populated is still an open question. The 40-pin header needs no teardown.
| Use | Why | |
|---|---|---|
| Probe socket | U | D is SWD. The BCM2712 does not expose SWD to you and nothing in this bring-up uses it. |
| Lead | orange / yellow / black, female DuPont ends | The board’s contacts are square male pins recessed in a shroud, so sockets go over them. |
| Set aside | the grey-and-pink JST-SH → JST-SH lead | That is the Pi 5 debug-port cable, for the connector this machine does not expose. The male-pin variant of the DuPont lead is also wrong. |
The two sockets take the same connector, so nothing stops you plugging into the wrong one; it simply produces silence. U is the UART port and is the one the three-wire lead goes into. D is SWD — the port the probe is named for, and the reason most tutorials show it — but the BCM2712 does not expose SWD to you and nothing in this bring-up uses it.
Note the wire order: on Raspberry Pi’s 3-pin debug connector ground is the middle conductor, with transmit and receive outboard of it. That is worth knowing if you ever have to re-crimp a lead or identify one that has lost its housing.
The probe is CDC-ACM class-compliant, so macOS needs no driver — it appears as /dev/cu.usbmodem*. Use cu., never tty.: the tty. node blocks on carrier-detect and simply hangs.
Settled by the silkscreen: the case is marked ▲40 at the left end of the header, on the micro-HDMI side. So pin 40 is there and pin 1 is at the Ethernet end. Odd pins run along the top row, even along the bottom, both counting from the right — which puts all three of your wires in the bottom row.
| Probe wire | Direction | Position from Ethernet end | Pin | Signal |
|---|---|---|---|---|
| Black | common ground | 3rd, bottom row | 6 | GND |
| Yellow | probe RX ← Pi | 4th, bottom row | 8 | GPIO14 / TXD |
| Orange | probe TX → Pi | 5th, bottom row | 10 | GPIO15 / RXD |
Serial is crossed — each side’s transmit goes to the other side’s receive — which is why orange and yellow look swapped relative to their names.
The one way to do damage The two bottom-row positions to the right of your targets — positions 1 and 2, pins 2 and 4 — are both 5 V. A 5 V pin into the probe destroys it, and shorting one to ground is worse. If you are unsure of your count, miscount leftward: positions 6 and 7 are pins 12 and 14, GPIO18 and ground, and neither will hurt anything.
Three wires, never four. Nothing goes to a power pin — the Pi powers itself, and back-feeding it through the header is a common way to kill a board.
Serial is off by default, and the firmware has to bring up RP1’s UART without resetting RP1 out from under it. In /boot/firmware/config.txt:
enable_uart=1
enable_rp1_uart=1 # firmware inits RP1 UART0 @115200
pciex4_reset=0 # required companion -- do not reset RP1
dtparam=uart0_console # console to UART0 on the 40-pin headerRaspberry Pi OS’s cmdline.txt already carries console=serial0,115200, and dtparam=uart0_console is what points serial0 at the 40-pin header.
ls /dev/cu.usb* # find it
screen /dev/cu.usbmodem1101 115200Success is kernel messages ending at a login: prompt. Quit screen with Ctrl-A then k.
The device name encodes the USB port path, so it changes if you move the probe to another port or hub — re-run ls after any replug rather than assuming.
Reading it unattended Only one process can hold the port. To capture the console from a script instead of watching it, quit screen first — and note that macOS resets the baud rate when the descriptor closes, so a logger has to hold it open:
exec 3<>/dev/cu.usbmodem1101
stty -f /dev/cu.usbmodem1101 115200 raw -echo
cat <&3 >> serial.logThe probe is a USB device on the Mac, so it stays enumerated no matter what the Pi does — no reconnect logic needed, which is the usual reason people reach for tio over screen.
Worth knowing before relying on it. Pins 8 and 10 are RP1 UART0, and RP1 sits behind PCIe. From phase 3 onward, the moment a driver takes ownership of that PCIe controller the console moves out from under itself and the board goes silent — which is indistinguishable from a hang.
That is not a wiring fault and cannot be patched around: the console address depends on both the outbound window mapping and RP1’s BAR assignment, and bringing up the controller necessarily changes both. The fix is UART10, a PL011 inside the BCM2712 itself at 0x10_7d00_1000, which FreeBSD already attaches as uart0 on this board.
Solved · 2026-08-23 UART10 is reachable on a Pi 500+: there is a 3-pin JST-SH debug connector on the main board, above the 40-pin header. It had never been documented and was widely assumed absent. Moving the probe there gives a console that survives PCIe resets — and shows the boot ROM and SDRAM training, which this one never does. See The Pi 500+ internal debug connector.
The guide on this page stays the right starting point: it needs no disassembly and it carried phases 0–3. Move to the internal connector when you start touching PCIe.
Measured on a Raspberry Pi 500+, revision e04190, with a Raspberry Pi Debug Probe on macOS. The console this describes carried the whole of phases 0–3.