From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ezequiel Garcia Subject: Re: OMAP3 NAND ECC selection Date: Thu, 5 Dec 2013 15:26:29 -0300 Message-ID: <20131205182628.GF2345@localhost> References: <52A04E75.3010609@corscience.de> <20131205171326.GA26766@atomide.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Received: from top.free-electrons.com ([176.31.233.9]:48611 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752009Ab3LES0Z (ORCPT ); Thu, 5 Dec 2013 13:26:25 -0500 Content-Disposition: inline In-Reply-To: Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: Javier Martinez Canillas Cc: Tony Lindgren , "Gupta, Pekon" , Thomas Petazzoni , Enric Balletbo Serra , linux-mtd@lists.infradead.org, "linux-omap@vger.kernel.org" , Andreas =?utf-8?B?Qmllw59tYW5u?= , Peter Meerwald , Brian Norris Hi Javier, (CCing Brian: What do you think about this?) On Thu, Dec 05, 2013 at 06:39:10PM +0100, Javier Martinez Canillas wrot= e: > On Thu, Dec 5, 2013 at 6:13 PM, Tony Lindgren wrot= e: >=20 > 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 se= t > 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. >=20 [..] > 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. >=20 AFAIK, there's no hardware limitation that would prevent us from settin= g a per-partition ECC, keep in mind this effort is not reduced to make devicetree accept ECC on the partitions. While there are some per MTD device (which model each partition), the ECC mode is present in the, nand_chip structure. My understanding is th= at the NAND core hasn't been designed for this use case, and thus some major re-work is needed to accomplish it. Therefore, it's a much short-term solution to implement the OMAP module parameter to fix the issue. Of course, feel free to prove me wrong :-) --=20 Ezequiel Garc=C3=ADa, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-omap" i= n the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from top.free-electrons.com ([176.31.233.9] helo=mail.free-electrons.com) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1VoddO-0001Lm-4f for linux-mtd@lists.infradead.org; Thu, 05 Dec 2013 18:26:46 +0000 Date: Thu, 5 Dec 2013 15:26:29 -0300 From: Ezequiel Garcia To: Javier Martinez Canillas Subject: Re: OMAP3 NAND ECC selection Message-ID: <20131205182628.GF2345@localhost> References: <52A04E75.3010609@corscience.de> <20131205171326.GA26766@atomide.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Cc: Thomas Petazzoni , Brian Norris , Tony Lindgren , Enric Balletbo Serra , linux-mtd@lists.infradead.org, "Gupta, Pekon" , Peter Meerwald , "linux-omap@vger.kernel.org" , Andreas =?utf-8?B?Qmllw59tYW5u?= List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Hi Javier, (CCing Brian: What do you think about this?) On Thu, Dec 05, 2013 at 06:39:10PM +0100, Javier Martinez Canillas wrote: > On Thu, Dec 5, 2013 at 6:13 PM, Tony Lindgren wrote: > > 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. > [..] > 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. > AFAIK, there's no hardware limitation that would prevent us from setting a per-partition ECC, keep in mind this effort is not reduced to make devicetree accept ECC on the partitions. While there are some per MTD device (which model each partition), the ECC mode is present in the, nand_chip structure. My understanding is that the NAND core hasn't been designed for this use case, and thus some major re-work is needed to accomplish it. Therefore, it's a much short-term solution to implement the OMAP module parameter to fix the issue. Of course, feel free to prove me wrong :-) -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com