[U-Boot] [PATCH v2 6/8] omap_gpmc: BCH8 support (ELM based)

[Andreas Bießmann]

Dear Ilya Yanok,

On 15.11.2012 21:08, Ilya Yanok wrote:
> Dear Andreas,
> 
> On Thu, Nov 15, 2012 at 2:25 PM, Andreas Bießmann
> <andreas.devel at googlemail.com <mailto:andreas.devel at googlemail.com>> wrote:
> 
>     Dear Ilya Yanok,
> 
>     On 07.11.2012 00:06, Ilya Yanok wrote:
>     > From: Mansoor Ahamed <mansoor.ahamed at ti.com
>     <mailto:mansoor.ahamed at ti.com>>
>     >
>     > This patch adds support for BCH8 error correction code to omap_gpmc
>     > driver. We use GPMC to generate codes/syndromes but we need ELM to
>     find
>     > error locations from given syndrome.
>     >
> 
>     first of all, I wonder why this is so different than the kernel
>     implementation for BCH. I mean the API (and content) of this and commit
>     8d602cf50d3bba864bc1438f486b626df69c87b3 mainline linux seems to differ.
>     The main question coming to mind is: Is the resulting OOB layout
>     compatible then?
> 
> 
> Please note that these patches are AM33XX-specific (as we are using ELM
> that, I think, just isn't available on OMAP3) so we use OOB layout that
> is compatible with AM33xx ROM boot code. 

You are right, ELM is not available in OMAP3 devices. It seems the ROM
loader of these devices only support the 1-Bit Hamming, but is also
different to the OOB layout used for the SW 1-bit hamming provided by
the Kernel.
So we get here a lot of different OOB layouts ... I wonder if we can
stick to e.g. the generic SW BCH layout (of linux kernel) for all but
the ROM partition (where the SPL is placed). So the SPL need to know
just one mechanism but software modifying that place needs to know about
the 'special' ROM layout.

> It's likely that this layout
> doesn't match with the current kernel layout as RBL uses strange 14th
> byte for BCH8 while only 13 bytes are needed. 

Sorry, what does RBL mean in that context?

> There are some patches for
> the kernel that make it use the same layout too but I don't if they are
> going to be accepted soon.

Ok, that would be required to write the SPL to flash.

> Actually, the only assumption the code does about the OOB layout is that
> ECC code occupies continuous area in the OOB.

Well, but you have defined that for example it is written in big endian.

I'm currently working on a omap3 enabled device that requires 4-bit ECC
for all but the first block. And I'm searching for a clean solution that
would be accepted mainline.
I think it would be best to have the same OOB layout for the whole
device but the SPL space (cause that needs to be read by ROM). The
layout should be chosen at compile time of the SPL.
What do you think about?

Best regards

Andreas Bießmann