[PATCH v2 0/3] mtd: rawnand: sunxi: support the Allwinner randomized OOB format
From: James Hilliard <hidden>
Date: 2026-09-04 21:23:54
Also in:
linux-arm-kernel, linux-sunxi, lkml
The sunxi NAND driver applies page randomization from its normal hardware-ECC page callbacks. Each page starts from a page-dependent seed. When protected OOB bytes are transferred separately, the driver uses precomputed randomizer states advanced according to the ECC step size. Erased-page detection and its physical-data fallback also live in these callbacks. Randomization is therefore part of the driver's hardware-ECC page format rather than an independent MTD access mode. MTD_OPS_RAW continues to bypass both ECC and randomization and exposes physical main and OOB bytes. The mainline format compensates the bad block marker before writes and after reads so that it remains plain on flash. On H6 and H616 it also fills the OOB space left after ECC with protected user data. Allwinner NAND firmware instead leaves the marker in the randomizer data stream and, on H6 and H616, uses a fixed protected user-data placement. These choices produce incompatible physical OOB layouts. The Allwinner BSP implementations for the SoCs covered by the two older mainline compatibles (sun4i, sun5i, sun7i, sun8iw3 and sun8iw5) likewise pass their protected user-data words to the controller unchanged while page randomization is enabled. Their 128-entry seed tables match mainline, and those controllers have the same fixed four-byte-per-step user-data layout, so only the marker handling differs on those generations. Add allwinner,randomized-oob to select the firmware's normal-page format for the configured controller hardware-ECC geometry. The property marks the NAND as requiring scrambling for normal hardware-ECC transfers, omits the marker compensation, and selects the controller-specific protected user-data placement. H6 and H616 use four protected bytes per 1 KiB ECC step, capped at 16 bytes, with the complete protected region placed before the first ECC step. Older controllers keep their already matching fixed user-data placement. Assuming the standard ECC geometry is configured to match the media, these choices make normal reads and writes compatible with BSP-derived images. The property does not change the per-operation raw-access behavior. Raw accesses continue to return the physical representation, including a randomized marker when that is what the firmware format stores. A physical marker cannot be both plain and compatible with firmware which stores it randomized. Normalizing only the marker in MTD_OPS_RAW would make the result non-physical, while enabling full-page de-randomization would make it a decoded access rather than a raw one. Preserving both the firmware format and existing raw semantics therefore requires raw access to expose the randomized physical marker. The raw-NAND core's bad-block and flash-BBT paths remain on decoded accesses: nand_block_bad() uses ecc.read_oob(), OOB scans use MTD_OPS_PLACE_OOB, and BBT data reads use mtd_read(). They therefore receive the logical marker and BBT contents through the hardware-ECC/randomizer path. When the property is absent, retain the existing mainline marker handling and H6/H616 maximized OOB layout. Tested on an H616 board with a Toshiba TC58NVG1S3H NAND using matching Linux and U-Boot implementations. Linux initialized the NAND, SPL and U-Boot cold-booted from it, U-Boot loaded the FIT from UBI, and Linux attached the same UBI with 2004 good PEBs, two bad PEBs and no corrupted PEBs. A target-timed 64 MiB read through /dev/mtd6 completed without reported ECC, timeout or I/O errors. Validation completed with strict checkpatch, dt_binding_check and an arm64 W=1 object build. Assisted-by: OpenAI Codex (gpt-5.6-sol, max) Signed-off-by: James Hilliard <redacted> --- Changes in v2: - rebase on the current MTD nand/next branch - retain the merged protected-OOB allocation, BBM reservation and stack-buffer fixes - clarify that randomization is part of the normal hardware-ECC page format while MTD_OPS_RAW continues to expose physical bytes - explain why a BSP-compatible BBM remains randomized in physical raw data - document the decoded bad-block and flash-BBT access paths - reject the firmware OOB format with software or disabled ECC - document the BSP page-format compatibility contract and the older-controller format audit - Link to v1: https://patch.msgid.link/20260810-submit-sunxi-nand-vendor-oob-layout-v1-v1-0-463853a14ad9@gmail.com --- James Hilliard (3): dt-bindings: mtd: sunxi: Add randomized OOB flag mtd: rawnand: sunxi: support randomized OOB formats mtd: rawnand: sunxi: select the packed H6/H616 OOB layout .../bindings/mtd/allwinner,sun4i-a10-nand.yaml | 10 ++++ drivers/mtd/nand/raw/sunxi_nand.c | 56 ++++++++++++++++++---- 2 files changed, 56 insertions(+), 10 deletions(-) --- base-commit: def559a215699aa2f2d8ef98f30156b9d562a154 change-id: 20260810-submit-sunxi-nand-vendor-oob-layout-v1-e3114d10cc9c Best regards, -- James Hilliard [off-list ref]