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

[Wolfgang Denk]

Dear Guennadi Liakhovetski,

In message <Pine.LNX.4.64.0902022141190.8602 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.

Such an explanation belongs into the commit message.

And I'm not really sure why this file is affected, then.


> > > +#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.

But why does this matter here, and why do we have to change this file
for that?

> 1. embedded, in this case the real environment is initialised at 
> env_init() time, otherwise first default environment is used

First default environment? Do we have more than one default
environment?

> 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().

I don't see why we need a special case here.

We have two situations only:

1) environment is on the same NAND chip as the U-Boot image; this is
   the case we can handle cleanly. But it does not play any role of
   the environment is embedded, or directly adjacent (either before
   or after) to the U-Boot image, or if it is on a completely
   different location on this NAND chip.

2) environment is on a different NAND chip than the U-Boot image; in
   this case we cannot access the environment as early as needed,
   i.e. proper operation of U-Boot is not possible.

To me this means that 1) is the case we implement, without additional
#ifdef'fery, and 2) is a configuration error for which we should  add
appropriate #error handling.

> > >  #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 

What has BSS to do with the environment storage ???

BSS does not take any space in the U-Boot image, so why leave a
(eventually huge) gap unused?

> 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.

What has the location in RAM to do with the image structure on NAND?
We don't need to allocate any space for BSS on the NAND device, right?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
On a clear disk you can seek forever.