DM37x ECC algorithms

Jozef,

DM37x support 1-bit hamming code, BCH-4 and BCH-8 is supported. BCH-8 is used by boot rom to bootup the device. So it will be good for you to use BCH8 for your use case.

Thank you for the answer, Renjith.

I've got some testing pages from client, for both algorithms. They were created using processor itself. I tried Hamming and BCH algorithms as they are implemented in Linux kernel, but I'm not able to get the same results. Therefore I'm looking for any hint desperately...

Is it happening for both the algorithms (BCH and hamming code)? Or just BCH8? Do you have the pattern that is generated from u-boot as well as kernel? There are chances that, the hardware ECC algorithm implementation in kernel is buggy. 

It happens for both algorithms. I compare the results from software ECC algorithms that I have implemented some time ago, based on source codes from Linux kernel, against results computed by processor itself. I can speculate e.g. about different primary polynomial for BCH (I use kernel implementation default one), but I cannot understand what is wrong with hamming. I used it in numerous applications without any problems, up to now...

Hi Jozef,

Can you post the ECC patterns generated by your code and the kernel for both BCH and Hamming?

Regards,
Renjith 

My code produces the same control sums like kernel code, but different from processor hardware ECC generator...

0741.patterns.zip

For Hamming code, I have discovered that the porcessor uses non-inverted ECC sums instead of inverted ones used in Linux kernel sources, and also it uses different bits assignment in ECC bytes. So now I finally can produce right Hamming ECC control sums.

But what trick is used for BCH?

Jozef,

Have you confirmed the BCH8 ECC generated is for the same data? If so, then it looks like the BCH8 implementation in kernel is wrong. You can ask your client to try using software BCH8 implementation and generate the pattern and try matching it with your pattern. I've seen issues in BCH8 driver implementation before. Which is the linux kernel version used by your client?

Bch_spare.bin is generated from bch8_dump.txt using bch algorithm from Linux kernel 3.5, for hamming files this applies reciprocally. However, Hamming problem is solved now, GPMC just uses different bits assignment in resulting bytes. I tried also some different BCH implementation, but I got the same results. Are you able to program data from bch8_dump.txt using DM37x processor (or any other Sitara/OMAP) and 8-bit BCH algorithm and check the sums? Or anybody other can do this? Thanks a lot.

Jozef,

I don't have a DM37x setup ready with me now. Also your NAND has 4k page size. Instead, can you ask your client to do a NAND write from u-boot with BCH8 and try comparing the ECC generated with the kernel values?

I'm observing similar issue. The BCH8 ECC that I generate is different from the spare data that is read from a NAND that is programmed by AM335x!

Any link to the BCH8 source code woudl help a lot. 

Josef,

Will you re-post your file bch8_dump.txt in binary format? This way,  I can run it through my BCH8 ECC generator to see if my ECC results matches yours or not?

Thanks,

AllanJ,

the file you requested contains data as read from processor, including spare area...