From mboxrd@z Thu Jan 1 00:00:00 1970 From: Igor Grinberg Date: Thu, 12 Dec 2013 10:38:39 +0200 Subject: [U-Boot] [PATCH 1/2] arm: omap: nand: introduce CONFIG_NAND_OMAP_SW_ECC_LEGACY In-Reply-To: <20980858CB6D3A4BAE95CA194937D5E73EA54702@DBDE04.ent.ti.com> References: <1386781064-23988-1-git-send-email-nikita@compulab.co.il> <1386781064-23988-2-git-send-email-nikita@compulab.co.il> <20980858CB6D3A4BAE95CA194937D5E73EA54702@DBDE04.ent.ti.com> Message-ID: <52A9760F.1000301@compulab.co.il> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Pekon, On 12/11/13 23:18, Gupta, Pekon wrote: > Hi Nikita, > >> From: Nikita Kiryanov [mailto:nikita at compulab.co.il] >> Commit "mtd: nand: omap: enable BCH ECC scheme using ELM for generic platform" >> (d016dc42cedbf6102e100fa9ecb58462edfb14f8) changed the way software ECC is >> configured, both during boot, and during ecc switch, in a way that is not >> backwards compatible with older systems (for example, X-Loader on CM-T35 relies >> on the old behavior). >> >> The culprit is the line which assigns ecc.size for software ECC. >> Older version of omap_gpmc.c always assigned ecc.size = 0 when configuring for >> software ecc, relying on nand_scan_tail() to select a default for ecc.size >> (256), while the new version of omap_gpmc.c assigns ecc.size = pagesize, which >> is likely to not be 256. >> > Then its just one-line change.. Remove "ecc.size = pagesize". > Why do you need to add a newer config for that ? Well, we think that having that line is actually the right behavior, and it is a pity we did not have this from the start in the X-Loader. So that is why we did not want to change it in a brutal way... But if you say: > This ecc-scheme (HAM1_SW) is anyways only kept for backward compatibility > with legacy devices. (As also mentioned in doc/README.nand) > ----------------------------- > CONFIG_NAND_OMAP_ECCSCHEME > On OMAP platforms, this CONFIG specifies NAND ECC scheme. > It can take following values: > OMAP_ECC_HAM1_CODE_SW > 1-bit Hamming code using software lib. > (for legacy devices only) > ----------------------------- then it makes real sense to just revert the ecc.size setting to what it was prior to your patches. > > But I don't have any board to boot-test this, because all my boards > have newer ROM code, which auto-detects BCH8 or BCH16 based > on block-size of NAND device connected to it. > > Also, I suggest to migrate to 'HAM1_HW' as this should be compatible to > OMAP3 ROM code (for NAND boot), at-least I could check that based > on NAND ecc-layout given in OMAP35xx TRM. The problem is not the ROM code... Our systems are in production phase already for a long time and we have customers relying on the old behavior, so we cannot just switch the ECC to HW and stop using the SW one. > 'HAM1_SW' will un-necessary burden your CPU by calculating ECC in > software, inspite the fact that GPMC controller can do that in hardware. Well, that is indeed the case. I think TI should have think about it in first place before releasing the SW ECC based drivers... ;-) -- Regards, Igor.