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

["Andreas Bießmann" <andreas.devel@googlemail.com>]

Dear Peter Korsgaard,

On 16.11.12 16:59, Peter Korsgaard wrote:
>>>>>> "Andreas" == Andreas Bie?mann <andreas.devel@googlemail.com> writes:
> 
> Hi,
> 
>  >> 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.
> 
>  Andreas> You are right, ELM is not available in OMAP3 devices. It seems
>  Andreas> the ROM loader of these devices only support the 1-Bit
>  Andreas> Hamming, but is also different to the OOB layout used for the
>  Andreas> SW 1-bit hamming provided by the Kernel.  So we get here a lot
>  Andreas> of different OOB layouts ... I wonder if we can stick to
>  Andreas> e.g. the generic SW BCH layout (of linux kernel) for all but
>  Andreas> the ROM partition (where the SPL is placed). So the SPL need
>  Andreas> to know just one mechanism but software modifying that place
>  Andreas> needs to know about the 'special' ROM layout.
> 
> No, please not. Having more than 1 OOB layout on the same NAND device
> leads to all kind of complications. There has also been kernel patches
> posted for the ELM, so IMHO the only sane option for am33xx is BCH8
> everywhere (with the ROM layout).

Ok, I understand your point here. But there are device combinations out
there that do not match!
We have an AM37xx with some micron NAND that requires 1bit ECC for the
first page (if less than 1000 erase cycle). But 4bit ECC for the rest of
the device. With the 1bit for first page it does fit to the ROM
requirements of that SoC but unfortunately we can not use the same OOB
layout on the whole device, cause the ROM can only do the 1bit hamming ECC.
I think there are other boards out there facing the same problem. I have
to recheck for example the devkit8000 which is a mainlined development
device some users based their products on (as we do).

>  >> Actually, the only assumption the code does about the OOB layout is that
>  >> ECC code occupies continuous area in the OOB.
> 
>  Andreas> Well, but you have defined that for example it is written in
>  Andreas> big endian.
> 
>  Andreas> I'm currently working on a omap3 enabled device that requires
>  Andreas> 4-bit ECC for all but the first block. And I'm searching for a
>  Andreas> clean solution that would be accepted mainline.  I think it
>  Andreas> would be best to have the same OOB layout for the whole device
>  Andreas> but the SPL space (cause that needs to be read by ROM). The
>  Andreas> layout should be chosen at compile time of the SPL.  What do
>  Andreas> you think about?
> 
> So the only reason to not have the same OOB layout everywhere is because
> of ROM restrictions and that 1bit ECC isn't good enough anymore?

That's my point.

> E.G. you actually would have prefered to use the ROM layout if it would
> have used something better like the am33xx ROM does.

You are right.

Best regards

Andreas Bie?mann