From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-1?Q?Andreas_Bie=DFmann?= Date: Tue, 02 Apr 2013 10:49:21 +0200 Subject: [U-Boot] [RFC/PATCH 0/4] BCH8 support for OMAP3 In-Reply-To: <20130328142136.GC5711@bill-the-cat> References: <1353683657-23496-1-git-send-email-andreas.devel@googlemail.com> <51542052.9020905@gmail.com> <20130328142136.GC5711@bill-the-cat> Message-ID: <515A9B91.2050005@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 > which also means merging > and 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