Re: NOR damage problem

[Sascha Hauer <s.hauer@pengutronix.de>]

Hi Alexander,

On Tue, Apr 01, 2025 at 09:20:31AM +0300, Alexander Shiyan wrote:
> Hello All!
> 
> Found NOR partition damage after use ubiformat.
> There is a NOR memory (256M) connected via atmel-qspi.
> First partition is RAW, the other for use via UBI.
> 
> partition@0 {
> label = "bootstrap";
> reg = <0 0x20000>;
> };
> ...
> partition@e0000 {
> label = "system";
> reg = <0xe0000 0>;
> };
> 
> barebox@Mega-Milas Informer SAMA5D2:/ md -s /dev/m25p0.bootstrap
> m25p80 flash@00: from 0x00000000, len 256
> 00000000: ea000012 eafffffe eafffffe eafffffe                ................
> 00000010: eafffffe 00004144 eafffffe eafffffe                ....DA..........
> 00000020: 65726162 00786f62 00000000 000040b8                barebox......@..
> 00000030: 55555555 55555555 55555555 55555555                UUUUUUUUUUUUUUUU
> 00000040: 55555555 55555555 55555555 55555555                UUUUUUUUUUUUUUUU
> 00000050: eb000c4b e1a00004 eb0008ca e1a0200e                K............ ..
> 00000060: e1a0300d eb000c8d e10fc000 e22cc01a                .0............,.
> 00000070: e31c001f e3ccc01f e38cc0d3 1a000004                ................
> 00000080: e38ccc01 e28fe00c e16ff00c e12ef30e                ..........o.....
> 00000090: e160006e e121f00c ee07cf15 ee07cf9a                n.`...!.........
> 000000a0: ee07cf95 ee11cf10 e3ccc085 e3cccc23                ............#...
> 000000b0: e38cca01 e38cc501 e3ccc002 ee01cf10                ................
> 000000c0: e1a0d003 e1a0f002 ee11cf30 e38cc040                ........0...@...
> 000000d0: ee01cf30 e1a0f00e e24f0008 e59f1004                0.........O.....
> 000000e0: e0500001 e12fff1e 000000d8 e3510000                ..P.../.......Q.
> 000000f0: 13a03000 15813000 e5d021ff e5d031fe                .0...0...!...1..
> 
> So, at this time all OK. Next, format with UBI.
> 
> barebox@Mega-Milas Informer SAMA5D2:/ ubiformat /dev/m25p0.system -y
> ubiformat: m25p0.system (nor), size 267517952 bytes (255.1 MiB),
> 4082 eraseblocks of 65536 bytes (64 KiB), min. I/O size 1 bytes
> ^Mlibscan: scanning eraseblock 0 --  0 % complete
> m25p80 flash@00: from 0x000e0000, len 64
> m25p80 flash@00: from 0x000f0000, len 64
> ...
> m25p80 flash@00: from 0x0ffe0000, len 64
> libscan: scanning eraseblock 4081 -- 100 % complete
> m25p80 flash@00: from 0x0fff0000, len 64
> 
> ubiformat: 7 eraseblocks have valid erase counter, mean value is 0
> ubiformat: 4069 eraseblocks are supposedly empty
> ubiformat: warning!: 6 of 4082 eraseblocks contain non-ubifs data
> ubiformat: warning!: only 7 of 4082 eraseblocks have valid erase counter
> ubiformat: erase counter 0 will be used for all eraseblocks
> ubiformat: note, arbitrary erase counter value may be specified using -e option
> ubiformat: use erase counter 0 for all eraseblocks
> ubiformat: formatting eraseblock 0 --  0 % complete
> m25p80 flash@00: at 0xe0000, len 65536
> m25p80 flash@00: at 0xf0000, len 65536
> m25p80 flash@00: at 0x100000, len 65536
> m25p80 flash@00: to 0x00100000, len 64
> ...
> m25p80 flash@00: to 0x000f0000, len 65536
> 
> Then check first partition:
> barebox@Mega-Milas Informer SAMA5D2:/ md -s /dev/m25p0.bootstrap
> m25p80 flash@00: from 0x00000000, len 256
> 00000000: 22000010 00000000 00000000 00000000                ..."............
> 00000010: 40000000 00000000 60dc9950 00000000                ...@....P..`....
> 00000020: 00000000 00000000 00000000 00000000                ................
> 00000030: 00000000 00000000 00000000 50040051                ............Q..P
> 00000040: 55555555 55555555 55555555 55555555                UUUUUUUUUUUUUUUU
> 00000050: eb000c4b e1a00004 eb0008ca e1a0200e                K............ ..
> 00000060: e1a0300d eb000c8d e10fc000 e22cc01a                .0............,.
> 00000070: e31c001f e3ccc01f e38cc0d3 1a000004                ................
> 00000080: e38ccc01 e28fe00c e16ff00c e12ef30e                ..........o.....
> 00000090: e160006e e121f00c ee07cf15 ee07cf9a                n.`...!.........
> 000000a0: ee07cf95 ee11cf10 e3ccc085 e3cccc23                ............#...
> 000000b0: e38cca01 e38cc501 e3ccc002 ee01cf10                ................
> 000000c0: e1a0d003 e1a0f002 ee11cf30 e38cc040                ........0...@...
> 000000d0: ee01cf30 e1a0f00e e24f0008 e59f1004                0.........O.....
> 000000e0: e0500001 e12fff1e 000000d8 e3510000                ..P.../.......Q.
> 000000f0: 13a03000 15813000 e5d021ff e5d031fe                .0...0...!...1..

The messages above say that 64bytes were written which matches the
number of bytes that are corrupted here. Maybe this can be a starting
point where to look at. Also the 64 bytes were written without the block
being erased. You could erase the block manually before calling
ubiformat, then you could see what the code really tried to write here.

Just an idea: Is the size of your Flash correctly detected? When writing
past the device then the write operations could roll over to the first
block.

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |