Raw NAND Bad Blocks: Preserve Factory Markers Through Manufacturing and Updates

Preserve factory bad-block information before any NAND programming or erase operation. Manufacturing tools, bootloaders, operating-system drivers, and update software must agree on where that information lives and how it remains excluded from ordinary image writes. A successful firmware verify does not prove that the device’s bad-block evidence survived.

This checklist concerns host-managed NAND, including SPI NAND whose on-chip ECC does not remove the host’s bad-block-management responsibility. It does not describe managed eMMC storage. The device example is Alliance Memory’s AS5F32G04SNDA/AS5F34G04SNDA family, datasheet revision 1.2, October 2024. Linux v6.12 sources illustrate software ownership; they are not proof of support for every device suffix or controller.

1. Obtain the exact marker contract

Section 13 of the Alliance Memory Rev.A datasheet says to inspect the first spare-area location of the first page of each block for non-FFh data before program or erase operations. That is a device-specific rule. Do not copy a marker byte, page selection, or bus-width assumption from another NAND family.

Record the complete part number, silicon revision, page and spare sizes, marker locations, required read mode, and any ECC interaction. Add the selected controller’s reference-manual revision and driver configuration. If the acquisition tool hides or transforms spare bytes, document how its output maps back to the physical marker locations. Without that mapping, stop before a destructive operation.

The Linux 6.12 NAND documentation explains why marked bad blocks must not be erased: their bad-block information can be lost. A later erase test is not a substitute for the original factory classification.

2. Separate markers, tables, and image content

A physical marker is evidence stored at a device-defined location. A bad-block table is a software representation of block status and may be maintained in RAM or flash. A logical firmware image is payload intended for usable storage. They have different owners and should not be merged into an unexplained whole-chip copy.

Document whether each tool expects a logical image, a physical main-area dump, or a main-plus-spare dump. Also document whether it skips bad blocks, inserts ECC, relocates payload, or preserves reserved table blocks. The same file length can have different meanings under different programmer modes.

Bad-block maps are unit-specific. A map acquired from a reference board does not establish which blocks are usable on another device. Manufacturing may share the logical payload, but it must honor each unit’s own physical exclusions and the platform’s approved mapping policy.

3. Assign an owner at every handoff

Stage	Evidence required	Release blocker
Incoming device inspection	Part identity, raw marker scan, read errors, and unit-associated scan record.	Programming begins before a trustworthy scan.
Production programmer	Versioned algorithm, image mode, bad-block exclusion behavior, and spare-area policy.	A generic full-chip erase or image write can destroy marker/table regions.
Bootloader	Its marker scan, ECC layout, payload placement, and table ownership.	It interprets physical addresses differently from manufacturing.
Kernel driver	Matched device ID, exact driver source, controller configuration, and bad-block reporting.	Similar part naming is treated as compatibility evidence.
Field updater	Logical update scope, reserved-region protection, and interrupted-update behavior.	It restores a reference unit’s physical spare data over the target’s evidence.

Where an on-flash bad-block table is used, identify who may update it and how interrupted updates are recovered. The Linux documentation describes several table policies, including mirrored and versioned tables; their existence does not mean every platform enables the same policy. Verify the deployed implementation.

4. Inspect software reservations as well as the datasheet

The Linux v6.12 SPI NAND core has explicit raw out-of-band marker reads and separate bad-block operations. The Alliance Memory driver in that release reserves the first two spare bytes from its free-area layout and identifies a particular AS5F34G04SND entry. This is implementation evidence, not permission to treat the newer Rev.A part as an interchangeable match.

Compare the actual device identification and supported table entry before applying any layout assumption. Reconcile discrepancies between programmer output, bootloader interpretation, and kernel reporting. A controller may expose spare bytes through a different path from ordinary data reads; its documented behavior and the active driver must be included in qualification.

Keep uncertainty visible. If the tool cannot distinguish a failed marker read from an erased marker, the scan is incomplete. Do not classify the block as good merely to let the manufacturing line continue.

5. Qualify preservation on controlled hardware

Use approved test units and retain their initial evidence. Do not deliberately erase factory-marked bad blocks to test whether the marker is recoverable. Test the preservation policy by observing that the tools exclude those regions and by comparing pre- and post-operation evidence through a validated read path.

1. Capture a per-unit marker map and relevant raw spare evidence before provisioning.
2. Record the programmer configuration and exact logical payload revision.
3. After provisioning, compare original bad-block exclusions, reserved regions, and the bootloader’s interpretation.
4. Boot the intended kernel and reconcile its block status with the earlier evidence.
5. Exercise the ordinary update and rollback paths on test units, then repeat the comparison.
6. Inject interruptions through the supported test mechanism and verify that table ownership and exclusions remain coherent.
7. Use emulation or an approved fault fixture for grown-bad-block handling; avoid destructive attempts to manufacture physical defects.

Keep read errors, corrected-data observations, and bad-block classifications separate in the report. In the cited datasheet, program or erase failure status can also reflect invalid or protected operations. Investigate the actual cause instead of converting every failure directly into a permanent retirement decision.

Hypothetical manufacturing review

A production team proposes copying a golden device’s complete dump, including spare data, onto every unit. The firmware checksum would verify, but the plan has no per-unit marker scan and no explanation of reserved-table handling. The review rejects the procedure before programming.

The revised plan identifies the logical payload separately, captures each unit’s initial marker evidence, and qualifies the programmer, bootloader, and kernel against the same ownership checklist. This hypothetical example does not claim a particular tool supports those steps automatically.

Release the process only when the device-specific marker rule, controller read path, and every writer’s preservation behavior are documented and verified. If factory evidence has already been overwritten, quarantine the unit for an approved disposition rather than claiming that a new filesystem format restored its original reliability classification.