ONFI 4GB and beyond NAND support
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
Quoted 8 lines
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.
Quoted 2 lines
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
Quoted 10 lines
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_tlimit. 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.
Quoted 5 lines
Thanks in advance for any pointers!
Blair Barnett
Sandeep
Quoted 10 lines · Sandeep
Quoted 7 lines
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.
Quoted 6 lines
Quoted 4 lines
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 codemtd->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
Quoted 24 lines
-----Original Message-----
From: Blair Barnett [mailto:[email protected]]
Sent: Friday, March 05, 2010 3:08 PM
To: Paulraj, Sandeep
Cc: [email protected]
Subject: Re: ONFI 4GB and beyond NAND supportQuoted 10 lines · Sandeep
Quoted 7 lines
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.
Quoted 2 lines
Quoted 2 lines
2. What's the plan, if any, for the MTD NAND layer to support 4 GB
NANDs
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
(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(). Iftype->pagesize== 0,0x46is 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
Quoted 5 lines
Writesize = 4096 bytes
oobsize= 128 bytes
erasesize = 64 K bytes (extid &0x03)
Quoted 8 lines
Reading the chip's ONFI Page parameters, one gets this geometry:
writesize = 4096 bytes
oobsize = 224 bytes
erasesize = 1024 K bytesIt appears a simple fix for the erasesize is to use
0x7as 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.
Quoted 6 lines
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
Quoted 5 lines
Do you have a preference for how to fix this?
-blair
Quoted 9 lines
Quoted 4 lines
It appears a simple fix for the erasesize is to use
0x7as 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.
Quoted 9 lines
Quoted 6 lines
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