Dear Steffen Arendt,
you could test the tricorder configuration. It does work with Pekon's patchset mentioned in your mail. I haven't tested Pekon's changes when they where included. But my regular tests before each U-Boot release showed a change in OOB layout, therefore commit 1b82491ee6ee1e986e5521b33692a00e1f38fe75 was generated. It seems my first attempt to implement OMAP3 HW supported BCH in u-boot was buggy :( Sorry for that!
On 07/11/2014 10:27 AM, Steffen Arendt wrote:
Dear Pekon,
thanks for your mail. This ECC topic is of some complexity. :(
I am close to solve a huge problem here, switching boards from 1bit-SW-ECC to BCH4. The only missing part is, that OMAP xloader and uboot calculates the BCH4 ECC values than Sitara XLoader (although the x-loader binaries are identical). Main problem is not that this is different to Linux - this is not nice, but not a problem. I solved this by implementing a second linux compatible BCH4 in uboot (which works on both platforms). Problem is, that BCH4 (as it is implemented in aragos xloader) seems not to work on OMAP3503. And it is not understood by me, why this is not working, or what can the reason for this.
There is an issue in GPMC for AM37xx up to revision 1.0 (Advisory 1.54 'GPMC Has Incorrect ECC Computation for 4-Bit BCH Mode'). I think this includes the OMAP35xx variants.
You suggestions address kernel/uboot changes. For this I have already a solution. I am running into other troubles if I shift to your suggestions, and I can't see an improvement for the xloader problem. I know, nowadays the xloader is SPL and is derived from uboot. But I haven't the power to completely change everything again. Frankly speaking, I afraid another nightmare here. Unfortunatly TI doesn't have an newer SDK for OMAP3503/AM3703. Is it true, that in this Arago or TI SDK the only functional ECC scheme are 1 bit SW and 1 bit HW (for xloader)?
U-Boot had also only 1 bit Hamming with two different OOB-schemes before my attempt to support BCH. Since X-Loader is outdated I think nobody cared to port these changes. Sorry, I never worked with X-Loader so I can't tell anything about it. You should really migrate to U-Boot!
For me it seems (if you check my logs) that in xloader the omap_calculate_ecc_bch4() uses hardware GPMC registers. Main question: why this doens't work or give different results in OMAP?
I think it is because of the errata mentioned above. You should switch to BCH8 on OMAP3 devices in favor of BCH4.
The version I take over for uboot and kernel (according to Technical Note from Micron tn2971_software_bch_ecc_on_linux.pdf), this functions. The counterpart for this seems to me in bch.c encode_bch(), which seems to run completly independent on hardware.
Please understand my situation. At TI forum I asked since monthes with no real help. So I started my work and succeeded 90%.
U-Boot BCH8 support for OMAP3 is working, one example is tricorder board.
Best regards
Andreas Bießmann