[U-Boot] [PATCH] envcrc: extract default environment from target ELF files

[Wolfgang Denk]

Dear Mike Frysinger,

In message <200906190536.13184.vapier at gentoo.org> you wrote:
>
> > We've been using this code for many years now, but I
> > cannot remember any problems with it.
...
> if the default environment utilizes defines that come from the toolchain in 
> any level of indirection, the environment that is built into the target u-boot 
> will not match the environment that is compiled on the host for crc 
> generation.

Hm... Defines that influence the envrionment should never come from
the tool chain, but only from U-Boot source files.

> so the CPP dependency chain looks something like:
> - Blackfin toolchain sets up variant defines
> - ADI board headers set up capabilities based on variant defines
> - common ADI board header enables some commands based on variant defines
> - common ADI board header sets up default environment based on capabilities 
> and commands available
> 
> since the host toolchain does not set up the same CPP dependencies as the 
> Blackfin toolchain, this tree falls apart and the resulting environment string 
> that envcrc operates on differs, so the CRCs differ.

I see what your problem is.

> i can understand your position of "setting up board configs this way is 
> wrong", but i've structured it this way because it greatly reduces my 
> maintenance burden while increasing regression capabilities.  for example, i 

I see. I understand what you have in mind, but I don't think that such
a specific hack for a single user justifies such a change.

Instead of setting such defines in  the  tool  chain  (whatever  this
means  exactly)  it  would  be  probably  more  appropriate  to  pass
arguments or environment variables to make, I think -  and  not  more
difficult, too.

> i have also seen a case or two where the host toolchain inadvertently expanded 
> things that ended up in the environment because they were not declared as 
> strings.  for example, many defines are not:
> #define CONFIG_FOO "foo"
> but rather they are:
> #define CONFIG_FOO foo
> just grep common/env_*.c for MKSTR() to see just how many things are affected 
> in this way.  having to worry about values here which may be arbitrarily 
> expanded across host toolchains is a bad design practice imo.

Patches for such problems are welcome.

> if the environment is only ever compiled by one toolchain, the target one, 
> then it significantly reduces the chance for unexpected and unwelcomed 
> surprises.  after all, the only way to notice something has gone wrong is to 
> build the source with a specific host toolchain, burn the image, reset, and 
> see the dreaded "CRC mismatch, using default environment" error from u-boot.  

Ummm.. but this is not a real problem, because a simple "saveenv" will
fix it, right? All boards that don't embed the environment work like
this.

> hope this clears things up

I understand your arguments, but I don't come to the same conclusions.
Sorry.

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
"Who is the oldest inhabitant of this village?"
"We haven't got one; we had one, but he died three weeks ago."