/FIRMWARE · 2026-08-14
UART is a lab port, not a party trick
A header on a bench unit is inventory. We document console yes/no. We do not publish pinouts to brick other people’s gateways.
Firmware reviews sometimes include a lab unit. The dtb already said uart0. The silkscreen sometimes says it out loud. We attach a USB-UART adapter on that unit, at the baud the bootloader prints, and we write down whether we got a shell, a bootloader prompt, or noise.
Device from the customer, on the bench, named in the authorization. We do not walk a warehouse. We do not write “how to unbrick your ISP modem” for the internet.
What UART is for, here
- Confirm the boot chain we recovered from the image actually matches the unit.
- See whether the bootloader is quiet or offers a prompt.
- See whether the serial console is a login or a raw kernel log.
- Correlate “dropbear in the image” with “shell on the wire.”
If we get a shell
That is a finding if the product is supposed to be sealed. It is expected if the SKU is a development board. Context goes in the sentence. We do not then enable extra daemons “to help.” We photograph the header, note baud, note what we typed that was in-scope (usually: none; reading is enough).
If we get nothing
Also a result. Disabled in this build, different pins, or the dump was a different board. Write “no console on uart0 at 115200 on this unit.” Do not keep probing until something breaks.
JTAG and friends
Same rule, higher bar. If the letter does not name debug pads, we do not go hunting under the shield. If it does, we treat it as a documented lab interface: is the TAP open, does it halt the CPU, is that expected for this SKU. This is not a course in defeating fused parts.
How this combines
image: dtb lists uart0
unit: header present
lab: adapter, read-only session
report: console yes/no, bootloader prompt yes/no
— no public pin-by-pin cookbook
The image work still comes first. UART without an unpack is just a cable. Unpack without ever matching a unit is still valid — say you never had hardware.