rockbox/utils/ipodnano3g/RESULTS.md

Nano 3G storage validation results

Results below were recorded on 2026-09-13. Hardware results used a 4 GB Nano 3G with Hynix NAND ID 0xA514D3AD.

Host tests

• The independent newest-page oracle agreed with ftl_read() for all 1,982,464 logical sectors in the device image.
• Read/write, wear-level, bad-block injection, allocation eligibility, restore and mock-NAND suites completed without failures.
• Power was cut at 300 operation boundaries in each of 48 deterministic campaigns. Half modeled a torn page program or half-completed erase. All acknowledged writes survived each remount and no page was programmed twice or out of order.
• The 600-file write replay retained 66,388 copy-merge reads and 34,816 delete-merge reads. Batched reads reduced these to 528 and 280 controller calls respectively, averaging 125.7 and 124.3 pages per call.
• Driver and emulator register traces were identical in all write scenarios: one page, single-plane rows, repeated-bank pages, and one through three two-plane rows.
• Driver and emulator register traces were identical for one read, four-bank reads, repeated-bank reads and a mixed duplicate-bank split.

Hardware tests

• A complete NAND dump produced 184 VFL context pages that all passed the format's checksums.
• Rockbox mounted and restored the uncommitted state left by Apple disk mode.
• A 77,067,368-byte, 600-file tree written through Rockbox read back with all SHA-256 hashes intact through both Rockbox and Apple disk mode.
• The same tree read at 7.550 MB/s through Rockbox USB and 9.745 MB/s through Apple disk mode. Rockbox wrote and synced it at 0.731 MB/s; Apple wrote and synced it at 1.026 MB/s.
• A setting survived reset and restore, and Apple firmware subsequently read the volume successfully.

Bad-block remapping and forced program/erase failure recovery have extensive host fault-injection coverage, including validation of the persisted remap after remount. They have not been deliberately triggered on hardware. The implemented layout and recovery order follow the decoded Apple FTL/VFL process documented in decode/APPLE-FTL-WRITE.md; that correspondence is evidence for the implementation, not a substitute for destructive hardware fault testing.

Later additions

• NAND check tool update, 2026-09-17. The rebuilt check image reads a 4GB unit with no ECC failures or timeouts; two independent collections from it agree byte for byte.
• 2-CE Micron A5D5D52C, enabled 2026-09-18. A contributor's check archive matches the table row exactly, including a derived vflspares of 89. Replayed against the host suite: test_ftl agrees with the oracle on all 1,982,464 sectors; test_crash survives 100 power cuts (172 writes, 6 syncs, 0 sectors wrong). No on-device write test.
• B614D5EC x2, A5D5D589 x2/x4, 3E94D589 x2, 2026-09-19. Four contributors' check archives all match their rows and pass test_crash clean. test_ftl passes three outright; A5D5D589 x2 disagrees with the oracle on two logical pages - confirmed against Apple's own disassembly (_FTLRestore, osos 1.1.3) to be that algorithm's own tie-break between two competing logs, not a defect (see the note in ftltest/test_ftl.c).
• BA94D598 x4, 2026-09-20. A contributor's check archive matches the row exactly (Toshiba, mode 1, vflspares 201 by our own formula). Clean on both host tests: test_ftl agrees with the oracle on all 3,964,928 sectors; test_crash survives 100 power cuts (344 writes, 11 syncs, 0 sectors wrong). No on-device write test.
• B614D5EC x4, 2026-09-21. A contributor's check archive matches the row exactly (mode 1, vflspares 201 by our own formula). test_crash is clean (100 power cuts, 349 writes, 9 syncs, 0 sectors wrong). test_ftl disagrees with the oracle on two logical pages in one block; traced to a second, distinct false positive from the one already documented for A5D5D589 x2 - a closed data block addressed purely by position, with one stale leftover page - confirmed against the decode notes (_FTLRestore's "closed blocks -> map" step) and not a defect (see ftltest/test_ftl.c).