NAND ECC Strength and Page Geometry: Check Controller Compatibility Before Substitution

Approve a NAND substitution only when its addressing geometry, correction requirement, spare-area layout, and error-reporting behavior fit every reader and writer in the product. Matching capacity and package is insufficient. A clean read on a new device can conceal an unsupported correction configuration.

This procedure covers host-managed NAND integration, including the different ownership model of SPI NAND with on-chip ECC. Linux v6.12 provides the software examples. Alliance Memory’s AS5F32G04SNDA/AS5F34G04SNDA datasheet, revision 1.2, October 2024, provides one concrete media example. No controller/device pair is approved here; exact controller documentation, boot-ROM restrictions, and deployed driver evidence remain required.

1. Identify where correction actually happens

For host ECC, record the algorithm, data bytes per correction step, supported correction strengths, parity bytes, and parity placement. For on-chip ECC, record the enabled mode, protected regions, spare-area restrictions, and status decoding. Do not compare an on-chip capability label directly with a host-controller strength setting as if they described the same data path.

Linux 6.12 represents NAND ECC capabilities through step sizes, supported strengths, and a driver calculation of parity bytes. Its raw-NAND configuration checker verifies a selected step/strength pair and whether the required parity fits available OOB space. See the versioned NAND ECC interface and v6.12 implementation.

Keep correction strength distinct from parity storage. “Eight-bit correction” and “eight ECC bytes” are different quantities. Also keep total page size distinct from the protected data-step size: correction operates over the documented unit, not an arbitrary average across the entire device.

2. Fill a compatibility matrix with evidence, not checkmarks

Property	Media evidence	Controller/software evidence
Main page and spare size.	Exact part and revision geometry.	Addressing, DMA/buffer limits, and exposed layout agree.
Pages per eraseblock and total organization.	Datasheet organization and address fields.	No truncation, aliasing, or unsupported target selection.
Correction step and strength.	Required mode or on-chip capability and conditions.	The actual selected engine supports the applicable tuple.
Parity and metadata layout.	Protected, reserved, and available spare regions.	Parity, bad-block markers, and platform metadata do not collide.
Read-error reporting.	Meaning and update point of each status class.	Corrected and uncorrectable results survive driver translation.
Boot and manufacturing format.	Allowed access modes and device identification.	Programmer, ROM, bootloader, and kernel interpret compatible bytes.

Every cell should contain a document section, source revision, observed effective setting, or explicit unknown. “Linux supports NAND” is not evidence for a particular controller’s ECC engine. “The chip was detected” does not prove that boot firmware and the kernel agree on the stored format.

3. Use the device example without generalizing it

The cited Alliance Memory Rev.A datasheet lists 2,048 main bytes plus 128 spare bytes per page and 64 pages per block for the named family. It describes eight-bit ECC and a specific division of protected metadata and internal parity space. Those are properties of that family and revision, not defaults for all SPI NAND.

Do not treat all 128 spare bytes as freely writable metadata. Inspect the datasheet’s ECC-enabled access restrictions and the selected driver’s OOB layout. An existing image may encode metadata or parity differently even when its main-area payload length looks correct.

This example also illustrates why the complete part suffix matters. A software table for a similarly named earlier device is not sufficient substitution evidence. Resolve identification and mode differences before trying to make the replacement pass by suppressing an error or disabling correction.

4. Check the spare-space arithmetic and the supported tuple

For a documented host-ECC layout, calculate the number of correction steps per page, multiply by parity bytes per step, then compare with the OOB space actually available to that engine. Account separately for markers, metadata, reserved bytes, and any placement restrictions. Arithmetic feasibility is necessary but does not prove that the controller can generate the required format.

For a deliberately hypothetical example, a 2,048-byte page divided into 512-byte steps has four steps. If an imagined supported configuration needs 16 parity bytes per step, it needs 64 parity bytes. A layout offering only 48 usable parity bytes fails before hardware testing. These values are invented arithmetic inputs, not specifications for the Alliance device or a real controller.

Conversely, enough space does not establish compatible correction behavior. Do not normalize two different step sizes into “bits corrected per kilobyte” and use that ratio as the sole approval criterion. Use the media requirement and the selected engine’s supported configuration, including its code and placement rules.

The v6.12 raw-NAND chooser can fall back to maximizing the available ECC configuration when matching requirements fails. Inspect the resulting settings and diagnostics; successful configuration selection is not, by itself, evidence that the media’s documented requirement was met.

5. Qualify geometry and reporting on disposable fixtures

1. Preserve existing storage images, per-unit factory evidence, and recovery access before any programming test. Use approved test units or an emulator, not irreplaceable production data.
2. Write and verify known patterns through the intended supported path at page, eraseblock, and target boundaries.
3. Confirm that addressing does not alias higher locations onto earlier ones, especially when density or target organization changes.
4. Use a supported software or controller fault fixture to exercise corrected and uncorrectable reporting. Do not attempt to create physical defects by uncontrolled stress.
5. Compare recovered bytes with an independent reference; a “corrected” status alone is not the payload oracle.
6. Verify that uncorrectable data is not silently accepted by the filesystem, updater, or boot path.
7. Repeat relevant reads through every stage that consumes the stored image, including manufacturing verification and boot firmware.

These tests are proposed and were not executed for this article. A parser or ECC model can qualify software translation; it does not prove electrical timing, retention, endurance, or the behavior of the actual NAND/controller pair.

Make the substitution decision explicit

A hypothetical purchasing review finds equal density and page size, but the replacement’s required correction mode is absent from the bootloader configuration. The kernel can read a freshly programmed sample, so the team is tempted to approve it. The matrix instead holds the substitution until the boot path and error-handling contract are resolved.

Release only with the exact media and controller revisions, selected ECC tuple or on-chip mode, usable spare layout, compatible image-format evidence, and reporting tests. If any of those is unknown, the correct result is an incomplete compatibility assessment, not an interchangeability claim.