Help with MNDSPEED PC3008 NAND ECC

[matostr]

Hello,
I'm trying to read data from device that is using MNDSPEED PC3008 and S34ML02G1 NAND.
I read NAND using my TL866II reader, but I'm not able to figure ECC. algorithm.
I found that page size is 2048 bytes and 64bytes are used for ECC.
ECC is probably bch.
Does anybody have some information or documentation what exactly ECC is used in this controller? Like polynomial, sector size, sector size in ECC.
Is there any free tool that can determinate what ECC is used?

I uploaded NAND image here https://ufile.io/earrkl7z

[arvika]

Yes, page size is 2112. ECC is not BCH for 99%. Sector is 512/13_1. You meet also bad byte or it could be controller specific.
Such old chip even without ECC have quite good quality.

[Amarbir[CDR-Labs]]

Yes, page size is 2112. ECC is not BCH for 99%. Sector is 512/13_1. You meet also bad byte or it could be controller specific.
Such old chip even without ECC have quite good quality.

Hello ,
What do you mean by " Sector is 512/13_1 " ,Can You explain Please .

[matostr]

Yes, page size is 2112. ECC is not BCH for 99%. Sector is 512/13_1. You meet also bad byte or it could be controller specific.
Such old chip even without ECC have quite good quality.

Thanks for response.
Unfortunately I'm not able to read data when I strip ECC.
It has squashfs file system, I can see squashfs header in data, but I'm not able to extract it because of errors.
Are you able to get corrected data from it?
Is there any other controller that is using the same ECC and has documentation for it?

[Amarbir[CDR-Labs]]

Yes, page size is 2112. ECC is not BCH for 99%. Sector is 512/13_1. You meet also bad byte or it could be controller specific.
Such old chip even without ECC have quite good quality.

Thanks for response.
Unfortunately I'm not able to read data when I strip ECC.
It has squashfs file system, I can see squashfs header in data, but I'm not able to extract it because of errors.
Are you able to get corrected data from it?
Is there any other controller that is using the same ECC and has documentation for it?

Hi,
what is this device that you are having ,Some photos would be wonderful

[matostr]

Yes, page size is 2112. ECC is not BCH for 99%. Sector is 512/13_1. You meet also bad byte or it could be controller specific.
Such old chip even without ECC have quite good quality.

Thanks for response.
Unfortunately I'm not able to read data when I strip ECC.
It has squashfs file system, I can see squashfs header in data, but I'm not able to extract it because of errors.
Are you able to get corrected data from it?
Is there any other controller that is using the same ECC and has documentation for it?

Hi,
what is this device that you are having ,Some photos would be wonderful

AT&T Cisco Microcell DPH-154
ECC will be the same for all devices with MNDSPEED PC3008.

[fzabkar]

What do you mean by " Sector is 512/13_1 " ,Can You explain Please .

512 bytes of data followed by 13 bytes of ECC plus a 0x00 pad (?) byte, then repeat until end of page. The 4th sector is terminated with 6 bytes of 0xFF. There is something special about that last sector, but I haven't yet worked it out.

[fzabkar]

I think I have worked out the layout of the 4th sector, but it seems very strange. I'll try to write a tool to strip out the data ... if anyone is interested.

[matostr]

I used this tool https://github.com/Hitsxx/NandTool to strip ECC data, but data without ECC correction contains errors.
Do you found what ECC algorithm it is using?

[arvika]

It has squashfs file system, I can see squashfs header in data, but I'm not able to extract it because of errors.
Are you able to get corrected data from it?
Is there any other controller that is using the same ECC and has documentation for it?

Data is stored at blocks, but not at order, it is mixed - we can say digital puzzle.
This controller maybe use Reed-Solomon, Hamming, custom producent code or other ECC algorithm.

@fzabkar: there's no need to break open doors, just use VNR or other tool which can do it easly more or less.

[fzabkar]

Each page of 0x840 bytes contains data at the following ranges:

0x0 - 0x1ff
0x20e - 0x40d
0x41c - 0x61b
0x62a - 0x7ff
0x802 - 0x82b

[fzabkar]

@fzabkar: there's no need to break open doors, just use VNR or other tool which can do it easly more or less.

Yes, I'll just dig out my copy of VNR. LOL

[matostr]

I used this tool to strip ECC github . com / Hitsxx / NandTool(I added spaces because I can't send post with link), but without correction I got a lot of errors in squshfs.
I think data in page is from 0x0 to 0x800 and ECC is from 0x800 to 0x840.
You can see it in my NAND image at 0x18C0 all data in this page is 0x00 and ECC is "FF FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF FF FF FF FF".

[fzabkar]

I think data in page is from 0x0 to 0x800 and ECC is from 0x800 to 0x840.

Definitely not. If you can't write your own tool (using my layout), I'll do it for you. Just let me know.

[matostr]

I can, I will send it here when it is done.

[fzabkar]

BTW, I expect that the word at offset 0x800 is a bad block indicator. If the value is not 0xFFFF, I would ignore that particular block.

Actually, the file system may be aware of bad blocks, so you may want to write two versions of your tool, one including the bad blocks and the other without.

Last edited by fzabkar on June 18th, 2023, 17:50, edited 1 time in total.

[matostr]

Here is my program to strip ECC, unfortunately output still has errors.

Attachments

ecc_strip.cpp

(1.15 KiB) Downloaded 480 times

[fzabkar]

Here is my program to strip ECC, unfortunately output still has errors.

Try discarding any bad blocks.

Could it be that the "ECC" bytes also contain LBNs? If so, then you would need to build a translator.

Perhaps you could extract the 14 bytes at the end of each sector and write them to a separate file? Then view this file in a hex editor set to display 14 bytes per line. In this way you could see any sequential pattern.

[matostr]

I checked and there are no pages that have different value than 0xFFFF at 0x800.

[fzabkar]

Here is my reasoning:

Extract the two blocks in the range 0x152C40 - 0x153CBF and copy them to a test file. Then execute my algorithm (your program) against this test file.

You should see that the resulting output now has correctly aligned tabular data.