Files

T

History

felis f4bc28043a Support native SD storage and consolidate fds-flash tooling

Accept native SD cards for internal settings alongside legacy NVMe,
reject USB ancestry and ambiguous disks, and preserve read-only boot
loading with explicit recovery writes. Require built-in MMC drivers,
validate cached kernel configuration, and provide SD-only, SD-first and
USB-first EEPROM profiles.

Expose typed create and inspect commands through fds-flash, reuse the
existing cartridge creation code, and document the optional e2fsprogs
package dependency. Extend storage, EEPROM, flashing and hardware-test
coverage and advance the wiki reference to the published SD guide.

Validation: rootfs checks for CLI/development, boot matrix, internal
storage, EEPROM, flash, workstation, emulator, make check and wiki checks
passed. The full internal suite passed on an unchanged rerun after one
unexplained VM shutdown stall. Standalone init-test was blocked by its
unavailable pinned upstream kernel. Physical Pi checks remain pending.

2026-09-27 00:29:53 +08:00

.gitkeep

FDS/OS 1.0

2026-09-21 22:29:23 +08:00

README.md

update doc structure

2026-09-24 13:54:28 +08:00

session-template.json

Support native SD storage and consolidate fds-flash tooling

2026-09-27 00:29:53 +08:00

README.md

Physical acceptance records

Start with real-hardware setup on the assembled Pi. Then follow the complete procedure, including bay calibration, repeatable device populations, explicit SAFE handling and separate external timing measurements.

Copy session-template.json into a new results directory outside this source folder. Replace nulls with observed values, retain raw captures and hashes, and leave unperformed cases marked not_run. Record failures before attempting a fix. Do not fill this record from VM results.

For example, on the build workstation:

mkdir -p out/hardware-session
cp tests/hardware/session-template.json out/hardware-session/session.json

On FDS, copy tools/capture-hardware to DATA and run it explicitly through Bash. Use a fresh output directory each time; the usage guide explains volatile captures when DATA itself is under test. Copy the resulting files into the session directory after the test, preserving status.tsv and SHA256SUMS.

No file in this directory is evidence of a completed physical test until an actual run is recorded. The template's null values mean unknown, never zero.