[PATCH] mx31pdk: Add NAND support

[PATCH] mx31pdk: Add NAND support

[Fabio Estevam]

Add NAND support to MX31PDK board.

Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
 arch/arm/mach-mx3/mach-mx31_3ds.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-mx3/mach-mx31_3ds.c b/arch/arm/mach-mx3/mach-mx31_3ds.c
index b88c18a..2d78754 100644
--- a/arch/arm/mach-mx3/mach-mx31_3ds.c
+++ b/arch/arm/mach-mx3/mach-mx31_3ds.c
@@ -34,6 +34,7 @@
 #include <mach/board-mx31pdk.h>
 #include <mach/imx-uart.h>
 #include <mach/iomux-mx3.h>
+#include <mach/mxc_nand.h>
 #include "devices.h"
 
 /*!
@@ -80,6 +81,11 @@ static struct resource smsc911x_resources[] = {
 	},
 };
 
+static struct mxc_nand_platform_data mx31pdk_nand_board_info = {
+	.width = 1,
+	.hw_ecc = 1,
+};
+
 static struct platform_device smsc911x_device = {
 	.name		= "smsc911x",
 	.id		= -1,
@@ -236,6 +242,7 @@ static void __init mxc_board_init(void)
 				      "mx31pdk");
 
 	mxc_register_device(&mxc_uart_device0, &uart_pdata);
+	mxc_register_device(&mxc_nand_device, &mx31pdk_nand_board_info);
 
 	if (!mx31pdk_init_expio())
 		platform_device_register(&smsc911x_device);
-- 
1.6.0.4


      

[PATCH] mx31pdk: Add NAND support

[Alberto Panizzo]

On mer, 2010-02-24 at 16:58 -0800, Fabio Estevam wrote:
> Add NAND support to MX31PDK board.
> 
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> 

Mmm.. maybe I waited too much before pull my work on this board..
Fabio, don't you think to change the namespace in mach-mx31_3ds
to accomplish to the new machine file name before adding some more 
functionality?

I am waiting for the rebase of mxc-master on 2.6.34-rc1 (or 
linux-next).

-- 
Alberto!

        Be Persistent!
                - Greg Kroah-Hartman (FOSDEM 2010)

[PATCH] mx31pdk: Add NAND support

[Alberto Panizzo]

Hi Fabio,

On mer, 2010-02-24 at 16:58 -0800, Fabio Estevam wrote:
> Add NAND support to MX31PDK board.
> 
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> ---
>  arch/arm/mach-mx3/mach-mx31_3ds.c |    7 +++++++
>  1 files changed, 7 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mach-mx3/mach-mx31_3ds.c b/arch/arm/mach-mx3/mach-mx31_3ds.c
> index b88c18a..2d78754 100644
> --- a/arch/arm/mach-mx3/mach-mx31_3ds.c
> +++ b/arch/arm/mach-mx3/mach-mx31_3ds.c
> @@ -34,6 +34,7 @@
>  #include <mach/board-mx31pdk.h>
>  #include <mach/imx-uart.h>
>  #include <mach/iomux-mx3.h>
> +#include <mach/mxc_nand.h>
>  #include "devices.h"
>  
>  /*!
> @@ -80,6 +81,11 @@ static struct resource smsc911x_resources[] = {
>  	},
>  };
>  
> +static struct mxc_nand_platform_data mx31pdk_nand_board_info = {
> +	.width = 1,
> +	.hw_ecc = 1,
> +};
> +

Are you sure that this works? Don't you see a lot of Bad blocks reports
in boot messages?


-- 
Alberto!

        Be Persistent!
                - Greg Kroah-Hartman (FOSDEM 2010)

[PATCH] mx31pdk: Add NAND support

[Fabio Estevam]

Hi Alberto,

--- On Thu, 2/25/10, Alberto Panizzo <maramaopercheseimorto@gmail.com> wrote:

> From: Alberto Panizzo <maramaopercheseimorto@gmail.com>
> Subject: Re: [PATCH] mx31pdk: Add NAND support
> To: "Fabio Estevam" <fabioestevam@yahoo.com>
> Cc: linux-arm-kernel at lists.infradead.org, s.hauer at pengutronix.de
> Date: Thursday, February 25, 2010, 9:12 AM
> Hi Fabio,
> 
> On mer, 2010-02-24 at 16:58 -0800, Fabio Estevam wrote:
> > Add NAND support to MX31PDK board.
> > 
> > Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> > ---
> >? arch/arm/mach-mx3/mach-mx31_3ds.c |? ?
> 7 +++++++
> >? 1 files changed, 7 insertions(+), 0
> deletions(-)
> > 
> > diff --git a/arch/arm/mach-mx3/mach-mx31_3ds.c
> b/arch/arm/mach-mx3/mach-mx31_3ds.c
> > index b88c18a..2d78754 100644
> > --- a/arch/arm/mach-mx3/mach-mx31_3ds.c
> > +++ b/arch/arm/mach-mx3/mach-mx31_3ds.c
> > @@ -34,6 +34,7 @@
> >? #include <mach/board-mx31pdk.h>
> >? #include <mach/imx-uart.h>
> >? #include <mach/iomux-mx3.h>
> > +#include <mach/mxc_nand.h>
> >? #include "devices.h"
> >? 
> >? /*!
> > @@ -80,6 +81,11 @@ static struct resource
> smsc911x_resources[] = {
> >? ??? },
> >? };
> >? 
> > +static struct mxc_nand_platform_data
> mx31pdk_nand_board_info = {
> > +??? .width = 1,
> > +??? .hw_ecc = 1,
> > +};
> > +
> 
> Are you sure that this works? Don't you see a lot of Bad
> blocks reports
> in boot messages?

I followed the same approach used on other i.MX boards. This is what I see:
...
NAND device: Manufacturer ID: 0xec, Chip ID: 0xaa (Samsung NAND 256MiB 1,8V 8-bit)                                                                              
Scanning device for bad blocks                                                  
Bad eraseblock 42 at 0x000000540000                                             
Bad eraseblock 125 at 0x000000fa0000                                            
Bad eraseblock 887 at 0x000006ee0000                                            
Bad eraseblock 1750 at 0x00000dac0000                                           
Bad eraseblock 2046 at 0x00000ffc0000                                           
Bad eraseblock 2047 at 0x00000ffe0000                                           
Registering mxc_nand as whole device  

If I define it as:

static struct mxc_nand_platform_data mx31pdk_nand_board_info = {
	.width = 1,
	.hw_ecc = 1,
	.flash_bbt =1,
};

The bad block messages go away. 

What would be the correct way?

Thanks,

Fabio Estevam




 


      

[PATCH] mx31pdk: Add NAND support

[Fabio Estevam]

Hi Alberto,

--- On Thu, 2/25/10, Alberto Panizzo <maramaopercheseimorto@gmail.com> wrote:

> From: Alberto Panizzo <maramaopercheseimorto@gmail.com>
> Subject: Re: [PATCH] mx31pdk: Add NAND support
> To: "Fabio Estevam" <fabioestevam@yahoo.com>
> Cc: s.hauer at pengutronix.de, linux-arm-kernel at lists.infradead.org
> Date: Thursday, February 25, 2010, 8:58 AM
> On mer, 2010-02-24 at 16:58 -0800,
> Fabio Estevam wrote:
> > Add NAND support to MX31PDK board.
> > 
> > Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> 
> 
> Mmm.. maybe I waited too much before pull my work on this
> board..
> Fabio, don't you think to change the namespace in
> mach-mx31_3ds
> to accomplish to the new machine file name before adding
> some more 
> functionality?

I am not a big fan of the mach-mx31_3ds name. I know that this comes from the MACH name, but the name we use these days is MX31PDK as it is advertised on Freescale's website (www.freescale.com/imx31pdk).

Should we really rename all mx31pdk references inside mach-mx31_3ds.c ?

U-boot also references this board as mx31pdk.

MX35PDK board seems not to follow the same logic:
MACH name is MX35_3DS and board name is mach-mx35pdk.c

I prefer the MX35 approach.

Regards,

Fabio Estevam


 


      

[PATCH] mx31pdk: Add NAND support

[Alberto Panizzo]

Hi Fabio,
On gio, 2010-02-25 at 13:59 -0800, Fabio Estevam wrote:
> Hi Alberto,
> 
> --- On Thu, 2/25/10, Alberto Panizzo <maramaopercheseimorto@gmail.com> wrote:
> 
> > From: Alberto Panizzo <maramaopercheseimorto@gmail.com>
> > Subject: Re: [PATCH] mx31pdk: Add NAND support
> > To: "Fabio Estevam" <fabioestevam@yahoo.com>
> > Cc: linux-arm-kernel at lists.infradead.org, s.hauer at pengutronix.de
> > Date: Thursday, February 25, 2010, 9:12 AM
> > Hi Fabio,
> > 
> > On mer, 2010-02-24 at 16:58 -0800, Fabio Estevam wrote:
> > > Add NAND support to MX31PDK board.
> > > 
> > > Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> > > ---
> > >  arch/arm/mach-mx3/mach-mx31_3ds.c |   
> > 7 +++++++
> > >  1 files changed, 7 insertions(+), 0
> > deletions(-)
> > > 
> > > diff --git a/arch/arm/mach-mx3/mach-mx31_3ds.c
> > b/arch/arm/mach-mx3/mach-mx31_3ds.c
> > > index b88c18a..2d78754 100644
> > > --- a/arch/arm/mach-mx3/mach-mx31_3ds.c
> > > +++ b/arch/arm/mach-mx3/mach-mx31_3ds.c
> > > @@ -34,6 +34,7 @@
> > >  #include <mach/board-mx31pdk.h>
> > >  #include <mach/imx-uart.h>
> > >  #include <mach/iomux-mx3.h>
> > > +#include <mach/mxc_nand.h>
> > >  #include "devices.h"
> > >  
> > >  /*!
> > > @@ -80,6 +81,11 @@ static struct resource
> > smsc911x_resources[] = {
> > >      },
> > >  };
> > >  
> > > +static struct mxc_nand_platform_data
> > mx31pdk_nand_board_info = {
> > > +    .width = 1,
> > > +    .hw_ecc = 1,
> > > +};
> > > +
> > 
> > Are you sure that this works? Don't you see a lot of Bad
> > blocks reports
> > in boot messages?
> 
> I followed the same approach used on other i.MX boards. This is what I see:
> ...
> NAND device: Manufacturer ID: 0xec, Chip ID: 0xaa (Samsung NAND 256MiB 1,8V 8-bit)                                                                              
> Scanning device for bad blocks                                                  
> Bad eraseblock 42 at 0x000000540000                                             
> Bad eraseblock 125 at 0x000000fa0000                                            
> Bad eraseblock 887 at 0x000006ee0000                                            
> Bad eraseblock 1750 at 0x00000dac0000                                           
> Bad eraseblock 2046 at 0x00000ffc0000                                           
> Bad eraseblock 2047 at 0x00000ffe0000                                           
> Registering mxc_nand as whole device  
> 
> If I define it as:
> 
> static struct mxc_nand_platform_data mx31pdk_nand_board_info = {
> 	.width = 1,
> 	.hw_ecc = 1,
> 	.flash_bbt =1,
> };
> 
> The bad block messages go away. 
> 
> What would be the correct way?
> 
> Thanks,
> 
> Fabio Estevam

Well, I am not very experienced on mtd devices, but if you
trust what your bootloader say, Bad blocks reporting must not change.
On my mx31_3ds board, omitting that row means A LOT of bad block 
reporting that is in contrast with the bootloader.

-- 
Alberto!

        Be Persistent!
                - Greg Kroah-Hartman (FOSDEM 2010)

[PATCH] mx31pdk: Add NAND support

[Uwe Kleine-König]

Hello,

> MACH name is MX35_3DS and board name is mach-mx35pdk.c
Oh, I must have missed that when massrenaming the machine files.
(commit 321ed164).  Sorry :-)

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[PATCH] mx31pdk: Add NAND support

[Juergen Beisert]

Fabio Estevam wrote:
> > Are you sure that this works? Don't you see a lot of Bad
> > blocks reports
> > in boot messages?
>
> I followed the same approach used on other i.MX boards. This is what I see:
> ...
> NAND device: Manufacturer ID: 0xec, Chip ID: 0xaa (Samsung NAND 256MiB 1,8V
> 8-bit) Scanning device for bad blocks
> Bad eraseblock 42 at 0x000000540000
> Bad eraseblock 125 at 0x000000fa0000
> Bad eraseblock 887 at 0x000006ee0000
> Bad eraseblock 1750 at 0x00000dac0000
> Bad eraseblock 2046 at 0x00000ffc0000
> Bad eraseblock 2047 at 0x00000ffe0000
> Registering mxc_nand as whole device
>
> If I define it as:
>
> static struct mxc_nand_platform_data mx31pdk_nand_board_info = {
> 	.width = 1,
> 	.hw_ecc = 1,
> 	.flash_bbt =1,
> };

Your bootloader also use a Bad Block Table? Then also your kernel should use 
it. If hardware ECC is in use, its always a good idea to collect the bad 
blocks into a BBT. Most of the time you can't control at which offset in the 
OOB data the NAND controller will store the ECC sum. There is the risk it 
will destroy manufacturer's bad block markers. So, its better to collect 
these marked bad blocks into a BBT the first time you use the NAND device. 
After that _only_ the BBT should be used to handle bad blocks (in the boot 
loader and the kernel).

jbe

-- 
Pengutronix e.K.                              | Juergen Beisert             |
Linux Solutions for Science and Industry      | Phone: +49-8766-939 228     |
Vertretung Sued/Muenchen, Germany             | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686              | http://www.pengutronix.de/  |

[PATCH] mx31pdk: Add NAND support

[Alberto Panizzo]

On ven, 2010-02-26 at 10:36 +0100, Uwe Kleine-K?nig wrote:
> Hello,
> 
> > MACH name is MX35_3DS and board name is mach-mx35pdk.c
> Oh, I must have missed that when massrenaming the machine files.
> (commit 321ed164).  Sorry :-)
> 
> Best regards
> Uwe
> 

Uwe, so what is the next step? we can re-rename the machine file
to mach-mx31pdk.c?


-- 
Alberto!

        Be Persistent!
                - Greg Kroah-Hartman (FOSDEM 2010)

[PATCH] mx31pdk: Add NAND support

[Alberto Panizzo]

On ven, 2010-02-26 at 10:56 +0100, Juergen Beisert wrote:
> Fabio Estevam wrote:
> > > Are you sure that this works? Don't you see a lot of Bad
> > > blocks reports
> > > in boot messages?
> >
> > I followed the same approach used on other i.MX boards. This is what I see:
> > ...
> > NAND device: Manufacturer ID: 0xec, Chip ID: 0xaa (Samsung NAND 256MiB 1,8V
> > 8-bit) Scanning device for bad blocks
> > Bad eraseblock 42 at 0x000000540000
> > Bad eraseblock 125 at 0x000000fa0000
> > Bad eraseblock 887 at 0x000006ee0000
> > Bad eraseblock 1750 at 0x00000dac0000
> > Bad eraseblock 2046 at 0x00000ffc0000
> > Bad eraseblock 2047 at 0x00000ffe0000
> > Registering mxc_nand as whole device
> >
> > If I define it as:
> >
> > static struct mxc_nand_platform_data mx31pdk_nand_board_info = {
> > 	.width = 1,
> > 	.hw_ecc = 1,
> > 	.flash_bbt =1,
> > };
> 
> Your bootloader also use a Bad Block Table? Then also your kernel should use 
> it. If hardware ECC is in use, its always a good idea to collect the bad 
> blocks into a BBT. Most of the time you can't control at which offset in the 
> OOB data the NAND controller will store the ECC sum. There is the risk it 
> will destroy manufacturer's bad block markers. So, its better to collect 
> these marked bad blocks into a BBT the first time you use the NAND device. 
> After that _only_ the BBT should be used to handle bad blocks (in the boot 
> loader and the kernel).
> 
> jbe
> 
Thank you Juergen to participate on this thread.
Ok, so with this board shall be enabled the flash_bbt checking because 
the bootloader uses it. But how do you explain that on Mine board the 
kernel recognize it correctly and in Fabio's board the kernel prompt 
disagree with the bootloader one? It is a kind of bootloader issue?

-- 
Alberto!

        Be Persistent!
                - Greg Kroah-Hartman (FOSDEM 2010)

[PATCH] mx31pdk: Add NAND support

[Uwe Kleine-König]

Hello,

> > > MACH name is MX35_3DS and board name is mach-mx35pdk.c
> > Oh, I must have missed that when massrenaming the machine files.
> > (commit 321ed164).  Sorry :-)
> > 
> > Best regards
> > Uwe
> > 
> 
> Uwe, so what is the next step? we can re-rename the machine file
> to mach-mx31pdk.c?
I suggest to do

	mv mach-mx35pdk.c mach-mx35_3ds.c

to make it consistant.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[PATCH] mx31pdk: Add NAND support

[Alberto Panizzo]

On ven, 2010-02-26 at 11:46 +0100, Uwe Kleine-K?nig wrote:
> Hello,
> 
> > > > MACH name is MX35_3DS and board name is mach-mx35pdk.c
> > > Oh, I must have missed that when massrenaming the machine files.
> > > (commit 321ed164).  Sorry :-)
> > > 
> > > Best regards
> > > Uwe
> > > 
> > 
> > Uwe, so what is the next step? we can re-rename the machine file
> > to mach-mx31pdk.c?
> I suggest to do
> 
> 	mv mach-mx35pdk.c mach-mx35_3ds.c
> 
> to make it consistant.
> 
> Best regards
> Uwe
> 

:) consistant with the MACH name, but the market and freescale call 
these mx[N]pdk, I don't know who registered those names but Fabio 
addressed a not obvious problem.
For me it is not a problem and I think that the motivations are: Freescale
can build different type of Product Development Kit, indeed the 3-Stack
is the particular one -> call it mx[N]_3ds.c
But Freescale do not produce multiple mx[N] PDKs.

Best regards

-- 
Alberto!

        Be Persistent!
                - Greg Kroah-Hartman (FOSDEM 2010)

[PATCH] mx31pdk: Add NAND support

[Juergen Beisert]

Hi Alberto,

Alberto Panizzo wrote:
> On ven, 2010-02-26 at 10:56 +0100, Juergen Beisert wrote:
> > Fabio Estevam wrote:
> > > > Are you sure that this works? Don't you see a lot of Bad
> > > > blocks reports
> > > > in boot messages?
> > >
> > > I followed the same approach used on other i.MX boards. This is what I
> > > see: ...
> > > NAND device: Manufacturer ID: 0xec, Chip ID: 0xaa (Samsung NAND 256MiB
> > > 1,8V 8-bit) Scanning device for bad blocks
> > > Bad eraseblock 42 at 0x000000540000
> > > Bad eraseblock 125 at 0x000000fa0000
> > > Bad eraseblock 887 at 0x000006ee0000
> > > Bad eraseblock 1750 at 0x00000dac0000
> > > Bad eraseblock 2046 at 0x00000ffc0000
> > > Bad eraseblock 2047 at 0x00000ffe0000
> > > Registering mxc_nand as whole device
> > >
> > > If I define it as:
> > >
> > > static struct mxc_nand_platform_data mx31pdk_nand_board_info = {
> > > 	.width = 1,
> > > 	.hw_ecc = 1,
> > > 	.flash_bbt =1,
> > > };
> >
> > Your bootloader also use a Bad Block Table? Then also your kernel should
> > use it. If hardware ECC is in use, its always a good idea to collect the
> > bad blocks into a BBT. Most of the time you can't control at which offset
> > in the OOB data the NAND controller will store the ECC sum. There is the
> > risk it will destroy manufacturer's bad block markers. So, its better to
> > collect these marked bad blocks into a BBT the first time you use the
> > NAND device. After that _only_ the BBT should be used to handle bad
> > blocks (in the boot loader and the kernel).
>
> Thank you Juergen to participate on this thread.
> Ok, so with this board shall be enabled the flash_bbt checking because
> the bootloader uses it. But how do you explain that on Mine board the
> kernel recognize it correctly and in Fabio's board the kernel prompt
> disagree with the bootloader one? It is a kind of bootloader issue?

Here on my i.MX35 based system the bootloader reports:

NAND device: Manufacturer ID: 0x20, Chip ID: 0xac (ST Micro NAND 512MiB 1,8V 8-bit)
Bad block table found at page 262080, version 0x01
Bad block table found at page 262016, version 0x01
nand_read_bbt: Bad block at 0x01d00000
nand_read_bbt: Bad block at 0x10020000
nand_read_bbt: Bad block at 0x10040000
nand_read_bbt: Bad block at 0x10060000
nand_read_bbt: Bad block at 0x10080000
nand_read_bbt: Bad block at 0x100a0000
nand_read_bbt: Bad block at 0x100e0000
nand_read_bbt: Bad block at 0x10120000
nand_read_bbt: Bad block at 0x10160000
nand_read_bbt: Bad block at 0x101a0000
nand_read_bbt: Bad block at 0x101c0000
nand_read_bbt: Bad block at 0x10200000
nand_read_bbt: Bad block at 0x10240000

And the starting kernel reports:

[...]
NAND device: Manufacturer ID: 0x20, Chip ID: 0xac (ST Micro NAND 512MiB 1,8V 8-bit)
Bad block table found at page 262080, version 0x01
Bad block table found at page 262016, version 0x01
nand_read_bbt: Bad block at 0x000001d00000
nand_read_bbt: Bad block at 0x000010020000
nand_read_bbt: Bad block at 0x000010040000
nand_read_bbt: Bad block at 0x000010060000
nand_read_bbt: Bad block at 0x000010080000
nand_read_bbt: Bad block at 0x0000100a0000
nand_read_bbt: Bad block at 0x0000100e0000
nand_read_bbt: Bad block at 0x000010120000
nand_read_bbt: Bad block at 0x000010160000
nand_read_bbt: Bad block at 0x0000101a0000
nand_read_bbt: Bad block at 0x0000101c0000
nand_read_bbt: Bad block at 0x000010200000
nand_read_bbt: Bad block at 0x000010240000
[...]

Both are configured to use a BBT and will handle the bad blocks in the same
manner.

Regards,
Juergen

-- 
Pengutronix e.K.                              | Juergen Beisert             |
Linux Solutions for Science and Industry      | Phone: +49-8766-939 228     |
Vertretung Sued/Muenchen, Germany             | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686              | http://www.pengutronix.de/  |

[PATCH] mx31pdk: Add NAND support

[Ivo Clarysse]

2010/2/26 Alberto Panizzo <maramaopercheseimorto@gmail.com>
[...]

> For me it is not a problem and I think that the motivations are: Freescale
> can build different type of Product Development Kit, indeed the 3-Stack
> is the particular one -> call it mx[N]_3ds.c
> But Freescale do not produce multiple mx[N] PDKs.
>

Yes it does: i.MX25 PDK, MX27 PDK, MX31 PDK and the MX35 PDK.

Basically, everything which Freescale used to call a "i.MX[N] 3-Stack
Development System", Freescale now refers to as "i.MX[N] PDK" (Platform
Development Kit).

Best regards,

Ivo.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20100226/26a11b34/attachment-0001.htm>

[PATCH] mx31pdk: Add NAND support

[Alberto Panizzo]

On ven, 2010-02-26 at 12:48 +0100, Juergen Beisert wrote:
> Hi Alberto,
> 
> Alberto Panizzo wrote:
> > On ven, 2010-02-26 at 10:56 +0100, Juergen Beisert wrote:
> > > Fabio Estevam wrote:
> > > > > Are you sure that this works? Don't you see a lot of Bad
> > > > > blocks reports
> > > > > in boot messages?
> > > >
> > > > I followed the same approach used on other i.MX boards. This is what I
> > > > see: ...
> > > > NAND device: Manufacturer ID: 0xec, Chip ID: 0xaa (Samsung NAND 256MiB
> > > > 1,8V 8-bit) Scanning device for bad blocks
> > > > Bad eraseblock 42 at 0x000000540000
> > > > Bad eraseblock 125 at 0x000000fa0000
> > > > Bad eraseblock 887 at 0x000006ee0000
> > > > Bad eraseblock 1750 at 0x00000dac0000
> > > > Bad eraseblock 2046 at 0x00000ffc0000
> > > > Bad eraseblock 2047 at 0x00000ffe0000
> > > > Registering mxc_nand as whole device
> > > >
> > > > If I define it as:
> > > >
> > > > static struct mxc_nand_platform_data mx31pdk_nand_board_info = {
> > > > 	.width = 1,
> > > > 	.hw_ecc = 1,
> > > > 	.flash_bbt =1,
> > > > };
> > >
> > > Your bootloader also use a Bad Block Table? Then also your kernel should
> > > use it. If hardware ECC is in use, its always a good idea to collect the
> > > bad blocks into a BBT. Most of the time you can't control at which offset
> > > in the OOB data the NAND controller will store the ECC sum. There is the
> > > risk it will destroy manufacturer's bad block markers. So, its better to
> > > collect these marked bad blocks into a BBT the first time you use the
> > > NAND device. After that _only_ the BBT should be used to handle bad
> > > blocks (in the boot loader and the kernel).
> >
> > Thank you Juergen to participate on this thread.
> > Ok, so with this board shall be enabled the flash_bbt checking because
> > the bootloader uses it. But how do you explain that on Mine board the
> > kernel recognize it correctly and in Fabio's board the kernel prompt
> > disagree with the bootloader one? It is a kind of bootloader issue?
> 
> Here on my i.MX35 based system the bootloader reports:
> 
> NAND device: Manufacturer ID: 0x20, Chip ID: 0xac (ST Micro NAND 512MiB 1,8V 8-bit)
> Bad block table found at page 262080, version 0x01
> Bad block table found at page 262016, version 0x01
> nand_read_bbt: Bad block at 0x01d00000
> nand_read_bbt: Bad block at 0x10020000
> nand_read_bbt: Bad block at 0x10040000
> nand_read_bbt: Bad block at 0x10060000
> nand_read_bbt: Bad block at 0x10080000
> nand_read_bbt: Bad block at 0x100a0000
> nand_read_bbt: Bad block at 0x100e0000
> nand_read_bbt: Bad block at 0x10120000
> nand_read_bbt: Bad block at 0x10160000
> nand_read_bbt: Bad block at 0x101a0000
> nand_read_bbt: Bad block at 0x101c0000
> nand_read_bbt: Bad block at 0x10200000
> nand_read_bbt: Bad block at 0x10240000
> 
> And the starting kernel reports:
> 
> [...]
> NAND device: Manufacturer ID: 0x20, Chip ID: 0xac (ST Micro NAND 512MiB 1,8V 8-bit)
> Bad block table found at page 262080, version 0x01
> Bad block table found at page 262016, version 0x01
> nand_read_bbt: Bad block at 0x000001d00000
> nand_read_bbt: Bad block at 0x000010020000
> nand_read_bbt: Bad block at 0x000010040000
> nand_read_bbt: Bad block at 0x000010060000
> nand_read_bbt: Bad block at 0x000010080000
> nand_read_bbt: Bad block at 0x0000100a0000
> nand_read_bbt: Bad block at 0x0000100e0000
> nand_read_bbt: Bad block at 0x000010120000
> nand_read_bbt: Bad block at 0x000010160000
> nand_read_bbt: Bad block at 0x0000101a0000
> nand_read_bbt: Bad block at 0x0000101c0000
> nand_read_bbt: Bad block at 0x000010200000
> nand_read_bbt: Bad block at 0x000010240000
> [...]
> 
> Both are configured to use a BBT and will handle the bad blocks in the same
> manner.
> 
> Regards,
> Juergen
> 

Well, also for me. With Bbt active:

++Searching for BBT table in the flash ...
.
Found version 1 Bbt0 at block 2047 (0xffe0000)
Block 55 is bad
Block 1688 is bad
Block 1735 is bad
Block 1742 is bad
Total bad blocks: 4
... Read from 0x07ee0000-0x07f00000 at 0x00080000: ..
... Read from 0x07ed3000-0x07ed4000 at 0x0009f000: .
PMIC ID: 0x0000009b [Rev: 3.3]

...

NAND device: Manufacturer ID: 0xec, Chip ID: 0xaa (Samsung NAND 256MiB 1,8V 8-b)
Bad block table found at page 131008, version 0x01                              
Bad block table found at page 130944, version 0x01                              
nand_read_bbt: Bad block at 0x0000006e0000                                      
nand_read_bbt: Bad block at 0x00000d300000                                      
nand_read_bbt: Bad block at 0x00000d8e0000                                      
nand_read_bbt: Bad block at 0x00000d9c0000

That considering a block size of 64 pages, it is consistent.

But without bad block table enabled:

NAND device: Manufacturer ID: 0xec, Chip ID: 0xaa (Samsung NAND 256MiB 1,8V 8-b)
Scanning device for bad blocks                                                  
Bad eraseblock 4 at 0x000000080000                                              
Bad eraseblock 8 at 0x000000100000                                              
Bad eraseblock 9 at 0x000000120000                                              
Bad eraseblock 10 at 0x000000140000                                             
Bad eraseblock 11 at 0x000000160000                                             
Bad eraseblock 12 at 0x000000180000
all blocks..
Bad eraseblock 342 at 0x000002ac0000                                            
Bad eraseblock 1688 at 0x00000d300000                                           
Bad eraseblock 1735 at 0x00000d8e0000                                           
Bad eraseblock 1742 at 0x00000d9c0000                                           
Bad eraseblock 2046 at 0x00000ffc0000                                           
Bad eraseblock 2047 at 0x00000ffe0000 

All blocks went bad.
I had seen this behaviour developing the machine support for the
Armadillo500 board, and that was solved by updating the ecc layout
management due to bad 2K page sized NAND flash support.
With the new version (V2) of the driver this comes back..

-- 
Alberto!

        Be Persistent!
                - Greg Kroah-Hartman (FOSDEM 2010)

[PATCH] mx31pdk: Add NAND support

[Juergen Beisert]

On Freitag, 26. Februar 2010, Alberto Panizzo wrote:
> On ven, 2010-02-26 at 12:48 +0100, Juergen Beisert wrote:
> > Hi Alberto,
> >
> > Alberto Panizzo wrote:
> > > On ven, 2010-02-26 at 10:56 +0100, Juergen Beisert wrote:
> > > > Fabio Estevam wrote:
> > > > > > Are you sure that this works? Don't you see a lot of Bad
> > > > > > blocks reports
> > > > > > in boot messages?
> > > > >
> > > > > I followed the same approach used on other i.MX boards. This is
> > > > > what I see: ...
> > > > > NAND device: Manufacturer ID: 0xec, Chip ID: 0xaa (Samsung NAND
> > > > > 256MiB 1,8V 8-bit) Scanning device for bad blocks
> > > > > Bad eraseblock 42 at 0x000000540000
> > > > > Bad eraseblock 125 at 0x000000fa0000
> > > > > Bad eraseblock 887 at 0x000006ee0000
> > > > > Bad eraseblock 1750 at 0x00000dac0000
> > > > > Bad eraseblock 2046 at 0x00000ffc0000
> > > > > Bad eraseblock 2047 at 0x00000ffe0000
> > > > > Registering mxc_nand as whole device
> > > > >
> > > > > If I define it as:
> > > > >
> > > > > static struct mxc_nand_platform_data mx31pdk_nand_board_info = {
> > > > > 	.width = 1,
> > > > > 	.hw_ecc = 1,
> > > > > 	.flash_bbt =1,
> > > > > };
> > > >
> > > > Your bootloader also use a Bad Block Table? Then also your kernel
> > > > should use it. If hardware ECC is in use, its always a good idea to
> > > > collect the bad blocks into a BBT. Most of the time you can't control
> > > > at which offset in the OOB data the NAND controller will store the
> > > > ECC sum. There is the risk it will destroy manufacturer's bad block
> > > > markers. So, its better to collect these marked bad blocks into a BBT
> > > > the first time you use the NAND device. After that _only_ the BBT
> > > > should be used to handle bad blocks (in the boot loader and the
> > > > kernel).
> > >
> > > Thank you Juergen to participate on this thread.
> > > Ok, so with this board shall be enabled the flash_bbt checking because
> > > the bootloader uses it. But how do you explain that on Mine board the
> > > kernel recognize it correctly and in Fabio's board the kernel prompt
> > > disagree with the bootloader one? It is a kind of bootloader issue?
> >
> > Here on my i.MX35 based system the bootloader reports:
> >
> > NAND device: Manufacturer ID: 0x20, Chip ID: 0xac (ST Micro NAND 512MiB
> > 1,8V 8-bit) Bad block table found at page 262080, version 0x01
> > Bad block table found at page 262016, version 0x01
> > nand_read_bbt: Bad block at 0x01d00000
> > nand_read_bbt: Bad block at 0x10020000
> > nand_read_bbt: Bad block at 0x10040000
> > nand_read_bbt: Bad block at 0x10060000
> > nand_read_bbt: Bad block at 0x10080000
> > nand_read_bbt: Bad block at 0x100a0000
> > nand_read_bbt: Bad block at 0x100e0000
> > nand_read_bbt: Bad block at 0x10120000
> > nand_read_bbt: Bad block at 0x10160000
> > nand_read_bbt: Bad block at 0x101a0000
> > nand_read_bbt: Bad block at 0x101c0000
> > nand_read_bbt: Bad block at 0x10200000
> > nand_read_bbt: Bad block at 0x10240000
> >
> > And the starting kernel reports:
> >
> > [...]
> > NAND device: Manufacturer ID: 0x20, Chip ID: 0xac (ST Micro NAND 512MiB
> > 1,8V 8-bit) Bad block table found at page 262080, version 0x01
> > Bad block table found at page 262016, version 0x01
> > nand_read_bbt: Bad block at 0x000001d00000
> > nand_read_bbt: Bad block at 0x000010020000
> > nand_read_bbt: Bad block at 0x000010040000
> > nand_read_bbt: Bad block at 0x000010060000
> > nand_read_bbt: Bad block at 0x000010080000
> > nand_read_bbt: Bad block at 0x0000100a0000
> > nand_read_bbt: Bad block at 0x0000100e0000
> > nand_read_bbt: Bad block at 0x000010120000
> > nand_read_bbt: Bad block at 0x000010160000
> > nand_read_bbt: Bad block at 0x0000101a0000
> > nand_read_bbt: Bad block at 0x0000101c0000
> > nand_read_bbt: Bad block at 0x000010200000
> > nand_read_bbt: Bad block at 0x000010240000
> > [...]
> >
> > Both are configured to use a BBT and will handle the bad blocks in the
> > same manner.
> >
> > Regards,
> > Juergen
>
> Well, also for me. With Bbt active:
>
> ++Searching for BBT table in the flash ...
> .
> Found version 1 Bbt0 at block 2047 (0xffe0000)
> Block 55 is bad
> Block 1688 is bad
> Block 1735 is bad
> Block 1742 is bad
> Total bad blocks: 4
> ... Read from 0x07ee0000-0x07f00000 at 0x00080000: ..
> ... Read from 0x07ed3000-0x07ed4000 at 0x0009f000: .
> PMIC ID: 0x0000009b [Rev: 3.3]
>
> ...
>
> NAND device: Manufacturer ID: 0xec, Chip ID: 0xaa (Samsung NAND 256MiB 1,8V
> 8-b) Bad block table found at page 131008, version 0x01
> Bad block table found at page 130944, version 0x01
> nand_read_bbt: Bad block at 0x0000006e0000
> nand_read_bbt: Bad block at 0x00000d300000
> nand_read_bbt: Bad block at 0x00000d8e0000
> nand_read_bbt: Bad block at 0x00000d9c0000
>
> That considering a block size of 64 pages, it is consistent.
>
> But without bad block table enabled:
>
> NAND device: Manufacturer ID: 0xec, Chip ID: 0xaa (Samsung NAND 256MiB 1,8V
> 8-b) Scanning device for bad blocks
> Bad eraseblock 4 at 0x000000080000
> Bad eraseblock 8 at 0x000000100000
> Bad eraseblock 9 at 0x000000120000
> Bad eraseblock 10 at 0x000000140000
> Bad eraseblock 11 at 0x000000160000
> Bad eraseblock 12 at 0x000000180000
> all blocks..
> Bad eraseblock 342 at 0x000002ac0000
> Bad eraseblock 1688 at 0x00000d300000
> Bad eraseblock 1735 at 0x00000d8e0000
> Bad eraseblock 1742 at 0x00000d9c0000
> Bad eraseblock 2046 at 0x00000ffc0000
> Bad eraseblock 2047 at 0x00000ffe0000
>
> All blocks went bad.
> I had seen this behaviour developing the machine support for the
> Armadillo500 board, and that was solved by updating the ecc layout
> management due to bad 2K page sized NAND flash support.
> With the new version (V2) of the driver this comes back..

Maybe you previously used a driver that does not report the byte at offset 5 
in the OOB as used (for 512 byte page size). So this byte was used (maybe) by 
jffs2 for example. When you switch off the BBT now, all these blocks seems 
marked as bad, because then byte 5 will be used again. For 2k page size, the 
bad block information is stored in byte 0 and 1 in the OOB. And maybe the 
same happend to these bytes by an old driver.

Regards,
Juergen

-- 
Pengutronix e.K.                              | Juergen Beisert             |
Linux Solutions for Science and Industry      | Phone: +49-8766-939 228     |
Vertretung Sued/Muenchen, Germany             | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686              | http://www.pengutronix.de/  |

[PATCH] mx31pdk: Add NAND support

[Fabio Estevam]

Hi Sascha,

--- On Wed, 2/24/10, Fabio Estevam <fabioestevam@yahoo.com> wrote:

> From: Fabio Estevam <fabioestevam@yahoo.com>
> Subject: [PATCH] mx31pdk: Add NAND support
> To: linux-arm-kernel at lists.infradead.org
> Cc: s.hauer at pengutronix.de
> Date: Wednesday, February 24, 2010, 10:58 PM
> Add NAND support to MX31PDK board.
> 
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> ---
>  arch/arm/mach-mx3/mach-mx31_3ds.c |? ? 7
> +++++++
>  1 files changed, 7 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mach-mx3/mach-mx31_3ds.c
> b/arch/arm/mach-mx3/mach-mx31_3ds.c
> index b88c18a..2d78754 100644
> --- a/arch/arm/mach-mx3/mach-mx31_3ds.c
> +++ b/arch/arm/mach-mx3/mach-mx31_3ds.c
> @@ -34,6 +34,7 @@
>  #include <mach/board-mx31pdk.h>
>  #include <mach/imx-uart.h>
>  #include <mach/iomux-mx3.h>
> +#include <mach/mxc_nand.h>
>  #include "devices.h"
>  
>  /*!
> @@ -80,6 +81,11 @@ static struct resource
> smsc911x_resources[] = {
>  ??? },
>  };
>  
> +static struct mxc_nand_platform_data
> mx31pdk_nand_board_info = {
> +??? .width = 1,
> +??? .hw_ecc = 1,
> +};
> +
>  static struct platform_device smsc911x_device = {
>  ??? .name???
> ??? = "smsc911x",
>  ??? .id???
> ??? = -1,
> @@ -236,6 +242,7 @@ static void __init
> mxc_board_init(void)
>  ??? ??? ???
> ??? ? ? ? "mx31pdk");
>  
>  ???
> mxc_register_device(&mxc_uart_device0,
> &uart_pdata);
> +???
> mxc_register_device(&mxc_nand_device,
> &mx31pdk_nand_board_info);
>  
>  ??? if (!mx31pdk_init_expio())
>  ??? ???
> platform_device_register(&smsc911x_device);
> -- 
> 1.6.0.4

Do you think this patch is OK?

Regards,

Fabio Estevam


      

[PATCH] mx31pdk: Add NAND support

[Alberto Panizzo]

Dear Fabio,

On ven, 2010-02-26 at 17:34 -0800, Fabio Estevam wrote:
> Hi Sascha,
> 
...
> 
> Do you think this patch is OK?
> 
> Regards,
> 
> Fabio Estevam

I do not know if Sascha own an i.MX31 PDK board and I 
do not know how Sascha could say if your patch is correct or not
until WE (i.MX31 PDK owners) are in disagree on this code.
So _please_, be _kind_ and continue the debugging of this code.

(Why your bootloader correctly read the BBT and the driver not?)

Another thing: I am a new graduated developer, I do this work
keeping in mind my future and until now I am not paid to do this.
What I gain is in experience and resume with my name in the 
kernel Git log.
If you are thinking to push my entire work with your name only
because I sent you my own mx31_3ds.c out of this mailing list
you are in _wrong_.
Review of my work are welcome, BUT please, do not overcome me
thinking that Sascha can merely arbitrate between us. 

Best regards,

-- 
Alberto

        Be Persistent!
                - Greg Kroah-Hartman (FOSDEM 2010)

[PATCH] mx31pdk: Add NAND support

[Fabio Estevam]

Hi Alberto,

--- On Sat, 2/27/10, Alberto Panizzo <maramaopercheseimorto@gmail.com> wrote:

> From: Alberto Panizzo <maramaopercheseimorto@gmail.com>
> Subject: Re: [PATCH] mx31pdk: Add NAND support
> To: "Fabio Estevam" <fabioestevam@yahoo.com>
> Cc: linux-arm-kernel at lists.infradead.org, s.hauer at pengutronix.de
> Date: Saturday, February 27, 2010, 12:25 PM
> Dear Fabio,
> 
> On ven, 2010-02-26 at 17:34 -0800, Fabio Estevam wrote:
> > Hi Sascha,
> > 
> ...
> > 
> > Do you think this patch is OK?
> > 
> > Regards,
> > 
> > Fabio Estevam
> 
> I do not know if Sascha own an i.MX31 PDK board and I 
> do not know how Sascha could say if your patch is correct
> or not
> until WE (i.MX31 PDK owners) are in disagree on this code.
> So _please_, be _kind_ and continue the debugging of this
> code.

Ok, I just did what all the others i.MX boards did.

> (Why your bootloader correctly read the BBT and the driver
> not?)
> 
> Another thing: I am a new graduated developer, I do this
> work
> keeping in mind my future and until now I am not paid to do
> this.
> What I gain is in experience and resume with my name in the
> 
> kernel Git log.

This is great. Please continue with this work.

> If you are thinking to push my entire work with your name
> only
> because I sent you my own mx31_3ds.c out of this mailing
> list
> you are in _wrong_.

This is not my intention. The mx31_3ds.c you sent me helped me to solve a different issue related to the LCD driver. The NAND patch I submitted in this list is not the same you had in your code as I did not pass flash_bbt.
So your comment that I am pushing your entire work is not fair.

> Review of my work are welcome, BUT please, do not overcome
> me
> thinking that Sascha can merely arbitrate between us. 
> 

Again, Alberto, I would love to work together with you and make i.MX support better.

Regards,

Fabio Estevam


      

[PATCH] mx31pdk: Add NAND support

[Alberto Panizzo]

On sab, 2010-02-27 at 07:38 -0800, Fabio Estevam wrote:
> Hi Alberto,
> 
> --- On Sat, 2/27/10, Alberto Panizzo <maramaopercheseimorto@gmail.com> wrote:
> 
> > From: Alberto Panizzo <maramaopercheseimorto@gmail.com>
> > Subject: Re: [PATCH] mx31pdk: Add NAND support
> > To: "Fabio Estevam" <fabioestevam@yahoo.com>
> > Cc: linux-arm-kernel at lists.infradead.org, s.hauer at pengutronix.de
> > Date: Saturday, February 27, 2010, 12:25 PM
> > Dear Fabio,
> > 
> > On ven, 2010-02-26 at 17:34 -0800, Fabio Estevam wrote:
> > > Hi Sascha,
> > > 
> > ...
> > > 
> > > Do you think this patch is OK?
> > > 
> > > Regards,
> > > 
> > > Fabio Estevam
> > 
> > I do not know if Sascha own an i.MX31 PDK board and I 
> > do not know how Sascha could say if your patch is correct
> > or not
> > until WE (i.MX31 PDK owners) are in disagree on this code.
> > So _please_, be _kind_ and continue the debugging of this
> > code.
> 
> Ok, I just did what all the others i.MX boards did.
> 
> > (Why your bootloader correctly read the BBT and the driver
> > not?)
> > 
> > Another thing: I am a new graduated developer, I do this
> > work
> > keeping in mind my future and until now I am not paid to do
> > this.
> > What I gain is in experience and resume with my name in the
> > 
> > kernel Git log.
> 
> This is great. Please continue with this work.
> 
> > If you are thinking to push my entire work with your name
> > only
> > because I sent you my own mx31_3ds.c out of this mailing
> > list
> > you are in _wrong_.
> 
> This is not my intention. The mx31_3ds.c you sent me helped me to solve a different issue related to the LCD driver. The NAND patch I submitted in this list is not the same you had in your code as I did not pass flash_bbt.
> So your comment that I am pushing your entire work is not fair.
> 
> > Review of my work are welcome, BUT please, do not overcome
> > me
> > thinking that Sascha can merely arbitrate between us. 
> > 
> 
> Again, Alberto, I would love to work together with you and make i.MX support better.
> 
> Regards,
> 
> Fabio Estevam
> 

Ok Fabio, nevermind.. I trust the pure intentions of the kernel community
and yours. For one moment I've lost the compass (we say this in Italy, I don't
know if it is valid too here) and I apologize for unfairness (I've spent months
on this board! urk!)

Returning on the subject, I was not the first owner of the i.MX pdk board in my
possess, and since the freescale NAND driver uses a private OOB schema, others
could have soiled my nand chip overwriting the Bad block bits in the OOB.

The things are two: 
1- I have to clean my NAND chip. -> the bad block scanning could 
   get rid of true Bad blocks.
2- Why the mxc_nand driver do not read your bbt as the 
   bootloader do?
   What version of redboot are you using?
   I am Very curious on this disagreement..!

-- 
Alberto!

        Be Persistent!
                - Greg Kroah-Hartman (FOSDEM 2010)

[PATCH] mx31pdk: Add NAND support

[Fabio Estevam]

--- On Thu, 2/25/10, Alberto Panizzo <maramaopercheseimorto@gmail.com> 
...
> What kernel are you running? In particular, what version
> of mxc_nand.c are you building?
> Recently the mxc_nand.c has been updated to support newer
> i.MX SoC
> and the problem come after this update. (add NFC_NAND V2
> support)

Running latest kernel from mxc-master.

Regards,

Fabio Estevam


      

[PATCH] mx31pdk: Add NAND support

[Alberto Panizzo]

On gio, 2010-02-25 at 14:22 -0800, Fabio Estevam wrote:
> --- On Thu, 2/25/10, Fabio Estevam <fabioestevam@yahoo.com> wrote:
> 
> ...
> 
> > > 
> > > Are you sure that this works? Don't you see a lot of
> > Bad
> > > blocks reports
> > > in boot messages?
> > 
> > I followed the same approach used on other i.MX boards.
> > This is what I see:
> > ...
> > NAND device: Manufacturer ID: 0xec, Chip ID: 0xaa (Samsung
> > NAND 256MiB 1,8V 8-bit)         
> > Scanning device for bad blocks       
> > Bad eraseblock 42 at 0x000000540000     
> > Bad eraseblock 125 at 0x000000fa0000     
> > Bad eraseblock 887 at 0x000006ee0000     
> > Bad eraseblock 1750 at 0x00000dac0000     
> > Bad eraseblock 2046 at 0x00000ffc0000     
> > Bad eraseblock 2047 at 0x00000ffe0000     
> >                
> 
> Just looked at what Redboot reported:
> 
> ++Searching for BBT table in the flash ...                                      
> .                                                                               
> Found version 1 Bbt0 at block 2047 (0xffe0000)                                  
> Block 42 is bad                                                                 
> Block 125 is bad                                                                
> Block 887 is bad                                                                
> Block 1750 is bad                                                               
> Total bad blocks: 4   
> 
> So the only mismatch is 2046 eraseblock.
> 
> Regards,
> 
> Fabio Estevam
> 

What kernel are you running? In particular, what version
of mxc_nand.c are you building?
Recently the mxc_nand.c has been updated to support newer i.MX SoC
and the problem come after this update. (add NFC_NAND V2 support)

-- 
Alberto!

        Be Persistent!
                - Greg Kroah-Hartman (FOSDEM 2010)

[PATCH] mx31pdk: Add NAND support

[Fabio Estevam]

--- On Thu, 2/25/10, Fabio Estevam <fabioestevam@yahoo.com> wrote:

...

> > 
> > Are you sure that this works? Don't you see a lot of
> Bad
> > blocks reports
> > in boot messages?
> 
> I followed the same approach used on other i.MX boards.
> This is what I see:
> ...
> NAND device: Manufacturer ID: 0xec, Chip ID: 0xaa (Samsung
> NAND 256MiB 1,8V 8-bit)? ? ? ? ?
> Scanning device for bad blocks? ? ? ?
> Bad eraseblock 42 at 0x000000540000? ? ?
> Bad eraseblock 125 at 0x000000fa0000? ? ?
> Bad eraseblock 887 at 0x000006ee0000? ? ?
> Bad eraseblock 1750 at 0x00000dac0000? ? ?
> Bad eraseblock 2046 at 0x00000ffc0000? ? ?
> Bad eraseblock 2047 at 0x00000ffe0000? ? ?
> ? ? ? ? ? ? ? ?

Just looked at what Redboot reported:

++Searching for BBT table in the flash ...                                      
.                                                                               
Found version 1 Bbt0 at block 2047 (0xffe0000)                                  
Block 42 is bad                                                                 
Block 125 is bad                                                                
Block 887 is bad                                                                
Block 1750 is bad                                                               
Total bad blocks: 4   

So the only mismatch is 2046 eraseblock.

Regards,

Fabio Estevam