nand/denali: Add bad block management for MRST
Subsystems (2)
PATCH v2 2/6 nand/denali: Add bad block management for MRST
From 675731420dabad00dc4337c3e89613c606f52906 Mon Sep 17 00:00:00 2001
From: Chuanxiao Dong <[email protected]>
Date: Thu, 12 Aug 2010 17:56:30 +0800
Subject: [PATCH 2/6] nand/denali: Add bad block management for MRST
Denali controller in MRST uses 15bits or 8bits ECC correction according to the size of NAND chip OOB area. Both of these two corrections will consume most of the OOB bytes. There are no enough bytes for MTD bad block management to use for some kind of NAND chip.
On the other side, when use MLC NAND, OOB area is not a trust area to store BBT.
So here design a new bad block mangement for denali controller.
Driver will scan available NAND blocks to create a memery BBT for the first time and store it in the last 8(default) blocks. The next time driver only need to read BBT from these blocks out and create a memery BBT. Also add a kernel config to let user choose how many blocks to store BBT for MRST.
--- drivers/mtd/nand/Kconfig | 26 +++- drivers/mtd/nand/denali.c | 484 ++++++++++++++++++++++++++++++++++++++++++++- drivers/mtd/nand/denali.h | 16 ++ 3 files changed, 523 insertions(+), 3 deletions(-)
drivers/mtd/nand/Kconfig +25 -1
@@ -56,7 +56,7 @@ config MTD_NAND_DENALI help Enable the driver for NAND flash on Intel Moorestown, using the Denali NAND controller core. - + config MTD_NAND_DENALI_SCRATCH_REG_ADDR hex "Denali NAND size scratch register address" default "0xFF108018"
@@ -68,6 +68,30 @@ config MTD_NAND_DENALI_SCRATCH_REG_ADDR scratch register here to enable this feature. On Intel Moorestown boards, the scratch register is at 0xFF108018. +choice + prompt "Compile for" + depends on MTD_NAND_DENALI + default MRST_NAND_CONTROLLER + +config MRST_NAND_CONTROLLER + bool "MRST NAND controller" + help + +config CE4100_NAND_CONTROLLER + bool "CE4100 NAND controller" + help + +endchoice + +config MTD_NAND_DENALI_BBT_BLKNUM + int "blocknums to store BBT -- MRST platform will use this" + default 8 + range 2 10 + depends on MTD_NAND_DENALI && MRST_NAND_CONTROLLER + help + This parameter defines the blocknums which is used to store Bad + Block Table. + config MTD_NAND_EDB7312 tristate "Support for Cirrus Logic EBD7312 evaluation board" depends on ARCH_EDB7312
drivers/mtd/nand/denali.c +482 -2
514 lines not on this page · raw message
drivers/mtd/nand/denali.h +16 -0
@@ -714,6 +714,7 @@#define LLD_MAX_FLASH_BANKS 4#define DENALI_BUF_SIZE (NAND_MAX_PAGESIZE + NAND_MAX_OOBSIZE) +#define BBT_BLKNUM CONFIG_MTD_NAND_DENALI_BBT_BLKNUMstruct nand_buf {int head;
@@ -724,6 +725,14 @@ struct nand_buf {#define INTEL_CE4100 1#define INTEL_MRST 2 +#define HEAD_LEN 44 + +/*denali_bbt_info: To store basic BBT information*/ +struct denali_bbt_info { +uint32_t version; +uint32_t bbtlen; +uint32_t serial; +};struct denali_nand_info {struct mtd_info mtd;
@@ -748,9 +757,16 @@ struct denali_nand_info {uint32_t devnum;/* represent how many nands connected */ uint32_t fwblks;/* represent how many blocks FW used */ +uint32_t manageblks;/* how many blocks managed by FW */ uint32_t totalblks;uint32_t blksperchip; +uint32_t bbtstartblk; +uint32_t bbtblks;uint32_t bbtskipbytes; + +/*used for BBT management*/ +struct denali_bbt_info bbtinfo; + uint32_t availbbtblk; /* how many available blocks can store BBT */ };#endif /*_LLD_NAND_*/
Signature · 1 line
1.6.6.1
Quoted 5 lines · Chuanxiao.Dong
drivers/mtd/nand/Kconfig +4
-0+choice + prompt "Compile for" + depends on MTD_NAND_DENALI + default MRST_NAND_CONTROLLER
drivers/mtd/nand/Kconfig config MTD_NAND_DENALI_SCRATCH_REG_ADDR · line 84
Quoted 10 lines
drivers/mtd/nand/Kconfig +10
-0+ +config MRST_NAND_CONTROLLER + bool "MRST NAND controller" + help + +config CE4100_NAND_CONTROLLER + bool "CE4100 NAND controller" + help + +endchoice
Hm, I don't like this much -- we ought to be able to compile a generic kernel which will support *both* MRST and CE4100.
(Actually, we *can* -- you don't use these options anywhere (yet?) except as a gateway to letting us set the BBT_BLOCKNUM value.
It may also be worth switching CE4100 to use the same BBT scheme as you're using in MRST -- don't all the same arguments apply there?
I'm guessing that you didn't change CE4100 just because you want to retain on-medium compatibility? Let's ask Jason -- I suspect it would be OK to change...
I'm also somewhat dubious about the way we abandon the BBT when we're going to use Spectra -- and especially the use of the scratch register. Can't we put that information into PCI config space if we really must have it? I'll look over that in more detail...
Signature · 2 lines
David Woodhouse Open Source Technology Centre [email protected] Intel Corporation
Quoted 9 lines
(Actually, we *can* -- you don't use these options anywhere (yet?) except as a gateway to letting us set the
BBT_BLOCKNUMvalue.It may also be worth switching CE4100 to use the same BBT scheme as you're using in MRST -- don't all the same arguments apply there?
I'm guessing that you didn't change CE4100 just because you want to retain on-medium compatibility? Let's ask Jason -- I suspect it would be OK to change...
[Chuanxiao Dong] It will be better if CE4100 can use this BBT. But from the original denali.c, I found CE4100 maybe don't have a protected partition like MRST does. In MRST, its IAFW is stored in this partition. This partition is created by SCU FW. So MTD driver doesn't have any permission to access this partition. So the BBT can't be created by scanning NAND from the beginning. It need to skip the protected partition. Here is the biggest difference between MRST and CE4100. This is just I got from code..... Never confirmed with DHG guys.
Quoted 4 lines
I'm also somewhat dubious about the way we abandon the BBT when we're going to use Spectra -- and especially the use of the scratch register. Can't we put that information into PCI config space if we really must have it? I'll look over that in more detail...
[Chuanxiao Dong] Spectra + MTD only used in two ways.
1) Spectra only manage a few blocks as well as IAFW. In this way, means Spectra is used to update Kernel or something like bootloader. No file system allowed. In this way, BBT will not contain these blocks information.
2) Spectra manage the whole NAND as well as IAFW. That means no NAND file system allowed. Only EXT3 will be used. So in this way, MTD driver doesn't create BBT.
So I think, BBT will have no influence to Spectra.
Scratch register just used to let MTD driver know how many blocks IAFW managing. So what will be the effect of using scratch register?
Hi David
Do you have any comment about these 6 patches?
Is there any update?
Thanks
--Chuanxiao
Quoted 49 lines
-----Original Message-----
From: David Woodhouse [mailto:[email protected]]
Sent: Thursday, August 12, 2010 7:14 PM
To: Dong, Chuanxiao
Cc: [email protected]; Roberts, Jason E
Subject: Re: [PATCH v2 2/6]nand/denali: Add bad block management for MRSTQuoted 5 lines · Chuanxiao.Dong
drivers/mtd/nand/Kconfig +4
-0+choice + prompt "Compile for" + depends on MTD_NAND_DENALI + default MRST_NAND_CONTROLLERdrivers/mtd/nand/Kconfig config MTD_NAND_DENALI_SCRATCH_REG_ADDR · line 84
Quoted 10 lines
drivers/mtd/nand/Kconfig +10
-0+ +config MRST_NAND_CONTROLLER + bool "MRST NAND controller" + help + +config CE4100_NAND_CONTROLLER + bool "CE4100 NAND controller" + help + +endchoiceHm, I don't like this much -- we ought to be able to compile a generic kernel which will support *both* MRST and CE4100.
(Actually, we *can* -- you don't use these options anywhere (yet?) except as a gateway to letting us set the
BBT_BLOCKNUMvalue.It may also be worth switching CE4100 to use the same BBT scheme as you're using in MRST -- don't all the same arguments apply there?
I'm guessing that you didn't change CE4100 just because you want to retain on-medium compatibility? Let's ask Jason -- I suspect it would be OK to change...
I'm also somewhat dubious about the way we abandon the BBT when we're going to use Spectra -- and especially the use of the scratch register. Can't we put that information into PCI config space if we really must have it? I'll look over that in more detail...
--
David Woodhouse Open Source Technology
Centre
[email protected] Intel
Corporation