The BT firmware download now runs from the idle loop after boot (zero boot
stall), completing the async goal. What made every earlier deferral attempt
fail was a months-latent HCI-layer bug, not the deferred environment:
WaitCommandComplete returned after the FIRST USB packet of an event, but
events larger than the 64-byte interrupt max-packet (like the AX211's
96-byte FC05 TLV version response) span several packets. Sending the next
command while the tail of the previous response was still in flight wedges
the AX211 bootloader into permanently ignoring commands. Boot-time flanterm
rendering added milliseconds between commands and accidentally paced the
protocol past the race -- which is why the synchronous bring-up always
worked and every log-suppressed (deferred) bring-up went mute at FC05 #2,
regardless of scheduling/MSI/xHCI fixes.
Fix: reassemble multi-packet Command Complete/Status events in the
transfer callback; the mailbox is marked ready only when the declared
event length has fully arrived. This inherently paces command flow and,
as a bonus, the TLV version read now sees the full response (sbe_type
present -> ECDSA/RSA selection is no longer a guess).
Also: per-slot EP0 completion tracking in the xHCI (a waiting ControlTransfer
can no longer be released early by another device's EP0 completion).
Verified on the AX211: instant boot, background download, real BD_ADDR.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Deferring the Intel BT firmware download off the boot path made the AX211
bootloader stop answering after the first FC05; even the final synchronous
revert freezes boot, so one of the 'neutral' fixes kept in this diff breaks
the bring-up on its own (candidates: BT-TRACE logging inside TransferCallback,
unconditional interrupt-IN re-queue after error completions on a halted EP,
xHCI interrupt-IN ZLP len fix interacting with HID, InPollContext owner
check). Full history + next experiments in memory notes, 2026-07-05/06.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
daniel
