Re: [PATCH v2 2/3] mtd: rawnand: sunxi: support randomized OOB formats

[James Hilliard]

On Tue, Sep 8, 2026 at 9:51 AM Miquel Raynal <miquel.raynal@xxxxxxxxxxx> wrote:
>
> Hi James,
>
> On 04/09/2026 at 15:22:12 -06, James Hilliard <james.hilliard1@xxxxxxxxx> wrote:
>
> > The controller randomizer covers the bad block marker along with the
> > rest of the OOB data. The driver currently compensates the marker bytes
> > before writes and after reads so that they remain plain on flash.
> >
> > Allwinner NAND firmware instead stores the marker through the
> > randomizer. Media using that format appears to contain bad blocks unless
> > the randomizer is enabled while reading the marker.
> >
> > Honor the allwinner,randomized-oob property by marking the NAND as
> > requiring scrambling during normal hardware-ECC transfers and leaving
> > the marker in the randomizer data stream. Keep the existing plain marker
> > behavior when the property is absent. Reject the property with software
> > or disabled ECC because those paths do not operate the controller
> > randomizer.
> >
> > MTD_OPS_RAW behavior remains unchanged: raw accesses bypass both ECC and
> > randomization and expose the physical representation. The raw-NAND
> > core's bad-block and flash-BBT paths use decoded accesses and therefore
> > continue through the hardware-ECC/randomizer path.
> >
> > This changes marker handling on all supported controllers; the H6/H616
> > protected user-data placement is handled separately.
> >
> > Signed-off-by: James Hilliard <james.hilliard1@xxxxxxxxx>
>
> I believe it is still not completely working. If you look at the error
> path in the read functions, in case we face a factory bad block, there
> will be no data, we will face the "page is maybe empty" case where we
> still address columns like before. Since data is randomized with these
> accesses, I believe we would return errors which will not be interpreted
> correctly by the core. The discovery of the factory bad block markers is
> thus broken during BBT scan. But a BBT read is also broken, because even
> if errors are ignored, we perform pattern matching on data which is, if
> my understanding of your implementation is correct, not de-randomized in
> this case.

The erased-page fallback could overwrite the decoded buffers with
physical randomized bytes before the core inspected the bad-block
marker or BBT signature.

In v6 [1], both PIO and DMA preserve the main data and protected OOB
from the original hardware read in randomized-OOB mode, including on
uncorrectable ECC errors.

Erased-page classification uses the controller-specific vendor
spare-byte heuristic without a raw reread. Accepted erased pages
return all-0xff data and OOB; all-zero physical pages instead retain
a bad marker and an ECC failure. Other uncorrectable reads retain
the decoded buffers and report failures through the ECC statistics,
so the core can inspect the marker and BBT pattern.

I verified this on H616 using the actual NAND-core BBM and BBT paths
through PIO, DMA and forced split-DMA reads. Signature searches
retained the decoded pattern despite ECC errors, while table loading
rejected an uncorrectable primary and successfully loaded its clean
mirror. Correctable protected-OOB cases and BBT creation/update also
passed. Hardware validation is limited to H616.

MTD_OPS_RAW remains physical, and the existing plain-marker
erased-page check is unchanged apart from the prerequisite
error-handling fixes.

The series grew because this work exposed existing bugs in the shared
PIO/DMA paths: error propagation and cleanup, IRQ/completion ordering,
OOB indexing and program-command handling. Those fixes also apply
without the new property, so they are split from the format support.
The final patches are separate optimizations.

[1] https://patch.msgid.link/20260914-submit-sunxi-nand-vendor-oob-layout-v1-v6-0-2fb084fe0751@xxxxxxxxx

>
> Thanks,
> Miquèl