Dear Mike Frysinger, In message <200906190536.13184.vap...@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: w...@denx.de "Who is the oldest inhabitant of this village?" "We haven't got one; we had one, but he died three weeks ago." _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
