[RFC] mtd: ubi: skip programming unused bits in ubi headers

[Cheng Ming Lin]

Hi Richard,

Richard Weinberger <richard at nod.at> 於 2025年9月12日 週五 下午3:57寫道：
>
> ----- Ursprüngliche Mail -----
> > Von: "Cheng Ming Lin" <linchengming884 at gmail.com>
> >> That's the crucial question. Is this true for all NAND chips?
> >> Do avoid larger writes of 0xFF patterns file systems such as UBIFS
> >> also use compression a lot.
> >> At least that's what I have been told when I asked 10+ years ago
> >> how UBI works.
> >
> > You are correct that there is an issue when blank data pages are repeatedly
> > erased. This can lead to cells entering a too deep VT state, which may
> > cause program failures in subsequent operations.
> >
> > To address this, newer NAND generations typically perform a pre-program
> > step before executing the actual erase. This keeps the VT distribution from
> > going too deep, thereby avoiding the blank-page degradation problem.
> > Such pre-PGM techniques have been widely adopted for roughly the past
> > 10–15 years.
> >
> > Additionally, JESD22-A117E (page 6, section 4.1.2.1) specifies examples of
> > acceptable data patterns, including solid-programmed, checkerboard/inverse-
> > checkerboard, and checkerboard-with-fill patterns. According to
> > qualification knowledge bases, using 0x00 can sometimes trigger special
> > failure modes, whereas writing 0xFF is more robust.
> >
> > Additionally, the Kioxia TC58NVG1S3HTA00 datasheet (page 63) also notes
> > that continuous program/erase cycling with a high percentage of ‘0'
> > bits in the data pattern can accelerate block endurance degradation.
> > This further supports avoiding large 0x00 patterns.
>
> Thanks for the detailed answer!
> So, yes let's apply this change.

Sorry, I need to adjust the code a bit, since I just noticed my
condition on vid_hdr shift was incorrect. I will send a v2 version.

>
> Thanks,
> //richard

Thanks,
Cheng Ming Lin