[U-Boot-Users] NAND search for bad blocks on startup
The newer NAND system seems to do a bad block search on startup. This takes several seconds when the NAND is big, like 256Mbytes. How about an #ifndef around this search, like CFG_NAND_NO_BAD_BLOCK_SEARCH so it can be turned off?
I can confirm the newer NAND system works with a 16 bit Micron NAND flash right out of the box once I've implemented the glue routines specific to my board. Good job!
Before I knew about the newer git version and was modifying 1.1.4 I had modified u-boot to support the micron NAND, but that work is irrelevant now. Maybe u-boot is ready for a major new release 1.1.5???
-Dave
In message 200605061602.k46G2T6b030445@xdr.com you wrote:
The newer NAND system seems to do a bad block search on startup. This takes several seconds when the NAND is big, like 256Mbytes. How about an #ifndef around this search, like CFG_NAND_NO_BAD_BLOCK_SEARCH so it can be turned off?
Do you think this is a good idea?
Before I knew about the newer git version and was modifying 1.1.4 I had modified u-boot to support the micron NAND, but that work is irrelevant now. Maybe u-boot is ready for a major new release 1.1.5???
I would like to see some more of the pending patches merged first. But this takes more time...
Best regards,
Wolfgang Denk
In message 200605061602.k46G2T6b030445@xdr.com you wrote:
The newer NAND system seems to do a bad block search on startup. This takes several seconds when the NAND is big, like 256Mbytes. How about an #ifndef around this search, like CFG_NAND_NO_BAD_BLOCK_SEARCH so it can be turned off?
Do you think this is a good idea?
Hmmm. I guess I don't really understand the reasons why the nand bad was done automatically on startup in the first place. I'm mainly just speaking of during development -- 5-10 seconds additional delay on each iteration of testing out u-boot adds up. So it would be nice to be able to *not* do the nand bad intentionally at startup during development.
Maybe the switch could exist, but after final code release always don't activate it so it does the "nand bad" on startup as it does now...
-Dave
In message 200605081846.k48IkhDL017032@xdr.com you wrote:
Hmmm. I guess I don't really understand the reasons why the nand bad was done automatically on startup in the first place. I'm mainly just speaking of during development -- 5-10 seconds additional delay on each iteration of testing out u-boot adds up. So it would be nice to be able to *not* do the nand bad intentionally at startup during development.
Don't enable NAND support in your board config file until the other areas in your code are debugged; then enable it when you want to get NAND working.
Best regards,
Wolfgang Denk
participants (2)
-
David Ashley -
Wolfgang Denk