| HDD GURU FORUMS http://forum.hddguru.com/ |
|
| Research ECC algo http://forum.hddguru.com/viewtopic.php?f=10&t=29828 |
Page 1 of 1 |
| Author: | alexey222 [ November 1st, 2014, 9:51 ] |
| Post subject: | Research ECC algo |
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? Attachment: Attachment:
|
|
| Author: | HaQue [ November 2nd, 2014, 0:47 ] |
| Post subject: | Re: Research ECC algo |
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! |
|
| Author: | alexey222 [ November 2nd, 2014, 3:41 ] |
| Post subject: | Re: Research ECC algo |
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... |
|
| Author: | HaQue [ November 2nd, 2014, 5:50 ] |
| Post subject: | Re: Research ECC algo |
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) ? |
|
| Author: | HaQue [ November 2nd, 2014, 6:42 ] |
| Post subject: | Re: Research ECC algo |
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.. |
|
| Author: | alexey222 [ November 2nd, 2014, 8:22 ] |
| Post subject: | Re: Research ECC algo |
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 Quote: 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 Quote: 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. |
|
| Author: | HaQue [ November 2nd, 2014, 19:25 ] |
| Post subject: | Re: Research ECC algo |
Attachment: ecc.jpg [ 11.14 KiB | Viewed 7957 times ] I am down here with this discussion... I am not experienced at manually coding ECC |
|
| Author: | alexey222 [ November 3rd, 2014, 1:25 ] |
| Post subject: | Re: Research ECC algo |
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.... |
|
| Page 1 of 1 | All times are UTC - 5 hours [ DST ] |
| Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |
|