W25N01GV dump ECC

[og0]

Hi there

Would Flashcat be able to use ECC in an off chip read of a W25N01GV SPI NAND that wasn't made with Flashcat to correcr bit errors? I've not purchased the hardware from you at this time and in fact don't even have access to the chip - just a dump provided by someone else for a little project I'm playing with for fun.

I'm not sure if Flashcat would simply ask the chip controller to ECC correct a read, or itself uses ECC to correct the data. Whatever the case or however far I do or don't get, it's been interesting to learn a bit about ECC and OOB etc

Here's a post I made on a different forum for info or interest - many thanks:


I've been looking at an off chip read of a Winbond W25N01GV SPI NAND 128Mb chip for a few days. (yes my life is that exciting).

It's from an IP Camera, and I'm looking to extract an lzma file from the first partition around 0x9300 of the dump. This contains the proper bootloader I need to further research.

I've removed the OOB (the layout of which is weird below), but when trying to decompress the lzma file it is clearly corrupted, and fails after producing only a little valid data.

Comparison with a dump from the same camera with the same bootloader version shows 420 bit errors between them for the data area I am interested in.

I do not have access to either device - just the dumps.

I did write a program to navigate these 420 bits errors that allowed me to interactively try both options for each of the 420 bits the 2 dumps disagreed on, previewing the decompression results, and backtracking to earlier choices as needed. That's allowed me to get about 200 bits in with valid results but now I'm struggling to make further progress.

I did look at using the ECC data in the dump to correct the bits, but short of spending $1000s for VNR there don't seem to be many tools that understand either the OOB layout or the ECC scheme used.

Page: 2048 + 64 OOB

OOB layout:

0x00 - 0x40F user data
0x410 - 0x40D 14 bytes (assumed ECC1)
0x40E - 0x7FF user data
0x800 - 0x801 Bad block marker (0xFF 0xFF)
0x802 - 0x80F user data
0x810 - 0x81D 14 bytes (assumed ECC2)
0x81E - 0x83F 0xFFs (except 0x83A there are always 2 0x00s)

So 0x800 user data in all and 0x40 OOB

On a blank page
ECC1 is always 0A 3A E9 39 43 DE 09 AC 83 22 D0 E1 7F F3
ECC2 is always A5 BB 1D F0 B8 A2 03 70 69 78 36 69 84 B1

So I'm thinking BCH-8 with a sector size of 1024 each having it's own 14 byte ECC code. 2 sectors in each 2048 + 64 page.

Despite this, the bootlog shows:

From bootlog of the kernel:
[ 1.602149] SPI Nand(cs 0) ID: 0xef 0xaa 0x21
[ 1.606622] nand: device found, Manufacturer ID: 0xef, Chip ID: 0xaa
[ 1.612980] nand: Winbond W25N01GV
[ 1.616460] nand: 128MiB, SLC, page size: 2048
[ 1.620901] Nand(Auto): OOB:64B ECC:4bit/512

The last line of this seems to disagree with my guess above, but it that because I'm looking at a physical off chip dump rather than the logical OOB view the OS gets? Data sheets on manufacturer web just talk about the logical layout view not what a chip reader sees.

Can anyone recommend a sensible way forward? Especially tools where I just press a button and magic happens lol

I know going too deep into BCH will get very mathematically complex likely beyond my ability for what is just a fun project for me. I can try different schemes, rearrange the OOB areas of the dump in to 1 64 byte area, try different polys for example, but if I need to work at a university and smoke a pipe with a whiteboard in the background I might give up

Any help appreciated.

 

[og0]

Ah reading a bit more sounds like this could be a difference between classic and Pro?

 

[Pantheon]

This post redundant.

W25N01GV has on board ECC (also known as managed NAND). By default, it generates the ECC data and automatically stores it in OOB. It also does read back correction.

This is because while many MCU might have built-in ecc interfaces, those are typically only for raw parallel NAND. So if you use a SERIAL (or QUAD) IO interface, such as SPI, you will not be able to perform ECC. So the chip will handle ECC itself.

So to copy a W25N01GV, put the hex editor view to "Main", do a READ ALL. And then on a blank device, do a WRITE ALL.

Note: the only thing you MAY have to do, is remove bad blocks (the first byte of OOB will be 00). Both devices will need to have their bad blocks ignored.

 

[og0]

So if I understand correctly you mean flashcat cannot correct the raw ECC in an off chip dump if the chip's controller did not use ECC when the dump was made.

That answers my question if so - like I said I don't have access to the chip nor was it made with Flashcat.

Fortunately I've been able to determine the internal ECC scheme the chips uses, and will programmatically use the ECC data to correct the dump.

Many thanks for your help

 

[lolkek1]

Hi,

I'm struggling with the same ecc on micron nand chip. Our ECC are the same for the blank pages. Can you share the ecc algo?