* Thomas Petazzoni <thomas.petazzoni@xxxxxxxxxxxxxxxxxx> [131205 11:33]: > Dear Brian Norris, > > On Thu, 5 Dec 2013 11:24:18 -0800, Brian Norris wrote: > > > > The long term benefits is simply to properly handle the hardware > > > constraints. We have hardware platforms were parts of the NAND *MUST* > > > use 1-bit ECC to be compatible with the ROM code, and other parts of > > > the NAND *MUST* use stronger 4-bits or 8-bits ECC to comply with the > > > NAND requirements. > > > > Using 1-bit ECC on NAND is not a long-term solution. Given that fact, > > I think your ROM code is what may need to change, not the entire MTD > > subsystem. > > As someone (Tom Rini maybe?) pointed out, today the shift is 1-bit ECC > supported by ROM code vs. 4 or 8 bits required by NAND. But we can very > well imagine that tomorrow ROM code will support BCH4 (and the NAND > will ensure block 0 is OK for use with BCH4) but the rest of the NAND > will require BCH16 or something like that. > > I'm not designing ROM code, and the fact that they today have this > limitation, should be an indication that Linux should be capable of > handling different ECC schemes to handle those hardware constraints. Yeah and it seems that for the bootloader partition we need to be able to specify the ECC scheme in the .dts file to avoid having people trash their system unless they really want to do it. /me at least has rebooted and reflashed way too many times unnecessarily while trying to update MLO or u-boot from the kernel. Regards, Tony -- 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
