[U-Boot] [RFC/PATCH 0/4] BCH8 support for OMAP3

[Andreas Bießmann]

Dear Tom Rini,

On 03/28/2013 03:21 PM, Tom Rini wrote:
> On Thu, Mar 28, 2013 at 11:49:54AM +0100, Andreas Bie??mann wrote:
> 
>> On 11/23/2012 04:14 PM, Andreas Bie??mann wrote:
>>> This RFC series implements BCH8 for OMAP3 as provided by linux kernel in commit
>>> 0e618ef0a6a33cf7ef96c2c824402088dd8ef48c.
>>> This series is heavily influenced by Ilyas series 'NAND support for AM33XX'
>>> thus could share some code.
>>
>> Any comments on that series? I would appreciate to get the BCH8 support
>> in for at least the tricorder board.
> 
> OK, so, some comments:
> - We should pull the gpmc structs out of arch-*/cpu.h and into
>   <asm/omap_gpmc.h> which also means merging
>   <asm/arch-am33xx/omap_gpmc.h> and <asm/arch-omap3/omap_gpmc.h> but I
>   suspect that's easy.

Will do so. But we will need some asm/arch/omap_gpmc.h defining the
differences between both systems (ELM based BCH8 has another OOB
footprint than HW assisted BCH8 on omap3).

> - In terms of 'nandecc' command, I don't like breaking existing
>   setup/scripts, so my first thought is "nandecc hw" -> 1bit, "nandecc
>   sw" -> sw (both just like today), "nandecc hw bch8" -> bch8 and
>   "nandecc hw hamming" -> 1bit, which leaves room down the line for
>   someone else to add nandecc hw bch4 -> bch4 (which is possible and I
>   know exists in custom solutions somewhere).

Sounds good for me. We will end up with 'nandecc hw' -> bch8 on am33xx
and 'nandecc hw' -> hamming on omap3 based boards. To enable bch8
explicitly on omap3 based devices we have the 'nandecc hw bch8'.
I will add another patch to the series changing the interface from
omap_nand_switch_ecc(int32) to omap_nand_switch_ecc(bool hw, uint32
eccbits) (or something like this).

BTW: Has anyone seen that ELM based bch8 on am33xx can not be chosen via
nandecc command?

>>> I have managed to load kernel from an ubifs written by the kernel driver, but is
>>> far away from tested thoroughly.
>>
>> We used that patchset for a while in-house and could not find obvious
>> issues. However we need to hack the SPL a bit to get the bigger
>> footprint into SRAM with 2013.01.
> 
> What exactly did you do? 

Well, disabled FAT for this specific build ...

> We _should_ already be taking up all of SRAM
> with a few kb saved off for stack.

We take 8 kB for stack in most configs on omap3, thus having 54 kB for
.text and .*data. Unfortunately the HW assisted BCH on omap3 based
devices require the bch library to decode ECC, this will grow the .text
+ .*data sections about 9k in sum (AFAIR, I've measured it some day).

>  We might be able to get away with
> less stack, but we'd need to check that a bit with the .su files.

Changing space for stack to 7 kB worked out with all features in SPL
(BCH + FAT for my build), this needs some testing though.

Best regards

Andreas Bießmann