HDD GURU FORUMS

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?

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!

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

alexey222 wrote:
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) ?

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

HaQue wrote: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.

HaQue wrote: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.

I am down here with this discussion...

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

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