# PFES-ENG-011 — Firmware Interfaces

**Status:** Active  
**Knowledge Cycle Stages:** Observe, Understand, Validate

## Purpose

Describe how firmware communicates with hosts, hardware, manufacturing systems, and external controllers.

## Engineering Problem

Optical-drive behavior depends on standardized protocols, vendor commands, MMIO, GPIO, interrupts, flash interfaces, timers, and external signals.

## Historical Engineering Evolution

Work began with SCSI and ATAPI command handling, then expanded as emulator and hardware work revealed GPIO, MMIO, timer, tray, and Xbox SMC interactions.

## Engineering Discoveries

- Standard protocols expose only part of behavior.
- External hardware state can determine firmware execution.

## Architectural Decisions

- Document interface behavior independently of implementation.
- Validate undocumented interfaces on real hardware.

## Knowledge Produced

- Command inventories
- Protocol behavior
- Signal models
- Register models

## Knowledge Consumed

- Firmware behavior
- Topology
- Hardware observations

## Current Engineering State

Current interfaces include ATA, ATAPI, SCSI, vendor commands such as 0xE7, MMIO, GPIO, interrupts, flash programming, and external Xbox SMC signals.

## Engineering Lessons

- Interfaces often explain behavior more directly than internal code.
- GPIO is necessary for some Xbox-related models.

## Negative Knowledge

Project Frankenstein no longer assumes:

- SCSI documentation fully explains vendor behavior.
- Firmware can be emulated without its external environment.

## Current Implementations

- Analyzer command mapping
- unlockdrive
- FriiDump
- MN103S emulator

## Future Implementations

- Formal interface schemas
- Signal-trace integration
- Additional transport families

## Open Questions

To be expanded during engineering review.

## Why This Chapter Exists

Firmware is a participant in a hardware and protocol system, not an isolated program.

## START STOP UNIT and Readiness Semantics

The current acquisition tooling uses:

- TEST UNIT READY (`00 00 00 00 00 00`) as a logical readiness poll;
- START STOP UNIT with START=1 and LOEJ=0 to request spin-up/start;
- START STOP UNIT with START=0 and LOEJ=0 to request normal spin-down without ejecting.

TEST UNIT READY does not prove that the spindle is physically rotating. A drive may report GOOD after an audible STOP UNIT spin-down. Tooling must therefore describe TUR as a logical command-readiness signal, not a literal spindle-state sensor.

After successful dump finalization, STOP UNIT is best-effort cleanup. Failure is a warning because image flush, commit, close, size verification, hashes, and sidecars have already completed.

## Patched-Firmware Unlock Bypass Is Not Authentication

`KickXboxMediaAuth()` must not be described as an authentication step, authentication recovery mechanism, or handshake accelerator.

Its actual behavior is:

1. send a custom vendor command;
2. patched firmware recognizes that command;
3. the firmware unlocks the Xbox partition directly;
4. no normal Xbox authentication handshake is performed.

The helper was experimental and was deemed unnecessary in Branch A.

Accordingly:

- the normal authentication implementation remains the canonical path;
- the bypass helper is optional and patch-specific;
- behavior observed through the bypass must not be used as proof that the real handshake succeeded;
- tests must distinguish handshake validation from patched-firmware unlock validation.

