[adding Pekon and Thomas as cc] On Thu, Dec 5, 2013 at 6:13 PM, Tony Lindgren <tony@xxxxxxxxxxx> wrote: > * Peter Meerwald <pmeerw@xxxxxxxxxx> [131205 08:13]: >> > >> I'd like to be able to update MLO and u-boot from within a booted Linux >> > >> system on the device (I have to resort to u-boot for that where I can >> > >> control the ECC scheme used) >> >> > > Meanwhile, to do this we use a small userspace program created by >> > > Javier Martinez in order to flash the MLO in our OMAP3 boards. See >> > > http://git.isee.biz/?p=pub/scm/writeloader.git;a=summary >> >> > we used another aproach here. See >> > http://article.gmane.org/gmane.linux.drivers.mtd/43804 >> >> pretty much what I have been looking for, thanks! > > Hmm well both methods should work, but is there anything stopping us > merging the module param patch to the mainline tree? > Hi Tony, In the another thread [0] pointed out by Enric we were discussing the same issue. Thomas suggested [1] that ideally we should be able to set a per MTD partition ECC scheme. That way we can set 1 bit hamming for the first MTD partition that has the SPL that the boot ROM needs to read and the other partitions can use a more secure ECC scheme. I completely agree with him. In fact the data-sheet for the NAND device used on the IGEPv2 board says: "Minimum required ECC 4-bit ECC per 528 bytes || Minimum required ECC for block 0 1-bit ECC per 528 byte" so I don't think we should impose a software limitation by having a global ECC scheme and we should expand the GPMC NAND DT binding so partitions support the "ti,nand-ecc-opt". I'll see if I can get some free time to try to implement that. Pekon does not agree with this solution though [2] Thanks a lot and best regards, Javier [0]: http://www.mail-archive.com/linux-omap@xxxxxxxxxxxxxxx/msg98969.html [1]: http://www.mail-archive.com/linux-omap@xxxxxxxxxxxxxxx/msg99008.html [2]: http://permalink.gmane.org/gmane.linux.ports.arm.omap/108136 -- 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
