ARM: MTD: mxc_nand: Question on NAND Flash support for mxc

ARM: MTD: mxc_nand: Question on NAND Flash support for mxc

[Alberto Panizzo]

Hi all!

I am trying to give support for NAND flash device to Atmark Armadillo 500
developing board.
This board has an iMX31 processor and is shipped with an ST Micro NAND 256MiB 3,3V 8-bit Flash.
Atmark support this board with an old 2.6.26 kernel with some modification.
For this NAND Flash Atmark installed the old Freescale mxc_nd driver brought up by
Sascha Hauer in the on tree mxc_nand.

Now the problem:
With the old driver kernel message is as follow:
--
MXC MTD nand Driver 2.0
NAND device: Manufacturer ID: 0x20, Chip ID: 0xda (ST Micro NAND 256MiB 3,3V 8-bit)
Scanning device for bad blocks
Bad eraseblock 592 at 0x04a00000
Creating 4 MTD partitions on "NAND 256MiB 3,3V 8-bit":
--

With the new in tree driver i get:
--
NAND device: Manufacturer ID: 0x20, Chip ID: 0xda (ST Micro NAND 256MiB 3,3V 8-bit)
Scanning device for bad blocks
Bad eraseblock 0 at 0x000000000000
Bad eraseblock 1 at 0x000000020000
Bad eraseblock 2 at 0x000000040000
Bad eraseblock 3 at 0x000000060000
Bad eraseblock 4 at 0x000000080000
Bad eraseblock 5 at 0x0000000a0000
Bad eraseblock 6 at 0x0000000c0000
Bad eraseblock 7 at 0x0000000e0000
.... all blocks ...
Bad eraseblock 2045 at 0x00000ffa0000
Bad eraseblock 2046 at 0x00000ffc0000
Bad eraseblock 2047 at 0x00000ffe0000
RedBoot partition parsing not available
Registering mxc_nand as whole device
--

All blocks are recognized as Bad eraseblocks! 

Digging the problem I switch off bbt scanning  and Bad eraseblock check in flash_eraseall (mtd utils 1.2.0)
running this utility results  in a mixture of:
--
Erasing 128 Kibyte @ 2e60000 -- 18 % complete.
flash_eraseall: /dev/mtd4: MTD Erase failure: Input/output error

Erasing 128 Kibyte @ 2ea0000 -- 18 % nand_erase: attempt to erase a bad block at page 0x00005e40
--

Thanks for any suggestions.

Alberto!

Re: ARM: MTD: mxc_nand: Question on NAND Flash support for mxc

[Magnus Lilja]

Hi

2009/5/21 Alberto Panizzo <maramaopercheseimorto@gmail.com>:
> Hi all!
>
> I am trying to give support for NAND flash device to Atmark Armadillo 500
> developing board.
> This board has an iMX31 processor and is shipped with an ST Micro NAND 256MiB 3,3V 8-bit Flash.
> Atmark support this board with an old 2.6.26 kernel with some modification.
> For this NAND Flash Atmark installed the old Freescale mxc_nd driver brought up by
> Sascha Hauer in the on tree mxc_nand.

Is the ST Micro NAND device a small page or large page NAND? I ran
into problems when trying to use the MXC-driver from the mainline
Linux kernel on the i.MX31 PDK board which has a large page device
mounted. I haven't had time to dig into the details yet though.

Regards, Magnus

Re: ARM: MTD: mxc_nand: Question on NAND Flash support for mxc

[Alberto Panizzo]

On Thu, 21 May 2009 18:11:57 +0200
Magnus Lilja <lilja.magnus@gmail.com> wrote:

> Hi
> 
> 2009/5/21 Alberto Panizzo <maramaopercheseimorto@gmail.com>:
> > Hi all!
> >
> > I am trying to give support for NAND flash device to Atmark Armadillo 500
> > developing board.
> > This board has an iMX31 processor and is shipped with an ST Micro NAND 256MiB 3,3V 8-bit Flash.
> > Atmark support this board with an old 2.6.26 kernel with some modification.
> > For this NAND Flash Atmark installed the old Freescale mxc_nd driver brought up by
> > Sascha Hauer in the on tree mxc_nand.
> 
> Is the ST Micro NAND device a small page or large page NAND? I ran
> into problems when trying to use the MXC-driver from the mainline
> Linux kernel on the i.MX31 PDK board which has a large page device
> mounted. I haven't had time to dig into the details yet though.
> 
> Regards, Magnus

It is an NAND02GW3B2CN6 with 2112 Byte/1056 Word Page, in mxcnd_probe at row 960
there is host->pagesize_2k = 0; setting to 1 do not change in results..

Re: ARM: MTD: mxc_nand: Question on NAND Flash support for mxc

[Vladimir Barinov]

Hello Manus,

Magnus Lilja wrote:
> Hi
>
> 2009/5/21 Alberto Panizzo <maramaopercheseimorto@gmail.com>:
>   
>> Hi all!
>>
>> I am trying to give support for NAND flash device to Atmark Armadillo 500
>> developing board.
>> This board has an iMX31 processor and is shipped with an ST Micro NAND 256MiB 3,3V 8-bit Flash.
>> Atmark support this board with an old 2.6.26 kernel with some modification.
>> For this NAND Flash Atmark installed the old Freescale mxc_nd driver brought up by
>> Sascha Hauer in the on tree mxc_nand.
>>     
>
> Is the ST Micro NAND device a small page or large page NAND? I ran
> into problems when trying to use the MXC-driver from the mainline
> Linux kernel on the i.MX31 PDK board which has a large page device
> mounted. I haven't had time to dig into the details yet though.
>   
I have the patch to support 2k pagesizes tested on mx31pdk. Will post in 
separate thread.

Regards,
Vladimir

Re: ARM: MTD: mxc_nand: Question on NAND Flash support for mxc

[Claudio Lanconelli]

Alberto Panizzo ha scritto:
> Hi all!
> 
> I am trying to give support for NAND flash device to Atmark Armadillo 500
> developing board.
> This board has an iMX31 processor and is shipped with an ST Micro NAND 256MiB 3,3V 8-bit Flash.
> Atmark support this board with an old 2.6.26 kernel with some modification.
> For this NAND Flash Atmark installed the old Freescale mxc_nd driver brought up by
> Sascha Hauer in the on tree mxc_nand.
> 
> Now the problem:
> With the old driver kernel message is as follow:
> --
> MXC MTD nand Driver 2.0
> NAND device: Manufacturer ID: 0x20, Chip ID: 0xda (ST Micro NAND 256MiB 3,3V 8-bit)
> Scanning device for bad blocks
> Bad eraseblock 592 at 0x04a00000
> Creating 4 MTD partitions on "NAND 256MiB 3,3V 8-bit":
> --
> 
> With the new in tree driver i get:
> --
> NAND device: Manufacturer ID: 0x20, Chip ID: 0xda (ST Micro NAND 256MiB 3,3V 8-bit)
> Scanning device for bad blocks
> Bad eraseblock 0 at 0x000000000000
> Bad eraseblock 1 at 0x000000020000
> Bad eraseblock 2 at 0x000000040000
> Bad eraseblock 3 at 0x000000060000
> Bad eraseblock 4 at 0x000000080000
> Bad eraseblock 5 at 0x0000000a0000
> Bad eraseblock 6 at 0x0000000c0000
> Bad eraseblock 7 at 0x0000000e0000
> .... all blocks ...
> Bad eraseblock 2045 at 0x00000ffa0000
> Bad eraseblock 2046 at 0x00000ffc0000
> Bad eraseblock 2047 at 0x00000ffe0000
> RedBoot partition parsing not available
> Registering mxc_nand as whole device
> --
> 
> All blocks are recognized as Bad eraseblocks! 

Hi Alberto,

The problem is that mx nand controller doesn't use standard oob layout for large page nand, instead it uses the same layout of the small page nand, some sort of concatenation of four small pages oob.

AFAIK you need at least two changes to use large page nand.

The first one is to use a correct oob layout (especially if you plan to use YAFFS):

+static struct nand_ecclayout nand_hw_eccoob_2k = {
+	.eccbytes = 20,
+	.eccpos = {6, 7, 8, 9, 10, 22, 23, 24, 25, 26,
+		   38, 39, 40, 41, 42, 54, 55, 56, 57, 58},
+	.oobfree = {
+		    {.offset = 0,
+		     .length = 5},
+
+		    {.offset = 11,
+		     .length = 10},
+
+		    {.offset = 27,
+		     .length = 10},
+
+		    {.offset = 43,
+		     .length = 10},
+
+		    {.offset = 59,
+		     .length = 5}
+		    }
+};
+

The second one is to look for bad block descriptor on location 5 instead of 0. Location 5 is the standard for small page devices. You also need to check that the nand flash you use is shipped with both 0 and 5 locations marked for bad blocks.

+	if (!this->badblock_pattern) {
+		if (mtd->writesize == 2048)
+			this->badblock_pattern = &smallpage_memorybased;
+		else
+			this->badblock_pattern = (mtd->writesize > 512) ?
+			    &largepage_memorybased : &smallpage_memorybased;
+	}

Give a look at Freescale patches to find all the changes needed.
Probably there is a better way to solve the problem, any suggestion by MTD gurus?

Cheers,
Claudio Lanconelli

Re: ARM: MTD: mxc_nand: Question on NAND Flash support for mxc

[Vladimir Barinov]

Hello Claudio,

Claudio Lanconelli wrote:
> Alberto Panizzo ha scritto:
>   
>> Hi all!
>>
>> I am trying to give support for NAND flash device to Atmark Armadillo 500
>> developing board.
>> This board has an iMX31 processor and is shipped with an ST Micro NAND 256MiB 3,3V 8-bit Flash.
>> Atmark support this board with an old 2.6.26 kernel with some modification.
>> For this NAND Flash Atmark installed the old Freescale mxc_nd driver brought up by
>> Sascha Hauer in the on tree mxc_nand.
>>
>> Now the problem:
>> With the old driver kernel message is as follow:
>> --
>> MXC MTD nand Driver 2.0
>> NAND device: Manufacturer ID: 0x20, Chip ID: 0xda (ST Micro NAND 256MiB 3,3V 8-bit)
>> Scanning device for bad blocks
>> Bad eraseblock 592 at 0x04a00000
>> Creating 4 MTD partitions on "NAND 256MiB 3,3V 8-bit":
>> --
>>
>> With the new in tree driver i get:
>> --
>> NAND device: Manufacturer ID: 0x20, Chip ID: 0xda (ST Micro NAND 256MiB 3,3V 8-bit)
>> Scanning device for bad blocks
>> Bad eraseblock 0 at 0x000000000000
>> Bad eraseblock 1 at 0x000000020000
>> Bad eraseblock 2 at 0x000000040000
>> Bad eraseblock 3 at 0x000000060000
>> Bad eraseblock 4 at 0x000000080000
>> Bad eraseblock 5 at 0x0000000a0000
>> Bad eraseblock 6 at 0x0000000c0000
>> Bad eraseblock 7 at 0x0000000e0000
>> .... all blocks ...
>> Bad eraseblock 2045 at 0x00000ffa0000
>> Bad eraseblock 2046 at 0x00000ffc0000
>> Bad eraseblock 2047 at 0x00000ffe0000
>> RedBoot partition parsing not available
>> Registering mxc_nand as whole device
>> --
>>
>> All blocks are recognized as Bad eraseblocks! 
>>     
>
> Hi Alberto,
>
> The problem is that mx nand controller doesn't use standard oob layout for large page nand, instead it uses the same layout of the small page nand, some sort of concatenation of four small pages oob.
>
> AFAIK you need at least two changes to use large page nand.
>
> The first one is to use a correct oob layout (especially if you plan to use YAFFS):
>   
Agree, it's needed to use 64k oob layout for 2k page sizes.
> +static struct nand_ecclayout nand_hw_eccoob_2k = {
> +	.eccbytes = 20,
> +	.eccpos = {6, 7, 8, 9, 10, 22, 23, 24, 25, 26,
> +		   38, 39, 40, 41, 42, 54, 55, 56, 57, 58},
> +	.oobfree = {
> +		    {.offset = 0,
> +		     .length = 5},
> +
> +		    {.offset = 11,
> +		     .length = 10},
> +
> +		    {.offset = 27,
> +		     .length = 10},
> +
> +		    {.offset = 43,
> +		     .length = 10},
> +
> +		    {.offset = 59,
> +		     .length = 5}
> +		    }
> +};
> +
>
> The second one is to look for bad block descriptor on location 5 instead of 0. Location 5 is the standard for small page devices. You also need to check that the nand flash you use is shipped with both 0 and 5 locations marked for bad blocks.
>
> +	if (!this->badblock_pattern) {
> +		if (mtd->writesize == 2048)
> +			this->badblock_pattern = &smallpage_memorybased;
> +		else
> +			this->badblock_pattern = (mtd->writesize > 512) ?
> +			    &largepage_memorybased : &smallpage_memorybased;
> +	}
>   
Actually I don't see the problem to use default bbt table for 
largepages, i.e. first 2 byte in oob layer. The nand_hw_eccoob_2k table 
above has the {0-5} marked as free for jffs2/yaffs oob info, so I think 
that making first bytes as not free is enough to protect them.
> Give a look at Freescale patches to find all the changes needed.
>   
Also the mx31 SoC will probably need to enable NFMS bit in RCSR 
register, do this in arch code or bootloader:
+       /* set NAND page size to 2k if not configured via boot mode pins */
+       writel(readl(MXC_CCM_RCSR) | (1 << 30), MXC_CCM_RCSR);

Regards,
Vladimir