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

[Tom Rini <trini@ti.com>]

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.
- 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: <http://lists.denx.de/pipermail/u-boot/attachments/20130328/b2caa293/attachment.pgp>