From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Thu, 28 Mar 2013 10:21:36 -0400 Subject: [U-Boot] [RFC/PATCH 0/4] BCH8 support for OMAP3 In-Reply-To: <51542052.9020905@gmail.com> References: <1353683657-23496-1-git-send-email-andreas.devel@googlemail.com> <51542052.9020905@gmail.com> Message-ID: <20130328142136.GC5711@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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. - 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). > > 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? We _should_ already be taking up all of SRAM with a few kb saved off for stack. We might be able to get away with less stack, but we'd need to check that a bit with the .su files. > > Cause my NAND device 'NAND device: Manufacturer ID: 0x2c, Chip ID: 0xbc (Micron > > NAND 512MiB 1,8V 16-bit)' does support 1bit ECC for first sector if erase is > > less than 1000, the rest requires 4bit ECC. Therefore the SPL needs to support > > BCH, the impact is about 9k for the SPL. > > So my question here is if this series would be accepted for the upcoming > release. I could work on it next week full time, so if I get a go for > this release I would do so. The RFC was well in time, so yes, I'm agreeable given the scope of the changes. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: