ONFI 4GB and beyond NAND support

ONFI 4GB and beyond NAND support

[Blair Barnett]

I have two questions for the MTD gang, but couldn't find the answer in 
the archives, nor elsewhere on the web.

1. What's the plan, if any, for the MTD NAND layer to support the ONFI 
standard?
2. What's the plan, if any, for the MTD NAND layer to support 4 GB NANDs 
(and greater)?

The two questions could be linked, as we're looking at Micron 4 GB, 8 GB 
and 16 GB MLC parts that support the ONFI standard, that we'd like to 
use on a board that my company is building.

I've hacked support for the 4 GB part by having the MTD layer recognize 
it as 4 GB - 1 erase block, which gets it inside the uint32_t limit. 
That hack won't really work for 8 GB and beyond. I'd certainly be 
willing to help with the design review and coding if I had a clue what 
folks were thinking.

Thanks in advance for any pointers!

Blair Barnett

RE: ONFI 4GB and beyond NAND support

[Paulraj, Sandeep]

> 
> I have two questions for the MTD gang, but couldn't find the answer in
> the archives, nor elsewhere on the web.
> 
> 1. What's the plan, if any, for the MTD NAND layer to support the ONFI
> standard?
I guess somebody has to write the necessary code and send the patch.
ONFI NANds get all the necessary info from a param table I believe. 

> 2. What's the plan, if any, for the MTD NAND layer to support 4 GB NANDs
> (and greater)?
This is already there for more than a year. Use the latest kernels

> 
> The two questions could be linked, as we're looking at Micron 4 GB, 8 GB
> and 16 GB MLC parts that support the ONFI standard, that we'd like to
> use on a board that my company is building.
> 
> I've hacked support for the 4 GB part by having the MTD layer recognize
> it as 4 GB - 1 erase block, which gets it inside the uint32_t limit.
> That hack won't really work for 8 GB and beyond. I'd certainly be
> willing to help with the design review and coding if I had a clue what
> folks were thinking.
This means that you are probably using an old kernel. Update to the newest kernels.

> 
> Thanks in advance for any pointers!
> 
> Blair Barnett
> 
Sandeep

Re: ONFI 4GB and beyond NAND support

[Blair Barnett]

Paulraj, Sandeep wrote:
>   
>> I have two questions for the MTD gang, but couldn't find the answer in
>> the archives, nor elsewhere on the web.
>>
>> 1. What's the plan, if any, for the MTD NAND layer to support the ONFI
>> standard?
>>     
> I guess somebody has to write the necessary code and send the patch.
> ONFI NANds get all the necessary info from a param table I believe. 
>   
O.K. That's fair.
>   
>> 2. What's the plan, if any, for the MTD NAND layer to support 4 GB NANDs
>> (and greater)?
>>     
> This is already there for more than a year. Use the latest kernels
>   
Let's see. I'm using 2.6.33, so that seems like a pretty new kernel. I 
think the problem may in the code for figuring out the NAND geometry in 
nand_get_flash_type(). If type->pagesize == 0,  0x46 is the extid value. 
Unfortunately, this decodes in the NAND code to the following geometry:

Writesize = 4096 bytes
oobsize= 128 bytes
erasesize = 64 K bytes (extid & 0x03)

Reading the chip's ONFI Page parameters, one gets this geometry:

writesize = 4096 bytes
oobsize = 224 bytes
erasesize = 1024 K bytes

It appears a simple fix for the erasesize is to use 0x7 as the mask, but 
the oobsize is a little more problematic.

The code
mtd->oobsize = (8 << (extid & 0x01)) * (mtd->writesize >> 9);

doesn't really work to create a 224 byte oobsize value, not to mention I 
don't know where to look to create the ECC structure required.

Do you have a preference for how to fix this?

-blair

RE: ONFI 4GB and beyond NAND support

[Paulraj, Sandeep]

> -----Original Message-----
> From: Blair Barnett [mailto:bbarnett@nethra.us.com]
> Sent: Friday, March 05, 2010 3:08 PM
> To: Paulraj, Sandeep
> Cc: linux-mtd@lists.infradead.org
> Subject: Re: ONFI 4GB and beyond NAND support
> 
> Paulraj, Sandeep wrote:
> >
> >> I have two questions for the MTD gang, but couldn't find the answer in
> >> the archives, nor elsewhere on the web.
> >>
> >> 1. What's the plan, if any, for the MTD NAND layer to support the ONFI
> >> standard?
> >>
> > I guess somebody has to write the necessary code and send the patch.
> > ONFI NANds get all the necessary info from a param table I believe.
> >
> O.K. That's fair.
> >
> >> 2. What's the plan, if any, for the MTD NAND layer to support 4 GB
> NANDs
> >> (and greater)?
> >>
> > This is already there for more than a year. Use the latest kernels
> >
> Let's see. I'm using 2.6.33, so that seems like a pretty new kernel. I
> think the problem may in the code for figuring out the NAND geometry in
> nand_get_flash_type(). If type->pagesize == 0,  0x46 is the extid value.
> Unfortunately, this decodes in the NAND code to the following geometry:
Its been a while but I vaguely remember that instead of actually writing code for the param table I hardcoded the required values in the nand_ids.c and it worked fine for me
> 
> Writesize = 4096 bytes
> oobsize= 128 bytes
> erasesize = 64 K bytes (extid & 0x03)
> 
> Reading the chip's ONFI Page parameters, one gets this geometry:
> 
> writesize = 4096 bytes
> oobsize = 224 bytes
> erasesize = 1024 K bytes
> 
> It appears a simple fix for the erasesize is to use 0x7 as the mask, but
> the oobsize is a little more problematic.

I had similar concerns.
What we did was to just assume that the OOB size was 128 instead of 224.
We just don't use and our driver sis not concerned about the other 96 bytes.
> 
> The code
> mtd->oobsize = (8 << (extid & 0x01)) * (mtd->writesize >> 9);
> 
> doesn't really work to create a 224 byte oobsize value, not to mention I
> don't know where to look to create the ECC structure required.
As I said above just assume that the OOB is 128 bytes

> 
> Do you have a preference for how to fix this?
> 
> -blair
> 

Re: ONFI 4GB and beyond NAND support

[Blair Barnett]

>> It appears a simple fix for the erasesize is to use 0x7 as the mask, but
>> the oobsize is a little more problematic.
>>     
>
> I had similar concerns.
> What we did was to just assume that the OOB size was 128 instead of 224.
> We just don't use and our driver sis not concerned about the other 96 bytes.
>   
>> The code
>> mtd->oobsize = (8 << (extid & 0x01)) * (mtd->writesize >> 9);
>>
>> doesn't really work to create a 224 byte oobsize value, not to mention I
>> don't know where to look to create the ECC structure required.
>>     
> As I said above just assume that the OOB is 128 bytes
>
>   
O.K., thanks for the feedback. I thought the bigger OOB size is there 
for allowing more ECC bytes, since the page size is much bigger than 
before and will require more error correction bytes.

I'll work on an ONFI implementation and get it out to the list in the 
next few weeks.

-blair