[U-Boot] [PATCH] mxs_nand: Fix ECC strength for NAND flash with OOB size of 224

[U-Boot] [PATCH] mxs_nand: Fix ECC strength for NAND flash with OOB size of 224

[Elie De Brauwer]

On a board with an i.mx28 and a Micron MT29F4G08ABAEAH4, Linux says:

NAND device: Manufacturer ID: 0x2c, Chip ID: 0xdc (Micron MT29F4G08ABAEAH4),
512MiB, page size: 4096, OOB size: 224) the ECC strength is 16.

root@(none):/sys/devices/virtual/mtd/mtd0# for i in ecc_strength oobsize subpagesize; do echo $i = `cat $i`; done
ecc_strength = 16
oobsize = 224
subpagesize = 4096

The ECC strength was not properly discovered by U-Boot causing the data
written by Linux to return an -74 (EBADMSG) when read from U-Boot. This
patch fixes mxs_nand_get_ecc_strength() to function in case of a NAND
flash with page_data_size = 4096 and page_oob_size= 224.

Signed-off-by: Elie De Brauwer <eliedebrauwer@gmail.com>
---
 drivers/mtd/nand/mxs_nand.c |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/mtd/nand/mxs_nand.c b/drivers/mtd/nand/mxs_nand.c
index 378f8c5..036c113 100644
--- a/drivers/mtd/nand/mxs_nand.c
+++ b/drivers/mtd/nand/mxs_nand.c
@@ -155,6 +155,9 @@ static inline uint32_t mxs_nand_get_ecc_strength(uint32_t page_data_size,
 
 		if (page_oob_size == 218)
 			return 16;
+
+		if (page_oob_size == 224)
+			return 16;
 	}
 
 	return 0;
-- 
1.7.10.4

[U-Boot] [PATCH] mxs_nand: Fix ECC strength for NAND flash with OOB size of 224

[Stefano Babic]

On 24/08/2013 16:51, Elie De Brauwer wrote:
> On a board with an i.mx28 and a Micron MT29F4G08ABAEAH4, Linux says:
> 
> NAND device: Manufacturer ID: 0x2c, Chip ID: 0xdc (Micron MT29F4G08ABAEAH4),
> 512MiB, page size: 4096, OOB size: 224) the ECC strength is 16.
> 
> root@(none):/sys/devices/virtual/mtd/mtd0# for i in ecc_strength oobsize subpagesize; do echo $i = `cat $i`; done
> ecc_strength = 16
> oobsize = 224
> subpagesize = 4096
> 
> The ECC strength was not properly discovered by U-Boot causing the data
> written by Linux to return an -74 (EBADMSG) when read from U-Boot. This
> patch fixes mxs_nand_get_ecc_strength() to function in case of a NAND
> flash with page_data_size = 4096 and page_oob_size= 224.
> 
> Signed-off-by: Elie De Brauwer <eliedebrauwer@gmail.com>
> ---

Scott, I found this is assigned to me in patchwork. Is it ok if I apply it ?

Best regards,
Stefano

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================

[U-Boot] [PATCH] mxs_nand: Fix ECC strength for NAND flash with OOB size of 224

[Scott Wood]

On Tue, 2013-09-10 at 19:02 +0200, Stefano Babic wrote:
> On 24/08/2013 16:51, Elie De Brauwer wrote:
> > On a board with an i.mx28 and a Micron MT29F4G08ABAEAH4, Linux says:
> > 
> > NAND device: Manufacturer ID: 0x2c, Chip ID: 0xdc (Micron MT29F4G08ABAEAH4),
> > 512MiB, page size: 4096, OOB size: 224) the ECC strength is 16.
> > 
> > root@(none):/sys/devices/virtual/mtd/mtd0# for i in ecc_strength oobsize subpagesize; do echo $i = `cat $i`; done
> > ecc_strength = 16
> > oobsize = 224
> > subpagesize = 4096
> > 
> > The ECC strength was not properly discovered by U-Boot causing the data
> > written by Linux to return an -74 (EBADMSG) when read from U-Boot. This
> > patch fixes mxs_nand_get_ecc_strength() to function in case of a NAND
> > flash with page_data_size = 4096 and page_oob_size= 224.
> > 
> > Signed-off-by: Elie De Brauwer <eliedebrauwer@gmail.com>
> > ---
> 
> Scott, I found this is assigned to me in patchwork. Is it ok if I apply it ?
> 
> Best regards,
> Stefano

Sure.

Acked-by: Scott Wood <scottwood@freescale.com>

I'm curious who's been doing these patchwork assignments and what
they're basing it on.

-Scott

[U-Boot] [PATCH] mxs_nand: Fix ECC strength for NAND flash with OOB size of 224

[Stefano Babic]

Hi Scott,

On 10/09/2013 22:11, Scott Wood wrote:
> Sure.
> 
> Acked-by: Scott Wood <scottwood@freescale.com>
> 
> I'm curious who's been doing these patchwork assignments and what
> they're basing it on.
> 

I think that everyone of us custodians has write rights to assign
patches. Personally, I check the list and I assign myself the i.MXes.
Surely there are a lot of unassigned patches, and someone tries to make
order - better there is who takes care of a patch as to let the patch
oblivious. However, this is an error-prone approach, and it should be
nice if there could be an automatic way to assign patches, maybe using
the subject.

Regards,
Stefano

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================

[U-Boot] [PATCH] mxs_nand: Fix ECC strength for NAND flash with OOB size of 224

[Scott Wood]

On Wed, 2013-09-11 at 09:24 +0200, Stefano Babic wrote:
> Hi Scott,
> 
> On 10/09/2013 22:11, Scott Wood wrote:
> > Sure.
> > 
> > Acked-by: Scott Wood <scottwood@freescale.com>
> > 
> > I'm curious who's been doing these patchwork assignments and what
> > they're basing it on.
> > 
> 
> I think that everyone of us custodians has write rights to assign
> patches. Personally, I check the list and I assign myself the i.MXes.
> Surely there are a lot of unassigned patches, and someone tries to make
> order - better there is who takes care of a patch as to let the patch
> oblivious.

Sure...  Probably what prompted the comment more than this was when
other people assign patches to me that aren't in the NAND code (e.g. UBI
patches, or patches in arch/board code).  Then I need to choose between
just unassigning them, or figuring out who to assign them to, and I
can't even see who assigned them to me to ask them about it.  A log of
patchwork updates would be nice.

>  However, this is an error-prone approach, and it should be
> nice if there could be an automatic way to assign patches, maybe using
> the subject.

It'd be nice if the files touched could be used.

-Scott