NOR damage problem

NOR damage problem

[Alexander Shiyan]

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..
barebox@Mega-Milas Informer SAMA5D2:/

Now the first partition is broken.

Any suggestions where to look for the bug?

Thanks!

Re: NOR damage problem

[Sascha Hauer]

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 |

Re: NOR damage problem

[Alexander Shiyan]

Hello.

> > Found NOR partition damage after use ubiformat.
> > There is a NOR memory (256M) connected via atmel-qspi.
...
> 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.

The problem is more complex than I thought...
ATMEL QSPI only works in the mapping range up to 128 MB,
larger chips will not work correctly.
To solve this, we will have to update the spi-mem and atmel-quadspi
drivers and add spi_transfer() support to the driver (and in the kernel too).

Thanks!

Re: NOR damage problem

[Ahmad Fatoum]

Hello Alexander,

On 4/1/25 13:56, Alexander Shiyan wrote:
> Hello.
> 
>>> Found NOR partition damage after use ubiformat.
>>> There is a NOR memory (256M) connected via atmel-qspi.
> ...
>> 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.
> 
> The problem is more complex than I thought...
> ATMEL QSPI only works in the mapping range up to 128 MB,
> larger chips will not work correctly.
> To solve this, we will have to update the spi-mem and atmel-quadspi
> drivers and add spi_transfer() support to the driver (and in the kernel too).

The spi-mem core is also limited to 1 bit currently. Just saying in case
you want to fix that as well. I haven't been successful to talk Oleksij
into it. :D

Cheers,
Ahmad

> 
> Thanks!
> 
> 

-- 
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 |

Re: NOR damage problem

[Alexander Shiyan]

Hello.

Oh, the spi-mem driver update also includes a major spi core update.
I'll try to make minimal changes just for the atmel-quadspi driver.

Thanks!

вт, 1 апр. 2025 г. в 15:05, Ahmad Fatoum <a.fatoum@pengutronix.de>:
>
> Hello Alexander,
>
> On 4/1/25 13:56, Alexander Shiyan wrote:
> > Hello.
> >
> >>> Found NOR partition damage after use ubiformat.
> >>> There is a NOR memory (256M) connected via atmel-qspi.
> > ...
> >> 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.
> >
> > The problem is more complex than I thought...
> > ATMEL QSPI only works in the mapping range up to 128 MB,
> > larger chips will not work correctly.
> > To solve this, we will have to update the spi-mem and atmel-quadspi
> > drivers and add spi_transfer() support to the driver (and in the kernel too).
>
> The spi-mem core is also limited to 1 bit currently. Just saying in case
> you want to fix that as well. I haven't been successful to talk Oleksij
> into it. :D
>
> Cheers,
> Ahmad
>
> >
> > Thanks!
> >
> >
>
> --
> 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 |
>