# Firmware handoff and device readiness Canonical: https://semiaifoundry.com/learn/atlas/firmware-device-contract/ Revision: 2026-10-07 Rights: https://semiaifoundry.com/ai-atlas/licenses.html Executable software · Atlas v1.3.0 # Firmware handoff and device readiness Separate device compatibility, driver discovery, resource ownership and queue readiness before any operand is consumed. [Explore in Atlas](https://semiaifoundry.com/ai-atlas/#firmware-device-contract)One process and device job; logical states and byte addresses, no timing or physical geometry Learning objectiveDistinguish the compatibility, discovery, resource and queue gates and identify the first gate that prevents a device job. ## The mechanism A powered accelerator is not yet a usable participant in a computation. Its interface must be recognized, its required resources must be available, and a driver must complete the device-specific readiness contract. Firmware and boot software can establish initial device state, but a compatible interface string does not prove who produced an image or whether it is trustworthy. This lesson deliberately begins with an advertised teaching ABI and follows how that claim gates later actions. The process can already own and populate host buffers while the device remains unavailable. Rejected compatibility leaves those values intact and produces no DMA or numerical output. The distinction matters during bring-up: silicon, an installed driver, a discovered function and a running command are different milestones. The execution trace makes each gate inspectable while leaving firmware loading, secure boot, attestation and physical reset release outside its scope. 1. The host process creates identified input and output buffers before it attempts a device job. 2. The device handoff advertises matrix-int32-v1 or an incompatible version; the model does not execute firmware code. 3. A recognized teaching device identity binds to a driver, and the register resource is claimed. 4. The assumed DMA addressing capability and queue setup are accepted before publication. 5. An incompatible ABI stops commissioning before any submission, device read or multiply-accumulate. 6. A later acknowledged device reset clears readiness and requires the contract to be established again. ## Science and assumptions ### The declared ABI gate $$ G_{\mathrm{ABI}}=\mathbf{1}[a_{\mathrm{device}}=a_{\mathrm{driver}}] $$ ABI gate equals one only when the advertised and required interface identifiers match. Symbols and units GABI Compatibility gate Boolean adevice Advertised ABI identifier string adriver Required ABI identifier string The model accepts one exact operation-interface identifier. Resource and queue gates remain separate after this comparison. Assumptions A declared symbolic interface contract, not image authentication, feature probing or proof of correct device behavior. ## Engineering example Keep A=\[\[1,2\],\[3,4\]\] and B=\[\[5,6\],\[7,8\]\]. With a compatible handoff, the later job can publish \[\[19,22\],\[43,50\]\]. Select incompatible ABI: the trace still shows the process input values, but submitted attempts, DMA read bytes and executed MACs are all zero. It publishes no C. Restoring compatibility permits the remaining gates to run; it does not by itself establish memory visibility, correct mappings or a correct completion. ## Distinctions and tradeoffs Matching a device interface identifies a supported contract; it does not verify a firmware image or establish end-to-end correctness. Adding interface versions can preserve compatibility only when negotiation and failure behavior are explicit. The current model chooses an exact single-version gate instead of emulating feature negotiation. Accelerator bring-up joins physical hardware to supported execution. A model framework depends on this lower interface being usable before tensor work can run. ## Specifications and interfaces Teaching ABI matrix-int32-v1 String equality is a compatibility test, not cryptographic verification. Scope of discovery One declared device/driver match No actual PCI configuration transactions or operating-system enumeration. Readiness outcome Queue ready or commissioning blocked Installed hardware is not counted as a completed job. ### Interfaces Declared runtime inputs Input Stable matrix job, buffer identities and the stated device/visibility contract Inspectable accepted or rejected result Output Event trace, actual buffer values and bounded completion/work ledger ## Check your understanding ### An ABI mismatch leaves host buffers populated. Has the device computed their matrix product? 1. Yes, because the driver is installed 2. No: no job was submitted or operands consumed 3. Yes, because populated memory implies DMA completion Answer and reasoning No: no job was submitted or operands consumed Host allocation and initialization do not execute the device command. ## Evidence and scope Primary sources establish the cited runtime mechanisms. Numerical values, address ranges, ABI strings, event schedule and reset/retry epochs are authored teaching contracts. No real device, firmware image, operating-system driver, page table, cache protocol or security verification is executed. The commissioning-execution-1 studio executes this bounded 2×2 matrix, buffer and completion contract. The surrounding atlas scene is conceptual; it is not a firmware emulator or system simulator. ## Sources - [Linux 6.16 — How To Write Linux PCI Drivers](https://docs.kernel.org/6.16/PCI/pci.html) - [OASIS — Virtual I/O Device (VIRTIO) Version 1.3](https://docs.oasis-open.org/virtio/virtio/v1.3/virtio-v1.3.html) [Published lesson data](https://semiaifoundry.com/ai-atlas/lesson-data/firmware-device-contract-af99231c7ca5e469.json) · [Atlas releases and licensing](https://semiaifoundry.com/ai-atlas/licenses.html) ## Continue exploring ### Foundations - [Runtime, driver and device dispatch](https://semiaifoundry.com/learn/atlas/runtime-device-dispatch/) - [Baseboard management controller](https://semiaifoundry.com/learn/atlas/management-controller/) ### Related lessons - [Process, physical and device address spaces](https://semiaifoundry.com/learn/atlas/process-dma-address-spaces/) - [Commissioning a usable AI cluster](https://semiaifoundry.com/learn/atlas/cluster-commissioning-gates/) - [Tapeout, bring-up and productization](https://semiaifoundry.com/learn/atlas/chip-tapeout-productization/)