Firmware Boot and ROM

Firmware, Boot & ROM

xemu's boot path combines guest firmware images, QEMU memory regions, Xbox-specific LPC state, and a deliberate compatibility workaround for a physical CPU-cache behavior that is not modeled directly.

This page follows what the guest sees from reset until the MCPX boot-ROM overlay is disabled.

Address-space construction

xbox_flash_init() loads the configured BIOS image and maps it near the top of the 32-bit guest physical address space.

flowchart TD
    A[BIOS file] --> B[ROM MemoryRegion]
    B --> C[Map at 0xFF000000 region]
    C --> D[Mirror through top of 32-bit address space]
    E[Optional 512-byte MCPX boot ROM] --> F[Overlay near top of BIOS image]
    F --> G[Writable xbox.mcpx RAM-like overlay]
    G --> H[Higher-priority mapping while enabled]

Loading

The numerical guest address can therefore resolve to different backing memory depending on whether the MCPX overlay is still enabled.

BIOS loading

The BIOS size is expected to be a positive multiple of 65536 bytes. If the configured file cannot be loaded, current code prints a failure message and fills the allocated BIOS buffer with 0xff rather than immediately terminating machine construction.

That distinction is useful when diagnosing a machine that appears to start but never boots: the memory map can still exist even though the firmware bytes are invalid.

BIOS mirroring

The ROM image is aliased repeatedly through the expected high-address range. xemu uses QEMU MemoryRegion aliases rather than allocating independent copies for every mirror.

one BIOS backing region
    ↓
multiple read-only aliases
    ↓
guest sees mirrored firmware addresses

This is an address-decoding model, not a physical flash-chip bus simulation.

MCPX boot-ROM overlay

When a boot-ROM file is configured, xemu requires exactly 512 bytes and copies it over the final 512 bytes of the BIOS data used to seed the overlay.

The full overlay region is sized to the BIOS mapping for page-alignment/performance reasons even though the actual MCPX boot ROM content is only 512 bytes.

At reset the overlay has higher priority than the underlying BIOS mapping.

stateDiagram-v2
    [*] --> MCPXOverlayEnabled
    MCPXOverlayEnabled --> EarlyBoot: CPU reset vector / MCPX path
    EarlyBoot --> BIOSVisible: LPC config write disables xbox.mcpx
    BIOSVisible --> Running

Loading

xbox_lpc_reset() re-enables the MCPX overlay. A write to LPC PCI configuration register 0x80 with bit 1 set calls xbox_lpc_enable_mcpx_rom(..., false) and exposes the underlying ROM mapping.

Writable-ROM compatibility workaround

Physical retail 1.1+ boot code contains an early sequence that writes to an address in the ROM area and reads it back immediately. The real CPU's write-back cache can temporarily satisfy that read even though the physical target is ROM.

xemu does not emulate that exact physical cache effect. Instead, the active MCPX overlay is deliberately implemented as writable RAM-like memory.

flowchart TD
    A[Guest writes ROM address] --> B{Physical Xbox}
    B --> C[Write retained transiently by CPU cache]
    C --> D[Immediate read sees written value]

    A --> E{xemu}
    E --> F[Writable MCPX overlay stores value]
    F --> D
    D --> G[Boot continues]
    G --> H[Overlay later disabled; underlying ROM visible]

Loading

This is one of the clearest examples of xemu optimizing for guest-observed compatibility instead of literal microarchitectural fidelity.

A CPU-cache “accuracy improvement” that makes the overlay read-only again would be a regression unless it also reproduces the original cache behavior correctly.

Reset ownership

The boot-ROM overlay participates in device reset. A reset is not merely “set EIP to reset vector”; machine/device reset also restores chipset mapping state that affects which bytes the CPU fetches.

system reset
    ↓
CPU reset state
    +
LPC reset enables MCPX overlay
    +
device reset handlers restore platform state
    ↓
firmware fetches see reset-time map

This matters when debugging soft-reset versus cold-boot differences.

Firmware versus machine properties

xemu also exposes platform settings outside the BIOS image, including:

• boot ROM file;
• SMC version;
• A/V pack selection;
• video encoder selection;
• short-animation setting.

Those properties can change what guest firmware detects even when the same BIOS binary is used. A reproducible boot test should record them alongside the BIOS/MCPX hashes.

SMC challenge boundary

On physical hardware the SMC/PIC participates in a boot challenge. Current xemu SMC behavior returns a fixed request sequence and accepts response writes without implementing the full cryptographic/timing behavior.

The firmware path therefore contains both:

high-fidelity guest CPU/ROM execution
        +
semantic SMC security-device approximation

A boot ROM that deliberately tests challenge randomness/timing may behave differently from retail hardware even if normal kernels boot correctly.

See Board Management: SMBus, SMC & GPIO.

LPC configuration path

The Xbox LPC bridge is a PCI function. Guest configuration writes are processed by xbox_lpc_config_write(), which first updates standard PCI config space and then checks Xbox-specific controls such as the boot-ROM disable bit.

sequenceDiagram
    participant C as Guest CPU
    participant P as PCI config I/O
    participant L as Xbox LPC model
    participant M as QEMU memory map

    C->>P: CF8/CFC config write
    P->>L: xbox_lpc_config_write
    L->>L: pci_default_write_config
    alt Boot-ROM disable condition
        L->>M: memory_region_set_enabled(xbox.mcpx, false)
    end

Loading

This is a logical configuration transaction. There is no physical PCI/LPC bus waveform involved.

Flash behavior that is not modeled here

The normal boot mapping should not be confused with a complete electrical flash-programming model. The firmware regions are primarily used to present executable/readable boot data and overlays.

If a title/homebrew directly depends on erase/program timing, command sequences, bus contention or chip-specific write protection, verify the actual device path before assuming the ROM MemoryRegion reproduces those properties.

Missing/incomplete chipset behavior

Machine construction still contains:

FIXME: Stub the memory controller

and instantiates a pci-testdev for that function. Boot software that probes undocumented memory-controller behavior may therefore encounter a placeholder even though normal memory and firmware mappings work.

xbox_pci.c also contains disabled (#if 0) code for an Xbox 1.1-specific PMBASE behavior, documenting another known revision-specific area not active in the current implementation.

Boot debugging flow

flowchart TD
    A[Boot failure] --> B{Correct BIOS/MCPX files loaded?}
    B -->|No| C[Verify hashes/size/configuration]
    B -->|Yes| D{Failure before overlay disable?}
    D -->|Yes| E[CPU reset vector + MCPX mapping/cache workaround]
    D -->|No| F{Failure in chipset/device init?}
    F -->|PCI/LPC| G[xbox_pci / IRQ / config space]
    F -->|SMBus/SMC| H[SMC challenge / AV / board state]
    F -->|GPU| I[NV2A init]
    F -->|Storage| J[IDE / disk / optical]

Loading

Capture exact firmware files and machine properties before attributing a boot difference to CPU translation.

Snapshot considerations

Firmware bytes are static backing state, but mapping/overlay enablement is guest-visible chipset state. A snapshot restored in the middle of boot must reproduce the active mapping and device state expected at that point.

Likewise, host pointers into RAM/ROM or cached translated code are derived runtime state, not substitutes for serializing the relevant guest mapping/device state.

Source map

Source	Responsibility
hw/xbox/xbox.c	BIOS loading, mirrors, MCPX overlay creation, machine properties
hw/xbox/xbox_pci.c	LPC reset and boot-ROM overlay disable/config behavior
QEMU memory subsystem	ROM/RAM/alias mapping and priority
hw/xbox/smbus_xbox_smc.c	SMC boot-challenge approximation and board state
target/i386 / TCG	CPU reset/firmware instruction execution

Related pages

• MCPX overlay and a retracted boot theory — the external flash image was not necessarily the code fetched at reset.
• Xyclops serial freeze and chip variants — flashing behavior is chip-specific.
• System Architecture
• Memory & DMA
• Platform & I/O
• Board Management: SMBus, SMC & GPIO
• Hardware Fidelity & Emulation Boundaries