Fuchsia Internals: A New Report Series for Hardware Engineers

July 25, 2026

I have been writing a set of technical reports on the internals of Fuchsia, Google’s capability-based microkernel operating system, aimed squarely at electrical, RTL, and FPGA engineers rather than at kernel hackers. This post kicks off a series in which I walk through the reports one volume at a time, roughly one a month. The whole set is a fourteen-volume reference; the complete PDF is linked at the bottom of this post, and each future post will take one volume and put its PDF in front of you.

A caveat, up front: these reports are auto-generated, so treat them as a map rather than gospel and take the specifics with a grain of salt. In my own reading they hold up well and read as generally correct, but verify against the source before relying on any one detail.

Regular readers will know that Fuchsia is my day job, and that I have been booting Zircon on a RISC-V soft core in an Artix-7 FPGA. Along the way I kept wanting a structural map of the system, one written for someone who already thinks in synthesizable blocks and handshakes, not one that assumes a lifetime of POSIX. Not finding one, I wrote it. These reports are compiled entirely from the public Fuchsia source tree and documentation at fuchsia.dev and cs.opensource.google/fuchsia; nothing here is insider knowledge, it is public material re-organized around a hardware reader’s mental model.

The one mental model

Fuchsia is a small kernel, Zircon, that exports a uniform set of kernel objects reached through unforgeable handles. Almost all of the operating system’s policy (drivers, filesystems, the network stack, graphics) runs in isolated user-space components. The whole series leans on one translation table between that world and the one an EE already knows:

  • A kernel object behaves like an IP block with typed ports.
  • A handle is a bus-grant token the requester cannot forge.
  • A channel is an AXI-Stream link: typed, ordered, flow-controlled.
  • A port is an interrupt aggregator collecting signals from many sources.
  • A VMO (Virtual Memory Object) is a DMA buffer descriptor whose physical backing the kernel manages.
  • The BTI and IOMMU together are a bus firewall confining a device’s DMA to explicitly pinned memory.
  • The scheduler is an arbiter granting CPU time.

These mappings are not decoration. They are the fastest route into the material if you already reason about registers, rings, and handshakes.

The volumes

The fourteen volumes were numbered in the order I wrote them, which is not the recommended reading order; the reports themselves suggest starting with the kernel (Vol. III) and the component framework (Vol. VI). But for this blog series I will walk them in numeric order, so that each post is a clean “here is one volume”. Here is the map:

  • Vol. I: Graphics & Display Pipeline. Magma, sysmem, the display coordinator, Flatland, and the Escher Vulkan renderer as a user-space pipeline of cooperating services.
  • Vol. II: The Build System & Toolchains. GN as an elaboration pass, Ninja as the runner, and the multi-toolchain model that compiles one source target many times.
  • Vol. III: The Zircon Kernel. Objects, handles, rights, the vDSO syscall ABI, VMOs/VMARs, the scheduler, channels, ports, and the hardware-access objects.
  • Vol. IV: Starnix. Running unmodified Linux and Android binaries directly on the CPU via Zircon restricted mode.
  • Vol. V: Graphics FIDL APIs in Practice. The wire-level companion to Vol. I: real FIDL declarations, sequence diagrams, and latch/fence effects.
  • Vol. VI: The Component Framework. Realms, CML manifests, and capability routing, components as module instances, routes as port maps.
  • Vol. VII: Driver Development in Practice (DFv2). How to land your own device: bind rules, the node topology, and turning MMIO, an interrupt, and a BTI into register access, an ISR, and pinned DMA.
  • Vol. VIII: Storage. From the block device’s DMA descriptor ring up through Fxfs and the Merkle-verified blob store.
  • Vol. IX: Power Management. The Power Framework as a user-space dependency graph, enables, rails, votes, and sequencing.
  • Vol. X: Networking. Netstack3, sockets, and the network-device descriptor rings that mirror the block protocol.
  • Vol. XI: FIDL. The interface language, its byte-and-handle wire ABI, and the bindings every other volume’s services speak.
  • Vol. XII: Software Delivery & OTA. Content-addressed packages, TUF repositories, and the A/B/R paver.
  • Vol. XIII: Diagnostics & Observability. Inspect, structured logs, tracing, metrics, and crash reporting, all gathered by the Archivist.
  • Vol. XIV: Security & Verified Boot. The closing synthesis: the object-capability model and the chain of trust from an eFuse key to a page fault.

What comes next

Next month I start at Volume I with the graphics and display pipeline. Each post will summarize a volume and link its individual PDF so you can read the whole thing. If you would rather not wait, the entire set is available now.

The combined PDF (this cover followed by all fourteen volumes in series order) is here:

If you have corrections or feedback, let me know, these are living documents.