[U-Boot] NAND bad block Query

[Gray Remlin <gryrmln@gmail.com>]

On 12/02/14 21:47, Scott Wood wrote:
> On Wed, 2014-02-12 at 21:04 +0000, Gray Remlin wrote:
>> Example taken from include/configs/sheevaplug.h
>>
>> #ifdef CONFIG_CMD_NAND
>> #define CONFIG_ENV_IS_IN_NAND           1
>> #define CONFIG_ENV_SECT_SIZE            0x20000 /* 128K */
>> #else
>> #define CONFIG_ENV_IS_NOWHERE           1       /* if env in SDRAM */
>> #endif
>> /*
>>  * max 4k env size is enough, but in case of nand
>>  * it has to be rounded to sector size
>>  */
>> #define CONFIG_ENV_SIZE                 0x20000 /* 128k */
>> #define CONFIG_ENV_ADDR                 0x60000
>> #define CONFIG_ENV_OFFSET               0x60000 /* env starts here */
>>
>> In the above configuration CONFIG_ENV_SIZE == CONFIG_ENV_SECT_SIZE, that
>> is, the erase block size.
>>
>> If there is just one bad block in the NAND mapped for the environment
>> does this mean that 'saveenv' will fail ?
>>
>> If so, shouldn't CONFIG_ENV_SIZE be set to less than
>> CONFIG_ENV_SECT_SIZE (but be a multiple of the write sector size) to
>> allow for bad block skipping ?
>>
>> I am tired and have a headache that wont go, please don't scold me too
>> harshly if I am being stupid....
> 
> Reducing CONFIG_ENV_SIZE would speed up I/O and CRC calculation, but it
> would not help with bad block skipping, because the granularity of
> skipping is the 128k block, not the 4k page.
Obvious, I looked at the 'writeenv' function numerous times and missed
that every time!

> 
> What you want is CONFIG_ENV_RANGE.
Re-reading the source (hopefully correctly) this morning, has no effect
on the bad block size, so does not help out in this instance as I only
have 128K (one erase block) to play with.

It seems to me that the current BBT method does not scale well, and
smacks of legacy implementation when flash was perhaps commonly a lot
smaller than the +GB used today. It's just crazy that the loss of a
couple of bits results in the loss of 128K.

Implementing a dynamic BBT that supports 'virtual partitioning' that
would permit finer granularity for smaller virtual partitions without
causing unnecessary overhead on larger virtual partitions will break
everything, so I won't hold my breath.
> 
> -Scott
> 
Thank you for your reply Scott