On Tue, Aug 5, 2014 at 1:11 PM, Roger Quadros <rogerq@xxxxxx> wrote: > For v3.12 and prior, 1-bit Hamming code ECC via software was the > default choice. Commit c66d039197e4 in v3.13 changed the behaviour > to use 1-bit Hamming code via Hardware using a different ECC layout > i.e. (ROM code layout) than what is used by software ECC. > > This ECC layout change causes NAND filesystems created in v3.12 > and prior to be unusable in v3.13 and later. So revert back to > using software ECC by default if an ECC scheme is not explicitely > specified. > > This defect can be observed on the following boards during legacy boot > > -omap3beagle > -omap3touchbook > -overo > -am3517crane > -devkit8000 > -ldp > -3430sdp omap3pandora is also using sw ecc, with ubifs. Some time ago I tried booting mainline (I think it was 3.14) with rootfs on NAND, and while it did boot and reached a shell, there were lots of ubifs errors, fs got corrupted and I lost all my data. I used to be able to boot mainline this way fine sometime ~3.8 release. It's interesting that 3.14 was able to read the data, even with wrong ecc setup. Do you think it's safe again to boot ubifs created on 3.2 after applying this series? -- Gražvydas -- 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
