OMAP3 NAND ECC selection

Javier Martinez Canillas javier at dowhile0.org
Thu Dec 5 12:39:10 EST 2013


[adding Pekon and Thomas as cc]

On Thu, Dec 5, 2013 at 6:13 PM, Tony Lindgren <tony at atomide.com> wrote:
> * Peter Meerwald <pmeerw at pmeerw.net> [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@vger.kernel.org/msg98969.html
[1]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg99008.html
[2]: http://permalink.gmane.org/gmane.linux.ports.arm.omap/108136



More information about the linux-mtd mailing list