A contributor's check archive matches the row exactly and passes
test_crash clean. test_ftl disagrees with the oracle on two logical
pages in one block - a second, distinct false positive from the
A5D5D589 x2 case: 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 documented in
test_ftl.c alongside the existing false positive.
Testing evidence: utils/ipodnano3g/RESULTS.md.
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Change-Id: Ib24d2df18e2b0e60e000ee6ea43bef9c214f7f72
A contributor's check archive matches the row exactly and passes both
host tests clean: test_ftl agrees with the oracle on all 3,964,928
sectors, test_crash survives 100 power cuts with 0 sectors wrong.
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Change-Id: I7c651c94332e0a04686ce8855a274735ae39546c
Four check archives (B614D5EC x2, A5D5D589 x2, A5D5D589 x4, 3E94D589 x2)
all match their table rows and pass test_crash clean. Three pass test_ftl
outright; A5D5D589 x2 disagrees with the oracle on two logical pages,
traced to _FTLRestore's own tie-break between two competing logs
(verified instruction-for-instruction against osos 1.1.3) - Apple's own
firmware would resolve the same medium the same way, so this is not a
defect. test_ftl.c gets a note explaining the false positive for future
archives that hit it.
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Change-Id: If8de0d6b1175981a292c5c45fbc092d5a6e0891a
A contributor's check archive for a 2-chip-enable A5D5D52C unit matches
the row exactly and replays clean against the host FTL suite. The row
moves in with the validated chips on this evidence alone - no on-device
write test has been run.
Testing evidence: utils/ipodnano3g/RESULTS.md.
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Change-Id: Ia9e00c0e880b10785da3ab52bc98dc93e94acfaf
The contributor NAND check tool went in before the driver changes that
followed it. This brings it up to the current tree.
Testing evidence: utils/ipodnano3g/RESULTS.md.
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Change-Id: Ie7712e0d7eaf75b880a9d134715ce1396a8545f8
The host-side tools the Nano 3G NAND driver and FTL were developed and
tested with, so the evidence in those changes can be reproduced and the
next chip can be added without rediscovering any of it: regdiff (register-
write comparison against Apple's sequencer programs), ftltest (the host
FTL test suite), chiptable.py, the FTL decode notes, and RESULTS.md, the
measurements the earlier changes quote.
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Change-Id: I321e06291ca393e18dbd5f71c2c6371fcda9a94d
Rockbox only drives NAND parts proven on hardware, and this tree has one
model to prove them on. This is the image that lets an owner of another
Nano 3G supply what validating theirs takes: a bootloader built with
-DNAND_CHECK and run from DFU, which never touches the NOR flash or
writes to the NAND.
Testing evidence: firmware/target/arm/s5l8702/ipodnano3g/TESTING.md.
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Change-Id: I46328b69f8011337790f35a195de97b5bcf347a5
Apple fitted at least five makers' NAND to the Nano 3G, in eighteen
chip and chip-enable combinations. Rockbox's Nano 3G NAND support can
only be enabled for writing on a chip that has been validated on
hardware, and so far one has. This gives owners of the others a way to
send what validation needs without installing anything.
nano3g-check.dfu runs from DFU mode (mks5lboot --dfusend). It reads the
chip ids on every chip enable, matches Apple's chip table, tries a
read-only mount, and shows a short summary. It then serves the raw NAND
over USB as a write-protected disk: sector 0 a text report, then 16-byte
spare records for every page, then page data. Nothing is written to the
iPod's NAND or NOR.
nandcheck.py collect finds that disk on Linux, macOS or Windows and
writes a few-MB archive: the report, every page's spare metadata and
read result, and every page that is not user data or erased (the FTL
and VFL control structures and Apple's bad-block records). It includes
no file contents and not the serial number. The README lists the chips,
how to tell which one an iPod has, and the procedure.
The image is the Nano 3G bootloader built with -DNAND_CHECK from the
Nano 3G NAND driver work, which is not merged yet.
Tested on a 4GB Nano 3G (Hynix A514D3AD x4): sent with mks5lboot
--dfusend, the disk appears within seconds, and collect reads it in 7
minutes with no ECC failures or timeouts. The archive mounts in the
driver's host FTL tests with every sector resolving to its newest copy.
AI provenance: developed with Claude Opus 5 (Anthropic), used through
Claude Code. The model wrote most of the code and this message under
Andrew Rice's direction. Any hardware testing described above was
carried out by Andrew Rice, who is responsible for this change.
Change-Id: Id790997768ee79451b7adeb5e9764dc8054faf4c
