01 / SYSTEM
BoardRunner
The broader firmware rehosting system. Follow the repository for public system code and project updates.
Public repository currently empty Research & engineering / embedded systems
BoardRunnerFirmware Rehosting and
Cyber-Physical Simulation
Firmware expects a board around it. Rehosting runs that firmware away from its original hardware, so peripheral behavior and the surrounding environment must be represented too.
BoardRunner brings together work on execution, device models, virtual I/O, and physical hardware access to make those interactions available for study.
FIG. 01 THE REHOSTING BOUNDARY
01 / EXECUTIONFirmwarereads & writes registers
guest / host boundary
02 / EMULATIONPeripheral modelinterprets device behavior
virtual I/O boundary
03 / ENVIRONMENTDevice or hostreturns input, receives output
A conceptual map of the problem space. Individual workflows can use different components.
01 / AN INTERACTION
What has to cross the boundary?
A sensor read, unpacked.
Consider firmware requesting an I²C sensor register. The firmware sees its controller. A controller model can pass the transaction through LibVIO’s I²C bus to a pluggable sensor model, then return the response to the firmware.
CONCEPTUAL EXAMPLEBased on LibVIO’s documented I²C interfaces
Request: firmware → controller → LibVIO → sensor
Response: sensor → LibVIO → controller → firmware
01 / GUESTFirmware
Requests register 0xD0 through its I²C controller.
request →← response
02 / PERIPHERAL MODELI²C controller
Turns register activity into bus operations and presents the result back to firmware.
Model logicsend / recv →← byte
03 / VIRTUAL I/OLibVIO bus
Routes the I²C transaction to the configured slave at 0x76.
api_i2c_*transaction →←
0x6004 / DEVICE MODELSensor model
The API guide’s example slave returns chip ID 0x60 for register 0xD0.
.soVirtual I/O is the interface that lets emulated peripherals exchange data with host resources or other models. LibVIO documents pseudo-terminals, files, networking, signals, DMA, ADC, and SPI/I²C buses; a workflow uses the interfaces it needs.
02 / SYSTEM ORGANIZATION
Which piece does what?
One research direction.
Several working surfaces.
The public repositories expose supporting libraries and a QEMU fork. BoardRunner and FastDyn identify the broader system and execution engine, but their public repositories currently contain no implementation files.
Repository ↗
02 / EXECUTION
FastDyn
Execution engine in the BoardRunner ecosystem. Follow its repository for public engine code.
Public repository currently empty03 / VIRTUAL I/O
LibVIO
Standalone C library for connecting peripheral models to host I/O and to other models. Use its documented APIs when building device models.
Public source and API guide available04 / HARDWARE
libhw
Common hardware access and flash programming interface, with ST-Link, OpenOCD, and mock backends plus Python bindings. Use it for experiments involving physical targets.
Public source and usage guide available05 / EMULATION
QEMU fork
The organization’s fork of QEMU. Consult the fork directly for its source and history; this page does not attribute specific project changes to it.
Public fork03 / FROM THE DOCUMENTATION
An actual model interface.
LibVIO’s API guide shows how an I²C bus attaches a slave model. The address and shared-library path are configuration, not proof of a running BoardRunner system.
Read the LibVIO API guide ↗LibVIO / docs/API.mdDOCUMENTED EXCERPT
{"slaves": [
{"device": "bme280",
"address": "0x76",
"device_scroll": "build/bme280.so",
"config": {"chip_id": 96}}
]}0xD0 to 0x60. This is documentation, not a measured execution trace.04 / GET STARTED
Choose the boundary you need to work on.
Find your entry point.
Build a device model
Start with LibVIO’s API guide and function reference. The library builds independently of FastDyn and QEMU.
Talk to a physical board
Use libhw’s C API or Python bindings for memory access and flash operations through a supported backend.
Follow the broader system
Watch the BoardRunner and FastDyn repositories for future public implementation and documentation.
05 / FIELD NOTES
Writing from the project
Notes from
the boundary.
Short technical writing on rehosting, device models, and the interfaces between firmware and its environment.
All field notes ↗What virtual I/O has to carry
A closer look at the boundary between a peripheral model, LibVIO, and the device or host on the other side.
Read the note06 / COMMUNITYKeep the conversation
Keep the conversation
close to the hardware.
Discuss firmware rehosting, device models, virtual I/O, and cyber-physical simulation with researchers and developers working on related problems.
Join the Discord