On 12/10/2012 07:41:43 AM, Phil Sutter wrote:
On Fri, Dec 07, 2012 at 11:38:11AM -0600, Scott Wood wrote:
On 12/07/2012 10:58:53 AM, Phil Sutter wrote:
Hmm. Does not look like CONFIG_ENV_OFFSET_OOB is used to select
the
block(s) within the erase page to save the environment. Looking at common/env_nand.c:318, the environment offset saved in the OOB
seems
to be in erase page unit.
I'm not sure what you mean by "block(s) within the erase page" -- blocks are the unit of erasing, and of bad block marking.
Not always, at least not with NAND flash. Erase pages are mostly bigger than write pages (or "blocks"). In my case, flash consists of 0x800 bytes write pages and 0x2000 bytes erase pages.
Erase blocks are larger than write pages, yes. I've never heard erase blocks called "pages" or write pages called "blocks" -- but my main point is that the unit of erasing and the unit of badness are the same.
The block to hold the environment is stored in the OOB of block
zero,
which is usually guaranteed to not be bad.
Erase or write block? Note that every write block has it's own OOB.
"block" means "erase block".
Every write page has its own OOB, but it is erase blocks that are marked bad. Typically the block can be marked bad in either the first or the second page of the erase block.
On the other hand, I could not find code that alters this setting based on bad blocks found or whatever. This seems to simply be an alternative to setting CONFIG_ENV_OFFSET at build-time.
It is set by the "nand env.oob" command. It is currently a manual process (or rather, automation is left to the user's board
preparation
process rather than being built into U-Boot), as U-Boot wouldn't
know
how to give back unused blocks to other purposes.
So that assumes that any block initially identified 'good' will ever turn 'bad' later on?
We don't currently have any mechanism for that to happen with the environment -- which could be another good reason to have real redundancy that doesn't get crippled from day one by having one copy land on a factory bad block. Of course, that requires someone to implement support for redundant environment combined with CONFIG_ENV_OFFSET_OOB.
Maybe a better option is to implement support for storing the environment in ubi, although usually if your environment is in NAND that means your U-Boot image is in NAND, so you have the same problem there. Maybe you could have an SPL that contains ubi support, that fits in the guaranteed-good first block.
Do you have any data on how often a block might go bad that wasn't factory-bad, to what extent reads versus writes matter, and whether there is anything special about block zero beyond not being factory-bad?
-Scott