Linux drivers on simulated hardware
Yocto + QEMU EDU Lab
A hands-on lab for building Linux images and learning how drivers communicate with simulated devices on two processor architectures.
Educational lab. A separate ARM64 exercise uses a different device. Simulation does not verify physical electronics.
USER SPACE writes 5
↓
LINUX DRIVER MMIO offset 0x08
↓
QEMU DEVICE computes 5!
↓
PCI INTERRUPT wakes the driver
↓
USER SPACE reads 120Latest verified change · A009 / PR #15 ↗ · Merged
Independent PCI and ARM64 learning paths
Closed lab manifests now separate x86-64 PCI MSI/INTx and bounded DMA from an ARM64 Device Tree and platform-driver path. The ARM64 peripheral has its own hardware contract and does not expose DMA.
Source checked . Documentation and retained evidence review, not a new runtime test.
Read change evidence ↗Documented example / 19 September 2026
Follow 5! from a Linux command to a virtual device.
The PCI lab makes a driver interaction visible: a command writes a value, the virtual device calculates it, and an interrupt tells the driver the result is ready.
How does a Linux request reach a virtual device?
A small calculation connects user space, a Linux driver, memory-mapped registers and a virtual interrupt.
Expected output and operation sequence transcribed from the pinned README. No new QEMU run or physical hardware test is claimed.
In plain terms
Ask a simulated device to calculate a factorial and follow the request through a Linux driver.
Why it matters
A driver connects software to a device. This lab makes that connection visible, so hardware discovery, requests and responses can be studied together.
Follow the example, step by step
Build a Linux image
Package the driver and test program into an image that runs in QEMU, a hardware simulator.
Send a request
The test program asks the PCI example device to calculate through the driver.
Follow the response
The simulated device reports completion and the driver makes the result available.
Share the build foundation without merging device contracts
Documented approach
The PCI and ARM64 platform paths share locked inputs and wrapper tooling, while each manifest owns its machine, driver, runtime suite and evidence profile.
Alternative and scope
The architecture explicitly avoids treating the ARM64 peripheral as an adaptation of the PCI EDU ABI. Its platform device and evidence schema remain independent.
Cost of the choice
Separate interfaces and schemas preserve the lessons each lab teaches, but require profile-specific checks. The source lock establishes metadata identity, not byte-identical output or runtime success.
What the evidence establishes
The pinned architecture states that a full image/runtime pass requires execution on an adequate Linux host. No new Yocto image build or physical-hardware test was performed for this profile.
Read the decision source (opens in a new tab)Shared build inputs, independent hardware
The two lab manifests share locked sources and an image target, but define separate hardware contracts. The ARM64 path does not inherit the PCI ABI or expose DMA. QEMU evidence is not physical-device qualification.
Follow the interface end to end
The default x86-64 lab adds QEMU's EDU PCI peripheral, an out-of-tree kernel module, a userspace test package, and a custom minimal image. A separate ARM64 lab uses a project-local SysBus peripheral, generated Device Tree node, and managed platform driver.
- PCI matching and MMIO, MSI-preferred or explicit INTx policy, and bounded DMA round trips
- sysfs controls, automatic module loading, and a userspace validation utility
- Manifest-selected setup, runtime tests, SPDX image evidence, and isolated direct-eSDK sample iteration
One operation exposes the whole stack
The PCI factorial exercise starts in userspace, crosses a sysfs driver attribute, writes an MMIO register, waits for QEMU's asynchronous result, and handles the selected virtual interrupt. The ARM64 path separately exercises bounded scratch and IRQ controls rather than reusing the PCI ABI.
That narrow path makes driver registration, hardware discovery, matching, memory-mapped I/O, interrupt handling, packaging, and image composition visible as one system.
Simulation is a first step, not physical proof
The project states the limits of its evidence: QEMU cannot validate electrical behavior, clock and reset sequencing, pin multiplexing, analog interfaces, physical DMA coherency, interrupt wiring, or silicon errata.
Project scaffolding and documentation use MIT licensing; the example kernel module and its build file use GPL-2.0-only, with file-level SPDX identifiers defining the boundary.
Compare PCI and platform contracts
Choose a boundary to compare the lab’s x86-64 PCI and ARM64 platform paths. These are selected device compositions; CPU architecture does not determine bus type.
Discovery
Who tells the driver that the device exists?
- x86-64 PCI lab
- PCI enumeration and device ID matching lead to probe.
- ARM64 platform lab
- A generated Device Tree node describes the platform device.
Registers
Where does the register range come from?
- x86-64 PCI lab
- The driver maps the device's BAR MMIO resource.
- ARM64 platform lab
- The driver maps the MMIO resource described for this device.
Interrupts
Which interrupt contract must the driver acknowledge?
- x86-64 PCI lab
- The selected lab uses MSI or an explicit INTx policy.
- ARM64 platform lab
- The independent peripheral exposes one level interrupt.
DMA
Which capabilities actually belong to this peripheral?
- x86-64 PCI lab
- The PCI exercise includes a bounded DMA round trip.
- ARM64 platform lab
- This teaching device has no DMA surface.
Each lab needs its own runtime evidence. This explorer runs no device; virtual results do not qualify physical hardware.
Read the comparison and pinned sources →Related writing
Related updates
Inspect the checked source
Evidence reviewed . Individual decisions and captured examples retain their own source revisions and limitations.
Read the checked README (opens in a new tab)