Research ECC algo

[alexey222]

Hello all forum members!

I'm experimenting with a NAND memory from flash, unsoldered and read it successfully, as a dump, understanded the layout of data and metadata,
and got the right order of blocks. The only thing I'm stopped at is checking ECC.
I supply a couple of sectors with metadata, it seems that there are 512 data bytes, followed by 6 metadata bytes, and 10 ECC bytes.
So, what I think is that it's Reed Solomon algo, probably 10bit symbol length (to cover 518 bytes) and 8 symbols ECC to total 80 bits=10 bytes.
But all my calculations resulting in different checksums, I can't get the same ECC as controller calculates. I use rslib linux library, which is a ported to userspace kernel Reed Solomon code.
I have tryed to setup the lib with init_rs(10, 0x409, 0, 1, 8) and init_rs(10, 0x409, 510, 1, 8).

The datasheet for flash controller states "4-byte ECC" being used.
Can someone help me with this as I'm almost giving up?

sample.txt

(528 Bytes) Downloaded 767 times

sample2.txt

(528 Bytes) Downloaded 730 times

[HaQue]

In the Service Area there can be information about the LBA and can be some byte/bytes about if the block is bad etc. , also marker bytes. So you will need to find which are the ECC. maybe line up the SA 1 per row and look for 4 bytes that are always different, or some such method.

May help to specify what flash controller it is, and someone may know the specifics.

This post http://joshuawise.com/projects/ndfslave may also be of help as it goes through an ECC algo, though I can't recall how in depth, it has been a while since I read it.

Be interesting if you could do a quick write up once you solve it.

BTW, NEVER Give up!

[alexey222]

Thanks for reply, HaQue!

Memory divided on blocks, each 512*528 bytes, i.e. one sector is 528 bytes of data + Service Area.
In the sample 2 sectors it's zeros in 512 data bytes.
Then there is LBA info as 4 bytes, doubled for some reason (ie 2 bytes specified twice). It's 1001 in sample 2. It's FFFF in sample1, but this sector comes from block 0,
not participating in user data area.
And then bad block/sector marker as a byte, again specified twice. FF in both cases.
The rest 10 bytes I suppose are ECC. If I get another sector with zeros in data and different LBA 4 bytes, all 10 ECC bytes differ.
This gives me the idea that 518 bytes are "covered".
Some sectors are 528 all-bytes FF, so I think bit's get inverted before actual calculation, and calculated ECC get inverted as well before storing on memory.
Data on chip stored as is, not xored/whitened.

I have read the post you supplied. It's BCH code explained there, but 4bytes=32 bits can't be protected by only 80 bits of parity bits.
I already tried to calculate BCH ECC, but the best suited algorithm was 78bit ECC protecting against 6 lost bits.
So it must be RS.

By the way, on flash it was USBest UT161-T6G controller. Memory chip Samsung K9L8G08U0M.
Hope someone knows the internals used in this controller...
Trying to find it already for a couple of months time to time...

[HaQue]

Memory divided on blocks, each 512*528 bytes, i.e. one sector is 528 bytes of data + Service Area.
In the sample 2 sectors it's zeros in 512 data bytes.

I think you will find the sectors are 512b + 16 for SA. Marker bytes are 512/513

Reference at http://www.flash-extractor.com/forum_old/viewtopic.php?p=10301 gives info for ECC as 518 / 10 / 1001 ... but I cant help with coding ECC algos.

I agree the Data is more than likely inverted before ECC calc, as this would give rs result 0xFF

you sure it isn't init_rs(10, 0x409, 0, 1, 6) ?

[HaQue]

EDIT, I think this is BCH actually! UT161 and 163 similar

do a search for BCH UT161

I have found a remarkable absence of example code for ECC used in flash on the internets..

[alexey222]

you sure it isn't init_rs(10, 0x409, 0, 1, 6) ?

With 6 we have 10*6=60 bits of ECC and can protect only 3 "bytes" (actually 3*10 bits) of data.
Anyway, I did calculated with 6 and ECC didn't match.

EDIT, I think this is BCH actually! UT161 and 163 similar
do a search for BCH UT161

Well, I'm not sure... I have found Datashit for UT165, and it states

Integrated ECC circuits for 8-bit/512Bytes and 14-bit/512Bytes BCH error correction

but I think they have introduced this new ECC with this model, and previous ones uses something else.
Both UT161 and UT163 datashits states

Integrated ECC circuits for 4-byte error correction

I don't think it's a typo (4-byte instead of 4 bit), and it's impossible to correct 4 bytes=32 bits with BCH 80 ECC bits..
But it's perfectly match Reed Solomon 10bit message and 80 bit ECC.

[HaQue]

ecc.jpg (11.14 KiB) Viewed 7967 times

I am down here with this discussion...

I am not experienced at manually coding ECC if you get the picture!!

[alexey222]

well 2 months not wasted then..
Unfortunately, not enough to "be there" yet...
I have some thoughts anyway, have to check them.
Thanks for a discussion,
hope someone else could help me....