Re: Power cut leads to "corrupt empty space"

[Timo Ketola <Timo.Ketola@xxxxxxxxxx>]

Hi Richard,

Thanks for looking at this!

On 2.3.2020 23.02, Richard Weinberger wrote:
> Hmm, vendor tree....
> I strongly suggest giving mainline a try.

I can share the feeling and I have tried couple of times to switch to
mainline (4.12 and 4.17) but failed. There were issues getting GPU and
camera interfaces working which I was unable to solve. At this time I
tried 5.4 but couldn't get even the NAND subsystem alone working:

http://lists.infradead.org/pipermail/linux-mtd/2020-February/094090.html

> Did you also double check your NAND settings, especially timings?

Not yet. I focused on finding out if the corruption could be recovered.
Now that it seems impossible, I obviously have to device tests to try to
make sure, it does never happen again in the first place.

At least for now, the incidents suggest that this relates somehow to the
power cut. That would speak against bad timings. And I have a design
blooper there: When supply voltage is dropped, NAND write protect signal
is set hard. Now I'm thinking about a 'dirty power loss' scenario, where
supply voltage is dropped momentarily just before actual total power
loss so that one page write fails and then several pages succeeds before
the final power cut. But shouldn't one page write fail put the whole
UBI/UBIFS volume in R/O mode and prevent further writes?

I hope you got my other mail with the link to the UBI image. It does
seem like simply one page in the middle had been left unwritten, doesn't
it? Is there anything there, which could be used to estimate how long
before power cut that happened?

--

Timo
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/