docs: execution-backend bring-up staged - ownership and firmware staging verified, real boot next

1 files changed, 24 insertions, 1 deletions

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 |