[U-Boot] [PATCH 1/3] nand: allow demand initialization

[Scott Wood]

On Mon, 11 Oct 2010 17:02:00 -0400
Mike Frysinger <vapier at gentoo.org> wrote:

> On Monday, October 11, 2010 16:29:41 Scott Wood wrote:
> > On Sun, Oct 10, 2010 at 06:37:40AM -0400, Mike Frysinger wrote:
> > > --- a/common/cmd_nand.c
> > > +++ b/common/cmd_nand.c
> > > @@ -309,6 +309,8 @@
> > > 
> > >  	if (argc < 2)
> > >  		goto usage;
> > > 
> > > +	nand_init();
> > > +
> > 
> > Also do_nandboot().
> 
> does it need to be before the mtdparts init stuff, or can it be in 
> nand_load_image() ?

I think before -- the mtdparts init checks whether an mtd device
actually exists.  Though in that case, and also for things
like mtdparts.spread, nand_init() should go in mtdparts_init(), and also
nand_load_image() in case mtdparts aren't enabled.

> > > --- a/common/env_nand.c
> > > +++ b/common/env_nand.c
> > > @@ -359,6 +359,8 @@ void env_relocate_spec(void)
> > >  		return;
> > >  	}
> > > 
> > > +	nand_init();
> > > +
> > > 
> > >  	if (readenv(CONFIG_ENV_OFFSET, (u_char *) tmp_env1))
> > >  		puts("No Valid Environment Area found\n");
> > > 
> > > @@ -404,6 +406,8 @@ void env_relocate_spec(void)
> > >  	free(tmp_env1);
> > >  	free(tmp_env2);
> > > 
> > > +#else
> > > +	nand_init();
> > > 
> > >  #endif /* ! ENV_IS_EMBEDDED */
> > 
> > Do we really need to initialize NAND if the environment is embedded, or
> > could it be delayed to when the environment is saved?
> 
> the reason i picked env_relocate_spec() is because i'd have to push the init 
> into the read/write/save code paths.  and those may be executed multiple times 
> while running.  the expectation is that if you're putting the env into nand, 
> it's going to get read, so you might as well initialize it.

If it's embedded, then you've already read the env out of NAND by
whatever loaded the U-Boot image.  You'd only need to initialize NAND
if you're going to write it back, which is probably not the common
case.  In fact, I'm not sure when I'd use embedded-env with NAND at all
unless the environment's completely read-only and thus can share an
erase block with the u-boot image.

OTOH, I'm fine with leaving that as a future refinement for someone who
is using embedded-env with NAND and cares about the boot time it adds.

-Scott