danielandClaude Fable 5
77940cf896
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 <[email protected]>
16 lines
439 B
C++
16 lines
439 B
C++
/*
|
|
* BuildNo.hpp
|
|
* Monotonic kernel build number.
|
|
*
|
|
* This file is the source of truth for the build number. It is regenerated
|
|
* (incremented) by scripts/bump-build.sh whenever the kernel or userspace
|
|
* sources change, via a rule in kernel/GNUmakefile. Do not edit the number
|
|
* by hand; the build system manages it.
|
|
*
|
|
* Copyright (c) 2026 Daniel Hammer
|
|
*/
|
|
|
|
#pragma once
|
|
|
|
#define MONTAUK_BUILD_NUMBER 29
|