On Wed, 21 Jul 2010 13:59:14 +0800 Jason Liu liu.h.jason@gmail.com wrote:
2010/7/21 Scott Wood scottwood@freescale.com:
On Tue, 20 Jul 2010 08:43:55 +0800 Lei Wen adrian.wenl@gmail.com wrote:
On Tue, Jul 20, 2010 at 4:22 AM, Scott Wood scottwood@freescale.com wrote:
On Mon, Jul 19, 2010 at 09:05:05PM +0800, Lei Wen wrote:
Rebased version for this nand chip has one problem in detecting its page size using in nand_base.c. If we set page size 0 in nand_ids.c, we would get the calculation result as page size 2048, while the true page size is 4096.
Is the ID data bad, or is there a bug in nand_get_flash_type(), or is it some new ID format that needs support?
Samsung seem modify the ID name rule, which make the calculation method nand_get_flash_type doesn't work. In mainline linux code, it give a hardcode way to identify this type of nand with new calculation method.
Let's do the same thing Linux does, then.
In fact, Linux(nand_base.c) does not handle the pagesize, oobsize correctly for the new NAND.
What should it be doing instead for this chip?
And actually, it's real difficult for providing one common caculation rule for all the NAND flash since the NAND ID data layout is not much the same as each other. Maybe, this is why there is not such patch in linux to fix this issue.
It doesn't need to be one common calculation, as long as enough of the ID is common that we can figure out which calculation to use. How many variants are there, and is how complicated is it to figure out which variant it is?
Alternatively, hard-coding it may be the only way to stay sane -- but in that case, we need to make sure we've got a good enough match. Do we need to add the manufacturer to the ID table? I'm assuming that something motivated the switch away from putting writesize/erasesize in the ID table.
And it looks like if pagesize is hardcoded, erasesize must be as well.
-Scott