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 _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
