[U-Boot] [PATCH 5/10] common/env: Point default environment for GD

Scott Wood scottwood at freescale.com
Sat Apr 5 01:51:19 CEST 2014


On Wed, 2014-04-02 at 09:12 +0530, Prabhakar Kushwaha wrote:
> On 4/2/2014 3:34 AM, Scott Wood wrote:
> > On Mon, 2014-03-31 at 15:34 +0530, Prabhakar Kushwaha wrote:
> >> GD(Global Data) structure has pointer to environment variable array.
> >> but, it always point to default_environment assuming it is running from
> >> final location.
> >>
> >> So update GD pointer with env variable array during SPL boot.
> >>
> >> Signed-off-by: Prabhakar Kushwaha <prabhakar at freescale.com>
> >> ---
> >>   common/env_common.c |    3 +++
> >>   1 file changed, 3 insertions(+)
> >>
> >> diff --git a/common/env_common.c b/common/env_common.c
> >> index c0bfc2f..043150a 100644
> >> --- a/common/env_common.c
> >> +++ b/common/env_common.c
> >> @@ -162,6 +162,9 @@ int env_import(const char *buf, int check)
> >>   	if (himport_r(&env_htab, (char *)ep->data, ENV_SIZE, '\0', 0,
> >>   			0, NULL)) {
> >>   		gd->flags |= GD_FLG_ENV_READY;
> >> +#ifdef CONFIG_SPL_BUILD
> >> +		gd->env_addr = (unsigned long)ep->data;
> >> +#endif
> >>   		return 1;
> >>   	}
> >>   
> > Could you explain a bit more about how the environment is being loaded
> > during SPL, and how gd->env_addr gets set for non-SPL?
> >
> >
> 
> during SPL or NON- XIP boot (SD, SPI, NAND) in order to access env 
> variables following 2 functions are called sequentially.
> 1. env_init() : Initialize gd->env_addr with default_environment array
> 2. env_relocate(). It copied data from flash to heap memory area and 
> call env_import().
>              here,  This env pointer *buf is used for importing.  but 
> gd->env_addr never updated with new address of env variables.  It always 
> remain pointed to default_environment array set in env_init().
> It looks to be a issue for non-XIP boot.  As I was not confident about 
> it. So limited to only SPL framework only.
> 
> for non-SPL i.e. XIP boot (NOR)
>   env_init (): gd->env_addr always point to NOR address containing 
> env_variables.  Because of XIP No need of copy from flash to buffer.  
> Hence no problem.

That doesn't really answer my question of how it gets initialized for
NOR flash.  What line in what file does the initialization?  It looks
like the answer is env_init() -- so it doesn't "always" hold the
address.  Why can't env_init() do this on NAND, SPI, etc, provided you
actually have the environment available before relocation[1]?

I'm also not sure what it has to do with SPL as opposed to non-XIP.
Doesn't this also apply for non-SPL PBL boot, etc?  Why wouldn't you do
this in env_relocate_spec()?

BTW, I notice a few Freescale boards initialize this in their spl.c
file.

Also, you don't mention what the actual bug is you see.  What uses
gd->env_addr after relocation, other than api/?  I'm not saying that
api/ isn't important, but I'm wondering if you saw an effect elsewhere.

-Scott

[1] I realize that in many cases we don't, but that's something we need
to fix, since it's important to how DDR gets set up among other things.




More information about the U-Boot mailing list