From 6a580431c9b503a61bdde17d4a37903ff16d3bfe Mon Sep 17 00:00:00 2001 From: Arthur Hanson Rasmusson Date: Wed, 30 Sep 2026 23:12:09 -0400 Subject: docs: execution-backend bring-up staged - ownership and firmware staging verified, real boot next --- .../03-architecture/08-physical-gpu-integration.md | 25 +++++++++++++++++++++- 1 file changed, 24 insertions(+), 1 deletion(-) (limited to 'docs') diff --git a/docs/03-architecture/08-physical-gpu-integration.md b/docs/03-architecture/08-physical-gpu-integration.md index 06df22b..b1ade18 100644 --- a/docs/03-architecture/08-physical-gpu-integration.md +++ b/docs/03-architecture/08-physical-gpu-integration.md @@ -88,6 +88,29 @@ WPR2 setup, message queues in host system memory, doorbell, version exchange — the same observable stages the guest emulation already models, with the module now on the client side. +The bring-up is staged so each step is reversible and independently verified: + +1. **Ownership** — the distribution driver is released from the device and the + module binds it; BAR0/1/3 are mapped and the falcon state is sampled. On + release the module unbinds and the distribution driver is rebound, so the + host can always return to its normal driver. +2. **Firmware staging** — the matching GSP image (the same file the + distribution driver would load) is fetched and validated (ELF64 RISC-V; + the loadable image section, firmware version and hardware signature blob + are identified and held for the boot stage). No device state is touched. +3. **Boot** — a protected region is laid out in video memory (firmware heap, + image, boot binary, reserved areas), the secure-verification stage runs on + the security falcon to authorize it, the booter is then run on the + security falcon with the address of the boot metadata, and the GSP RISC-V + core is started; success is observed as an active RISC-V core plus the + firmware's resource manager completing initialization. +4. **Client** — the module speaks the already-mapped RPC protocol to the real + firmware as the client (section 4.3). + +Stages 1 and 2 are implemented in the module and verified live (a claim/release +cycle leaves the host driver working; the staged image parses as expected); +stage 3 is the current bring-up target. + ### 4.3 Host-side resource-manager client Using the wire protocol and RPC inventory already mapped for the supported @@ -139,7 +162,7 @@ per-context scheduling. Tenant policy and fairness are a later layer on top. |---|---| | Control plane (GSP boot emulation, RPC, BAR/PCI/MSI-X) | done | | Software-executed bridge for decoded memory/state operations | in progress (memsets, copies, releases) | -| Device ownership + real GSP bring-up by the module | not started (the early prototype is to be rebuilt under exclusive ownership) | +| Device ownership + real GSP bring-up by the module | in progress — reversible claim/release and firmware staging verified; the real boot stage is next | | Host-side resource-manager client for real objects/channels | not started | | Work translation and real submission | not started | | Completion relay through real hardware | not started | -- cgit v1.2.3