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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
