Two sides of a model
Rehosting means running firmware away from its original board. That firmware still reads and writes peripheral registers, waits for inputs, and produces outputs. A peripheral model interprets those firmware-facing operations. The model’s other side needs an interface to a device model, a host resource, or another peripheral.
LibVIO’s API guide draws this division clearly. It describes a device model as an emulated peripheral loaded by an emulator, a slave model as a separate chip model on an SPI or I²C bus, and host-side resources such as terminals, files, and network interfaces. LibVIO supplies ways for those pieces to exchange data.
The firmware-facing register behavior belongs to a peripheral model. LibVIO supplies interfaces that model can use on the other side.
An I²C example
The guide includes an example bus configuration with a bme280 slave at address 0x76. Its sample slave code initializes register 0xD0 to 0x60, a chip ID value. A controller model can use LibVIO’s documented start, send, receive, and end operations to communicate with a configured slave.
The bus is one possible route. The slave is pluggable, so the controller model does not need the sensor’s behavior embedded in its own code. The guide also shows that a single slave library can keep separate state for multiple attached instances.
Other paths out
Not every peripheral connects to a bus slave. A UART model can use a pseudo-terminal for serial bytes. A network model can exchange frames through a TAP interface. LibVIO also documents FIFOs, files, analog inputs, signals, and DMA requests. The choice follows the interaction a model needs to reproduce.
Physical board access is a different responsibility. libhw provides a common interface for memory operations and flash programming through ST-Link, OpenOCD, and a mock backend. It is useful for work involving a target board; it is not the virtual I/O path in the conceptual sensor example.
What this establishes
The public LibVIO source and documentation establish these interfaces and examples. They do not, by themselves, demonstrate a complete firmware run through BoardRunner. The broader rehosting system and its FastDyn execution engine are described by the project organization, while their public repositories currently contain no implementation files.
For model work, the practical next step is the LibVIO API guide and its function reference. They define the available calls more precisely than this note can.