The last update ended on an honest cliffhanger: USB core was up at 1.4 seconds, but the port scan still crawled and no keystroke had crossed the wire. This one closes it. On the Raspberry Pi 3B, keyboard, mouse, and Ethernet now all come up at about 7.7 seconds — before any screen paints — and @grio confirmed it on the metal. His words: "yup, it worked just now." NumLock lit on the real board.
What closed the keyboard
The remaining wall was the HID report path. The fix was an encoder correction — 0x8000C083 on the wire — turning raw transfers into real scancodes and real keys. Six of six enumeration chains came up clean on UART (A3=0 · O2=1 · KL=0), the mouse bound (KM3=1), and the LAN9514 Ethernet attached (ETH=0) — all on metal build 35ffdf86.
The boot order became a law
The deeper win isn't any one fix — it's why they all worked once reordered. The whole enumeration-crash class had one root: enumeration must run with the MMU on. Early in boot, before the cached MMU is live, peripheral MMIO is uncached and the reads that USB bring-up depends on simply don't behave. Run the same code after the MMU is up and it just works.
So it stopped being a per-board scramble and became a ratified boot order, folded into hal_boot: step 1 is MMU + caches; step 2 is all hardware (USB host → hub → HID → the 3B's LAN9514 NIC), then networking. The 4B and Pi 5 inherit that law rather than re-deriving it — the point of a HAL that's a first-class kernel subsystem, not a pile of board hacks.
FAST
All input + NIC alive at ~7.7 s, before the splash — the payoff of moving bring-up to first-thing at boot (USB core itself is up at 1.4 s).
EFFICIENT
One boot-order law in hal_boot instead of three per-board sequences; 4B and Pi 5 inherit it for free.
STABLE
Enumeration runs MMU-on, deterministically — the crash class that reset the board is gone at the root, not patched at the symptom.
SECURE
Bounded, ordered bring-up: the device stack is up and accounted for before anything else runs. No ambient hardware poking mid-session.
The honest last mile
Input on the 3B is real and @grio-seen. What isn't done yet: the complete full-OS image — the crash-loop park+print fix, the 3B HID, the full Lumen desktop, and all the apps in one build — is built green and deployed to the 3B rail (run 29245408825), but it is awaiting its confirming cycle on metal. Built and deployed is not the same as verified running, and we publish the milestone when the board proves it, not when the image compiles. One known caveat on this particular morning image: Ethernet won't be live on it — that's a follow-up fix already owned. The 4B and Pi 5 come next, inheriting the boot law.
Where the sprint stands
- USB / input (pillar ①): ✅ 3B keyboard + mouse + Ethernet up before the splash, @grio-confirmed on metal. Next: hotplug + a USB drive + a BT dongle on the 3B, then 4B/Pi5 parity.
- The Lumen desktop (pillar ②): content fixed and verified (apps populate, colors right, garbage rows and CLI resolved); the complete image is on the rail, one metal cycle from proving out.
- SRDX clients (pillar ⑤a): the macOS, Linux, and Windows remote-desktop clients are published and live (0.1.0 preview).