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

[Tom Rini]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/02/2013 04:49 AM, Andreas Bießmann wrote:
> 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).

Shoot.  But, we can handle it, see the mmc headers for an example.

>> - 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

There's no nandecc command for am33xx.  The plan is that we'll
auto-detect when we need BCH16 (as we need BCH8 or BCH16 and the
others don't really have found-today use cases).

> 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).

OK.

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

Yes, we only do BCH8 over everything.  The ROM talks BCH8 or BCH16
(given what the NAND chip requires) or you tell it (via SYSBOOT pins)
tha it's an on-die ECC engine.

>>>> 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.

Along with some measurements (which are available today in the .su
files, see doc/README.SPL) we should be able to do this safely.

- -- 
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRWwOUAAoJENk4IS6UOR1Wg6YP/23aVKSjbgwEtYt84zi97JXp
OUnRxoERpRBUV4Z1Ie9GTc/kk/Vl34eTJfLo8ApKMnHzuDM8o5hB4KTnXzIVjU7T
DSYkPnxsqB6V2W3FRo/g/MfMX3zYrRz1UYzfOxRwHbhJsfmxnu7YTB5MZSjaB72a
vaHHx83x0vaNJePCroGo/ix3SGC4WzpInibu4JiQ16c53A6K1nG/bmSp0z3qB7VV
4ji2kqYe1c5DFgruFG/Ov6+94Dw4PJbVUe6hdqs29b+zWhghfFcKlRhhDnjq5iZg
cd158frWm2CQ199K2r3WDhenr6rkSX0wN9Av9OAg+8QdYQot6iL13GtuGd+Dhp+I
6K7st/oatJOL0d5oTR32dJIUC3j6ElRQnkmbkUWz8/kYo6prPCpvLeYvajahUg4N
mFoOia1W2C8k5tCgUHbqnuDMJRd3cZ/HHMOEauN7Ha0xrOuPHH46Nuyau/vSbVbD
vFOTz8C1VnpaXla0kn0d41/SIk4TYvJFVYChKfglG5CZ8HrRixUeM4F1q7oYOcbC
QzpK2fpZacB2dYaT7J3+zb74effXzPjPw6YkTzKgGPCPC7fQv73wsG9fjaRyA9Lv
x54ZpyVjOf80/b41VGKbxSvcC0d89EOhcjqh93lzIhbzUrIWOYZkqQ+1NY2pjSr0
Q0nzInNCSmwLBKJgJ4eG
=XOEw
-----END PGP SIGNATURE-----