0x0LearnReferenceLibraries0x0.jmp0x1b.com

Direct Hardware Access And Bare-Metal Output

This page documents the bounded production evidence for direct hardware access

and bare-metal output in the native performance roadmap. It covers typed

volatile MMIO, register maps, memory barriers, bare-metal startup, vector

tables, linker memory maps, HAL/BSP boundaries, firmware image checksums,

secure-boot signing hooks, QEMU or equivalent deterministic emulator execution,

and fail-closed physical evidence intake.

Run the bounded gates with:


make bare-metal-check
make mmio-volatile-check
make firmware-image-check

These gates do not run the full release or self-host matrix. They validate the

source-owned hardware evidence listed below.

Evidence Files

MMIO And Volatile Access

hardware/native-mmio-register-map.tsv is the typed register map for the

current sim-cortex-m0 target. Register rows define address, width, access,

volatile requirement, capability, and reset value.

The verifier rejects:


NATIVE_HARDWARE_VOLATILE
NATIVE_HARDWARE_ORDER
NATIVE_HARDWARE_MMIO_WIDTH
NATIVE_HARDWARE_REGISTER

Volatile loads and stores must be preserved, must use an allowed register

width, must reference a register in the target map, and must keep the recorded

program order and barriers.

Bare-Metal Startup

Bare-metal startup evidence records:

The verifier rejects unsupported target features before a target can claim

bare-metal output:


NATIVE_HARDWARE_TARGET_FEATURE

The current target is sim-cortex-m0, with a thumbv6m-none-eabi profile and

source-owned linker script evidence in release/native-hardware-sim-cortex-m0.ld.

Firmware Images And Secure Boot

release/native-hardware-sim-cortex-m0.img is the tracked firmware image

artifact for the current emulated target. The image report records its size,

flash budget, checksum, reproducibility, and secure-boot signature manifest.

The verifier rejects unsigned or stale signature evidence:


NATIVE_HARDWARE_SIGNATURE

It also validates the tracked image size and checksum against the artifact on

disk, not only against copied report text.

Emulator Requirement

Every embedded target must have a QEMU or equivalent deterministic emulator

profile before any physical hardware claim can be accepted. The emulator row

records the emulator identity, version, command, timeout, stdout, trace hash,

and deterministic status.

The verifier rejects missing or nondeterministic emulator evidence:


NATIVE_HARDWARE_EMULATOR

The current target uses the source-owned 0x0-virtual-mcu-v1 equivalent

deterministic emulator profile. It is treated as emulator evidence, not as a

claim that a physical board was flashed.

Physical Evidence Intake

Repository defaults fail closed for physical readiness. A physical claim can

only be accepted when emulator evidence is verified, the physical evidence

bundle is verified, the root key is active, and the board evidence is within

the configured age budget.

The verifier rejects stale or incomplete physical claims:


NATIVE_HARDWARE_PHYSICAL_EVIDENCE

Physical evidence intake is still separate from external certification approval.

What This Does Not Overpromise

This page closes native performance Milestone 8 for the recorded emulated

Cortex-M0 target profile. It does not claim that a physical board was flashed,

that vendor certification was granted, or that later compile-time and final

release milestones are complete.