[U-Boot] Antw: [PATCH v11 3/4] mtd: nand: omap: add CONFIG_NAND_OMAP_ECCSCHEME for selection of ecc-scheme

Andreas Bießmann andreas.devel at googlemail.com
Fri Jul 11 12:08:29 CEST 2014


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


More information about the U-Boot mailing list