Dear Mike Frysinger,
In message 200906190536.13184.vapier@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