len0rd/rockbox
1
0
Fork 1
mirror of https://github.com/Rockbox/rockbox.git synced 2026-10-10 08:03:04 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

ipodnano3g: mark the 4-CE B614D5EC row checked

Browse source 
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
This commit is contained in:
Andrew Rice 2026-09-21 21:53:52 +10:00
parent 413f17b8ce
commit bd24fddb7e
3 changed files with 33 additions and 10 deletions
Download patch file Download diff file Expand all files Collapse all files

2
firmware/target/arm/s5l8702/ipodnano3g/nand-nano3g.c
View file

@ -126,7 +126,7 @@ static const struct nand_chip_info nand_chip_table[] =
* write test. */
/* Micronas (ITT Intermetall, acquired by TDK 2016): 0xEC, not Samsung */
{ 0xB614D5EC, 2, 8, 4096, 128, 4096, 3872, false }, /* checked */
{ 0xB614D5EC, 4, 1, 4096, 128, 4096, 3872, false },
{ 0xB614D5EC, 4, 1, 4096, 128, 4096, 3872, false }, /* checked */
{ 0x2555D5EC, 4, 9, 8192, 128, 2048, 7744, false },
/* Hynix */
{ 0xB614D5AD, 4, 1, 4096, 128, 4096, 3872, false },

9
utils/ipodnano3g/RESULTS.md
View file

@ -64,3 +64,12 @@ fault testing.
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`).

32
utils/ipodnano3g/ftltest/test_ftl.c
View file

@ -8,15 +8,29 @@
* position in its superblock. Every lpn the FTL resolves must land on the
* oracle's copy (or, where copies tie, on one with identical data).
*
* Known false positive: when two logs for the same logical block each hold
* pages the other lacks, _FTLRestore's own tie-break (0x806a19c in osos
* 1.1.3, matched here instruction for instruction) keeps the more complete
* one whole and drops the other entirely, even if the dropped one is newer
* for some of its pages. ftl_read() then disagrees with this oracle on
* exactly those pages - correctly, since that is what Apple's own firmware
* would also resolve to on the same medium. A handful of disagreements
* confined to one or two logical blocks on a real contributor's dump is
* this, not a bug; wholesale disagreement is not.
* Known false positive #1: when two logs for the same logical block each
* hold pages the other lacks, _FTLRestore's own tie-break (0x806a19c in
* osos 1.1.3, matched here instruction for instruction) keeps the more
* complete one whole and drops the other entirely, even if the dropped one
* is newer for some of its pages. ftl_read() then disagrees with this
* oracle on exactly those pages - correctly, since that is what Apple's
* own firmware would also resolve to on the same medium.
*
* Known false positive #2: a superblock whose last page reads
* SPARE_DATA_LAST is classified a closed data block from that one page
* alone ("closed blocks -> map" in decode/APPLE-FTL-WRITE.md) and every
* lpn in it is then addressed purely by position, offset == lpn % sbpages,
* with no per-page check. If one physical page in such a block is stale -
* left over from before the block closed, still carrying an older lpn's
* spare - the oracle credits that spare's lpn with the newest copy at the
* position it actually holds data, while the FTL (like Apple's own
* firmware) trusts the position instead: it lands on the stale page for
* the lpn that owns that spare, and finds nothing at the position the
* oracle expected for the lpn that really belongs there.
*
* Both are confined to a handful of pages on one or two logical blocks on
* a real contributor's dump; wholesale disagreement is not either of
* these, and is a bug.
*/
#include <stdio.h>
#include <stdlib.h>