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. > > Isn't handling hardware constraints properly not a sufficient > > motivation for doing something? > > I'm not convinced your hardware constraints are reasonable or > generally useful. But I could be convinced otherwise. They may not be reasonable, but they exist :) > >> Also, any constrain due to ROM code, or upgrading from remote can be > >> handled using various alternative approaches like [a] and [b]. > > > > And you're not realizing that these solutions are ugly and impractical? > > Solution [a] is both ugly and impractical. Solution [b] is only a > little ugly but quite practical (you could flesh out a better > user-space ECC library, then combine it with nanddump/nandwrite > --noecc). Rewriting both the MTD and NAND layers is not exactly > practical and may still yield something ugly. It's not practical because it wasn't thought like this originally, but technically speaking, being able to use a different ECC scheme for different areas of the NAND makes a lot of sense. That being said, it is true that having a good and reusable userspace tool to write data with arbitrary ECC schemes would be useful to workaround this situation. Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.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
