From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?B?QW5kcmVhcyBCaWXDn21hbm4=?= Date: Thu, 28 Mar 2013 11:49:54 +0100 Subject: [U-Boot] [RFC/PATCH 0/4] BCH8 support for OMAP3 In-Reply-To: <1353683657-23496-1-git-send-email-andreas.devel@googlemail.com> References: <1353683657-23496-1-git-send-email-andreas.devel@googlemail.com> Message-ID: <51542052.9020905@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 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. > 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. I would really appreciate if some other omap users could test it. One thing is that most current NAND (even SLC) devices require at least 4Bit ecc for most sections. > 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. Best regards Andreas Bie?mann