[U-Boot] [ARM] Environment variables not available during console initialisation?

[Guennadi Liakhovetski]

On Mon, 2 Feb 2009, Wolfgang Denk wrote:

> Dear Guennadi Liakhovetski,
> 
> In message <Pine.LNX.4.64.0902021725100.4218 at axis700.grange> you wrote:
> > 
> > -#ifdef ENV_IS_EMBEDDED
> > +#if defined(ENV_IS_EMBEDDED)
> >  extern uchar environment[];
> >  env_t *env_ptr = (env_t *)(&environment[0]);
> > +#elif defined(CFG_ENV_IS_APPENDED)
> 
> What makes you think an "appended" environment is so special that it
> is worth a separate #ifdef here? What about a prepended environment?
> Or one two sectors apart?

Ok, agree, the name is badly chosen. The real restriction of this specific 
implementation is that the environment must be on the same NAND chip as 
the one we are booting from. Any location on that chip can be handled, I 
think.

> > -#if defined(ENV_IS_EMBEDDED)
> > -	size_t total;
> > +#if defined(ENV_IS_EMBEDDED) || defined(CFG_ENV_IS_APPENDED)
> >  	int crc1_ok = 0, crc2_ok = 0;
> > -	env_t *tmp_env1, *tmp_env2;
> > +	env_t *tmp_env1;
> >  
> 
> Note that there is a fundamental difference between embedded and
> non-embedded (in whatever which way) environments, but I can see no
> significant difference between an "appended" or a "prepended" or
> otherwise separate environment.

The reason they share the same #if case here is that both get initialised 
early, not as was only possible until now on NAND - after all initcalls.

> Maybe you try to explain what you have in mind with this
> special-casing here?
> 
> And I don't understand the rest of your implementation either. Please
> explain...

Ok, currently environment in NAND has two cases:

1. embedded, in this case the real environment is initialised at 
env_init() time, otherwise first default environment is used
2. other, env_init() initialises the default environment, the real (stored 
in NAND) environment is first activated at env_relocate() time.

With this patch we add one more case

3. environment, located on the same NAND chip as the boot NAND. in this 
case we can also let the nand_spl code load it for is in RAM and then we 
can use it in env_init().

> > diff --git a/include/configs/smdk6400.h b/include/configs/smdk6400.h
> > index 1ee4191..3acf7cd 100644
> > --- a/include/configs/smdk6400.h
> > +++ b/include/configs/smdk6400.h
> > @@ -223,6 +224,8 @@
> >  #define CFG_UBOOT_BASE		(CFG_MAPPED_RAM_BASE + 0x07e00000)
> >  
> >  #define CFG_ENV_OFFSET		0x0040000
> > +/* Leave enough space for bss, currently __bss_end == 0x57e74800 */
> > +#define CFG_NAND_ENV_DST	(CFG_UBOOT_BASE + 0x80000)
> 
> ???? What's that? What has BSS to do with the environment storage ???

This is smdk6400 header, on this board I chose to place the environment 
read in by nand_spl above bss, because, AFAIU, the area above __bss_end is 
unused by u-boot. But I didn't find an easy way to pass a calculated value 
from u-boot proper to nand_spl or vice versa. As you know, these two 
objects use saparate linker scripts and are linked absolutely 
independently, and just cat'ed together in the end. So, I had to use a 
macro to specify the location of the environment copy in RAM instead of 
calculating it precisely.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de