On Saturday 08 November 2014 04:18 AM, Tony Lindgren wrote:
* Roger Quadros <rogerq@xxxxxx> [141107 01:59]:
On 11/07/2014 11:35 AM, Roger Quadros wrote:
On 11/06/2014 08:03 PM, Tony Lindgren wrote:
* Roger Quadros <rogerq@xxxxxx> [141105 03:02]:
In commit 7d5929c1f343 ("mtd: nand: omap: Revert to using software ECC by default"),
we switched back to using 1-bit SW ECC scheme by default. However
commit b491da7233d5 ("mtd: nand: omap: clean-up ecc layout for BCH ecc schemes")
didn't take into account the 1-bit SW scheme (i.e. OMAP_ECC_HAM1_CODE_SW)
when checking for small page devices because it was already got rid of
one commit earlier. Consider OMAP_ECC_HAM1_CODE_SW while deciding
if we can proceed with small page devices or not.
Fixes: 7d5929c1f34 ("mtd: nand: omap: Revert to using software ECC by default")
Cc: <stable@xxxxxxxxxxxxxxx> [3.17+]
Reported-by: Tony Lindgren <tony@xxxxxxxxxxx>
Signed-off-by: Roger Quadros <rogerq@xxxxxx>
---
[...]
Well I'm wrong about the OMAP3 information. OMAP3 does support BCH4 and BCH8 as well.
I'm don't thinkg small page check is right. For BCH8 we need 13 bytes per 512 bytes.
In the LDP case we have page size:1024 and OOB size: 32.
Thus for BCH8 we need 26 bytes per page. which should fit in 32 bytes OOB.
So this check is bogus in that case.
Pekon,
can you please explain why you check for 64 bytes OOB size for all ECC schemes?
Accept this is a bug.
As I re-review now, small-page check is applicable only for BCH ECC
schemes, and not for HAM1.
Tony,
The question for backward compatibility still remains. Even if OMAP3 supports bch8
do we stick to the scheme that was used in legacy boot or do we switch?
Well for the boards that had a standard file system, we should support
that. But at least for the LDP, there was only the "bootable microSD card"
AFAIK:
http://support.logicpd.com/ProductDownloads/LegacyProducts/ZoomOMAP34xMDK.aspx
OMAP3 supports BCH ECC scheme.
Document: http://www.ti.com/lit/pdf/spruf98
(1) GPMC in OMAP3 supports BCH8
Section: 11.1.5.14.3.2 BCH Code
(2) ROM code in GPMC supports BCH (but its not clear whether its BCH4 or
BCH8)
Section: 25.4.7.4.3 MLC NAND Read Sector Procedure
But I agree that now it doesn't make sense to put effort on OMAP3 for
upgrading default ECC schemes. If user has to migrate then there are
other easy ways of doing so.
Then there is the question of boot rom compatibility. OMAP3 bootloaders use HAM1 scheme.
So if you want to be able to flash bootloader from the kernel we have to stick with HAM1.
changing the ECC scheme would mean that NAND filesystems created earlier won't work
and will have to be erased and recreated.
Right. I doubt anybody has bch8 rootfs on LDP.. And considering u-boot
must be ham1 to boot at all, that's what we should change for the
devices that do not have not standardized on bch8.
My view on this is slightly different:
- Lately, everyone seems to have migrated to BCH8.
- Also HAM1 does not have strength to fix bitflips in aging NAND. So if
someone already has OMAP3-LDP deployed on field then its NAND would have
already aged to such an extend that HAM1 may not be sufficient.
My question is..
Moving back to HAM1 should be decided based on statistics rather than
rule of breaking backward compatibility. So please review:
(1) How many user of OMAP3-Zoom or other old boards complaining about
using BCH8 in mainline kernel? OR
(2) How many users of OMAP3 legacy boards are migrating to newer kernel?
At-least I have not, rather most of the OMAP3 users I interacted via
TI's E2E forum wanted to migrate to BCH8 or even BCH16, as HAM1 was not
sufficient for their usage.
So whatever you decide on this topic, please be cautious that you don't
re-invent work for yourself, as I did. It took me lot of time and
testing effort on multiple boards to migrate HAM1 to BCH8, And add BCH16
for newer devices.
Also, now I realize u-boot (boot-loaders) are better place for all this
migration.
Regards,
Tony
with regards, pekon
------------------------
Powered by BigRock.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
