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

[Mike Frysinger]

On Friday 10 July 2009 18:07:52 Wolfgang Denk wrote:
> Mike Frysinger wrote:
> > 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.

this isnt a hack.  the code is thought out and designed to do one thing 
properly.  if you want to see hacks, look at the nested mess that exists today 
in the code that is compiled on the host to produce the embedded environment.  
as for "single user", yes i might be the only arch so far *to complain aloud*, 
but that doesnt directly imply i'm the only one who would use it.

the current process design for creating the embedded env is fundamentally 
flawed.  i'm not saying it doesnt work as is on most development systems we 
care about today, but working doesnt translate directly to "designed 
correctly".

> 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 guess i could create a header that enumerates all the possible toolchain 
defines and translates them to CONFIG_xxx such that they get transferred 
between build environments, but that sounds pretty fragile and would require 
constant updates as new processors are supported.  i dont think make env vars 
would work because these are dynamic CPP defines.

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

i'm not interested in fighting a battle that, by design, can never be won

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

yes, a saveenv will reset the crc, but again, this is a workaround for a 
design flaw.  i'm interested in fixing these flaws, not telling people to "go 
run saveenv and pretend there isnt a problem".  after all, it makes it pretty 
hard to take a u-boot binary image, send it to a factory for programming, and 
then additionally have the board run the native code merely to rebuild the 
environment crc that should have been correct in the first place.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090710/31347006/attachment.pgp