nand: current mainline show "new" startup output

U-Boot Heiko Schocher 2 participants 4 messages Feb 13, 2012 – Feb 14, 2012

Subsystems (2)

Memory technology devices (MTD) NAND flash

lore

Share & tools

lore

Heiko Schocher

author

2012-02-13 08:18 UTC #0 lore raw

Hello Christian, Scott,

current mainline code of U-Boot:

commit 9a3aae22edf1eda6326cc51c28631ca5c23b7706

Author: Christian Riesch <[email protected]>
Date:   Thu Feb 2 00:44:42 2012 +0000

arm, davinci: Add support for the Calimain board from OMICRON electronics

This patch adds support for the Calimain board from
OMICRON electronics GmbH. The board features a Texas Instruments AM1808 SoC, 128 MB DDR2 memory, and 64 MB NOR flash memory connected to CS2 and CS3.

Signed-off-by Christian Riesch <[email protected]>

shows now on startup the following printfs on the enbw_cmc board:

U-Boot 2011.12-00331-ga400f85 (Feb 13 2012 - 08:49:17)

I2C: ready
[...]
NAND: Bad block table found at page 65472, version 0x01 Bad block table found at page 65408, version 0x01
nand_read_bbt: Bad block at 0x000002980000
nand_read_bbt: Bad block at 0x000003240000
128 MiB
MMC: davinci: 0

Found with "git bisect" the reason:

[hs at pollux u-boot]$ git bisect good 2a8e0fc8b3dc31a3c571e439fbf04b882c8986be is the first bad commit commit 2a8e0fc8b3dc31a3c571e439fbf04b882c8986be

Author: Christian Hitz <[email protected]>
Date:   Wed Oct 12 09:32:02 2011 +0200

nand: Merge changes from Linux nand driver

[backport from linux commit 02f8c6aee8df3cdc935e9bdd4f2d020306035dbe]

This patch synchronizes the nand driver with the Linux 3.0 state.

Signed-off-by Christian Hitz <[email protected]>

Cc Scott Wood <[email protected]>

[scottwood at freescale.com: minor fixes]

Signed-off-by Scott Wood <[email protected]>

:040000 040000 5ab34f43b64379528b9ef2652c8481fdab1a927a b453a49035e179dfb5f31c3164a1b7d3d62d66d6 M drivers
:040000 040000 b59a7f3136da038b4b49c48cd0958e140a09ed66 a8fd298715a562fda0a350e6f732c1072ca7d410 M include
[hs at pollux u-boot]$

Looking in this patch, it seems to me, this is the "reason":

drivers/mtd/nand/nand_base.c +0 -0

index 758b53f..ed2640c 100644

[...]
@@ -2992,9 +3145,10 @@ int nand_scan_tail(struct mtd_info *mtd)

        /* Check, if we should skip the bad block table scan */
        if (chip->options & NAND_SKIP_BBTSCAN)

- chip->options |= NAND_BBT_SCANNED;
+ return 0;

-       return 0;
+       /* Build bad block table */
+       return chip->scan_bbt(mtd);

}

/**

... This printfs in the startoutput are suboptimal ... maybe we apply the following patch:

drivers/mtd/nand/nand_bbt.c +7 -6

index 2b730e0..bf12df8 100644
@@ -259,10 +259,10 @@ static int read_bbt(struct mtd_info *mtd, uint8_t *buf, int page, int num,
                                        mtd->ecc_stats.bbtblocks++;
                                        continue;
                                }
-                               /* Leave it for now, if its matured we can move this
-                                * message to MTD_DEBUG_LEVEL0 */
-                               printk(KERN_DEBUG "nand_read_bbt: Bad block at 0x%012llx\n",
-                                      (loff_t)((offs << 2) + (act >> 1)) << this->bbt_erase_shift);
+                               MTDDEBUG(MTD_DEBUG_LEVEL0, "nand_read_bbt: " \
+                                       "Bad block at 0x%012llx\n",
+                                       (loff_t)((offs << 2) + (act >> 1))
+                                       << this->bbt_erase_shift);
                                /* Factory marked bad or worn out ? */
                                if (tmp == 0)
                                        this->bbt[offs + (act >> 3)] |= 0x3 << (act & 0x06);

@@ -651,8 +651,9 @@ static int search_bbt(struct mtd_info *mtd, uint8_t *buf, struct nand_bbt_descr
                if (td->pages[i] == -1)
                        printk(KERN_WARNING "Bad block table not found for chip %d\n", i);
                else
-                       printk(KERN_DEBUG "Bad block table found at page %d, version 0x%02X\n", td->pages[i],
-                              td->version[i]);
+                       MTDDEBUG(MTD_DEBUG_LEVEL0, "Bad block table found " \
+                               "at page %d, version 0x%02X\n", td->pages[i],
+                               td->version[i]);
        }
        return 0;
 }

If this patch is OK, I can send it ...

bye,
Heiko

Signature · 2 lines

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Scott Wood

2012-02-13 17:06 UTC #1 lore raw

Quoted 76 lines · Heiko Schocher

Hello Christian, Scott,
current mainline code of U-Boot:
commit 9a3aae22edf1eda6326cc51c28631ca5c23b7706
Author: Christian Riesch <[email protected]>
Date:   Thu Feb 2 00:44:42 2012 +0000
arm, davinci: Add support for the Calimain board from OMICRON electronics
This patch adds support for the Calimain board from
OMICRON electronics GmbH. The board features a Texas Instruments AM1808 SoC, 128 MB DDR2 memory, and 64 MB NOR flash memory connected to CS2 and CS3.
Signed-off-by Christian Riesch <[email protected]>
shows now on startup the following printfs on the enbw_cmc board:
U-Boot 2011.12-00331-ga400f85 (Feb 13 2012 - 08:49:17)
I2C: ready
[...]
NAND: Bad block table found at page 65472, version 0x01 Bad block table found at page 65408, version 0x01
nand_read_bbt: Bad block at 0x000002980000
nand_read_bbt: Bad block at 0x000003240000
128 MiB
MMC: davinci: 0
Found with "git bisect" the reason:
[hs at pollux u-boot]$ git bisect good 2a8e0fc8b3dc31a3c571e439fbf04b882c8986be is the first bad commit commit 2a8e0fc8b3dc31a3c571e439fbf04b882c8986be
Author: Christian Hitz <[email protected]>
Date:   Wed Oct 12 09:32:02 2011 +0200
nand: Merge changes from Linux nand driver
[backport from linux commit 02f8c6aee8df3cdc935e9bdd4f2d020306035dbe]
This patch synchronizes the nand driver with the Linux 3.0 state.
Signed-off-by Christian Hitz <[email protected]>
Cc Scott Wood <[email protected]>
[scottwood at freescale.com: minor fixes]
Signed-off-by Scott Wood <[email protected]>
:040000 040000 5ab34f43b64379528b9ef2652c8481fdab1a927a b453a49035e179dfb5f31c3164a1b7d3d62d66d6 M drivers
:040000 040000 b59a7f3136da038b4b49c48cd0958e140a09ed66 a8fd298715a562fda0a350e6f732c1072ca7d410 M include
[hs at pollux u-boot]$
Looking in this patch, it seems to me, this is the "reason":
drivers/mtd/nand/nand_base.c +3 -2
index 758b53f..ed2640c 100644
[...]
@@ -2992,9 +3145,10 @@ int nand_scan_tail(struct mtd_info *mtd)
 
        /* Check, if we should skip the bad block table scan */
        if (chip->options & NAND_SKIP_BBTSCAN)
-               chip->options |= NAND_BBT_SCANNED;
+               return 0;
 
-       return 0;
+       /* Build bad block table */
+       return chip->scan_bbt(mtd);
 }
 
 /**

Quoted 2 lines

... This printfs in the startoutput are suboptimal ... maybe we apply the following patch:

The problem isn't (just) the prints, which have always been there, but when we do the scanning. I suspect this patch accidentally reversed a U-Boot local change to defer bad block scanning to first use.

-Scott

Heiko Schocher

author

2012-02-14 06:38 UTC #2 lore raw

Hello Scott,

Quoted 75 lines · Scott Wood

Quoted 74 lines · Heiko Schocher
Hello Christian, Scott,
current mainline code of U-Boot:
commit 9a3aae22edf1eda6326cc51c28631ca5c23b7706
Author: Christian Riesch <[email protected]>
Date:   Thu Feb 2 00:44:42 2012 +0000
arm, davinci: Add support for the Calimain board from OMICRON electronics
This patch adds support for the Calimain board from
OMICRON electronics GmbH. The board features a Texas Instruments AM1808 SoC, 128 MB DDR2 memory, and 64 MB NOR flash memory connected to CS2 and CS3.
Signed-off-by Christian Riesch <[email protected]>
shows now on startup the following printfs on the enbw_cmc board:
U-Boot 2011.12-00331-ga400f85 (Feb 13 2012 - 08:49:17)
I2C: ready
[...]
NAND: Bad block table found at page 65472, version 0x01 Bad block table found at page 65408, version 0x01
nand_read_bbt: Bad block at 0x000002980000
nand_read_bbt: Bad block at 0x000003240000
128 MiB
MMC: davinci: 0
Found with "git bisect" the reason:
[hs at pollux u-boot]$ git bisect good 2a8e0fc8b3dc31a3c571e439fbf04b882c8986be is the first bad commit commit 2a8e0fc8b3dc31a3c571e439fbf04b882c8986be
Author: Christian Hitz <[email protected]>
Date:   Wed Oct 12 09:32:02 2011 +0200
nand: Merge changes from Linux nand driver
[backport from linux commit 02f8c6aee8df3cdc935e9bdd4f2d020306035dbe]
This patch synchronizes the nand driver with the Linux 3.0 state.
Signed-off-by Christian Hitz <[email protected]>
Cc Scott Wood <[email protected]>
[scottwood at freescale.com: minor fixes]
Signed-off-by Scott Wood <[email protected]>
:040000 040000 5ab34f43b64379528b9ef2652c8481fdab1a927a b453a49035e179dfb5f31c3164a1b7d3d62d66d6 M drivers
:040000 040000 b59a7f3136da038b4b49c48cd0958e140a09ed66 a8fd298715a562fda0a350e6f732c1072ca7d410 M include
[hs at pollux u-boot]$
Looking in this patch, it seems to me, this is the "reason":
drivers/mtd/nand/nand_base.c +3 -2
index 758b53f..ed2640c 100644
[...]
@@ -2992,9 +3145,10 @@ int nand_scan_tail(struct mtd_info *mtd)
 
        /* Check, if we should skip the bad block table scan */
        if (chip->options & NAND_SKIP_BBTSCAN)
-               chip->options |= NAND_BBT_SCANNED;
+               return 0;
 
-       return 0;
+       /* Build bad block table */
+       return chip->scan_bbt(mtd);
 }
 

Quoted 8 lines

Quoted 4 lines
drivers/mtd/nand/nand_base.c +0 -0
 /**
... This printfs in the startoutput are suboptimal ... maybe we apply the following patch:
The problem isn't (just) the prints, which have always been there, but when we do the scanning. I suspect this patch accidentally reversed a U-Boot local change to defer bad block scanning to first use.

Yes, seems so. So there are two points to decide:

- Do we need this prints? I vote for moving them to debug output

- Do we move scanning back to first use? I vote for moving to "first use"

bye,
Heiko

Signature · 2 lines

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Scott Wood

2012-02-14 17:12 UTC #3 lore raw

Quoted 10 lines · Heiko Schocher

Hello Scott,
Quoted 3 lines · Scott Wood
The problem isn't (just) the prints, which have always been there, but when we do the scanning. I suspect this patch accidentally reversed a U-Boot local change to defer bad block scanning to first use.
Yes, seems so. So there are two points to decide:
- Do we need this prints? I vote for moving them to debug output

That's fine, but not related to this patch.

Quoted 1 line

- Do we move scanning back to first use? I vote for moving to "first use"

Yes, this is a regression introduced by this patch and should be fixed.

-Scott