[U-Boot-Users] NAND search for bad blocks on startup

[U-Boot-Users] NAND search for bad blocks on startup

[David Ashley]

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

[U-Boot-Users] NAND search for bad blocks on startup

[David Ashley]

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

[U-Boot-Users] NAND search for bad blocks on startup

[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?

> 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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Vor allem kein Gedanke! Nichts ist kompromittierender als ein  Gedan-
ke!            - Friedrich Wilhelm Nietzsche _Der Fall Wagner_ (1888)

[U-Boot-Users] NAND search for bad blocks on startup

[David Ashley]

>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

[U-Boot-Users] NAND search for bad blocks on startup

[Wolfgang Denk]

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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Fools ignore complexity. Pragmatists suffer it. Some  can  avoid  it.
Geniuses remove it.
     - Perlis's Programming Proverb #58, SIGPLAN Notices, Sept.  1982