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