On 11/12/2014 08:02 PM, Tony Lindgren wrote: > * pekon <pekon@xxxxxxxxxxx> [141109 11:31]: >> On Saturday 08 November 2014 04:18 AM, Tony Lindgren wrote: >>> >>> 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. > > OK so it makes sense to keep it as BCH8 then. Would be nice to get > the writing u-boot from kernel issue fixed somehow though as people > are hitting that for sure. What about performance impact? OMAP3 doesn't have ELM module. So error location for BCH8 has to be done in software. > >> 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 > > 0 > >> (2) How many users of OMAP3 legacy boards are migrating to newer kernel? > > Quite a few for sure, but are probably also using rootfs on MMC instead. > >> 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. > > Right no objections to using BCH8 for rootfs, except it stopped working > over past year or so. This would be BCH8-sw on OMAP3 right? AM3xx uses BCH8-hw and that seems to work fine. So it seems nobody has used/tested BCH8-sw. > > And it seems the settings should be partition specific because of u-boot > requiring HAM1. > I don't think we have partition specific ECC scheme support in u-boot or kernel, so it will become messy to manage. That means we either stick with HAM1 for all partitions or don't support NAND boot at all and go with any other ECC scheme for OMAP3. cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html