On 12/06/2012 10:38:32 PM, Vipin Kumar wrote:
On 12/7/2012 12:57 AM, Scott Wood wrote:
On 12/06/2012 01:21:28 AM, Vipin Kumar wrote:
This patch forces to read the bad block marker from location 0 in large page nand devices and location 5 in small page devices.
Signed-off-by: Vipin Kumarvipin.kumar@st.com Reviewed-by: Shiraz Hashimshiraz.hashim@st.com
drivers/mtd/nand/fsmc_nand.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/fsmc_nand.c b/drivers/mtd/nand/fsmc_nand.c index 7a61d88..bce4298 100644 --- a/drivers/mtd/nand/fsmc_nand.c +++ b/drivers/mtd/nand/fsmc_nand.c @@ -433,7 +433,7 @@ int fsmc_nand_init(struct nand_chip *nand) writel(FSMC_THIZ_1 | FSMC_THOLD_4 | FSMC_TWAIT_6 | FSMC_TSET_0, &fsmc_regs_p->attrib);
- nand->options = 0;
- nand->options = NAND_SKIP_BBTSCAN; #if defined(CONFIG_SYS_FSMC_NAND_16BIT) nand->options |= NAND_BUSWIDTH_16; #endif
I don't think this will change the bad block marker behavior -- just whether you use a BBT. Why do you need this? Why not NAND_USE_FLASH_BBT instead?
It's because the BootROM which is fused in the device itself (ie non-modifiable) is going to read the bad block markers from the oob area.
Which means that anything written via u-boot is non-readable if it uses flash bbt
The factory bad block markers will still be there. The BBT is based on those markers, so you'll still avoid them when writing your boot image. So I don't follow why you're having trouble with your current settings. The main difference that NAND_SKIP_BBTSCAN makes is whether you scan for bad blocks up front, or whether you check each block on demand (and don't cache the results for next time).
Is your concern blocks that get marked bad later on -- not by the factory? In that case, you're still writing real bad block markers with "nand->options = 0". It's only when you specify NAND_USE_FLASH_BBT that you'll be updating an on-flash BBT instead of writing bad block markers.
Do you really expect to be marking blocks bad in your boot image? Normally that happens as part of a filesystem (or block management layer such as ubi) that does active bad-block management.
BTW, I've found an on-chip BBT to be nice during development. A bug in the NAND driver can cause the filesystem to mark every block as bad. If you wipe the BBT, you still keep the factory bad block information. If you have to scrub everything, you lose that.
-Scott