On 03/08/2013 02:27:48 PM, Tom Rini wrote:
On Thu, Dec 20, 2012 at 11:51:05AM -0000, Scott Wood wrote:
SPL doesn't write to the environment. These list entries prevent
the
functions from being garbage-collected, even though nothing will
look at
the list. This caused several SPL builds (e.g. P2020RDB-PC_NAND)
to
break due to size limitations and/or unresolved symbols.
A static inline function is used to provide a context in which we can consume the callback, and thus avoid unused function warnings.
Signed-off-by: Scott Wood scottwood@freescale.com Acked-by: Joe Hershberger joe.hershberger@gmail.com Acked-by: Kim Phillips kim.phillips@freescale.com
OK, this isn't quite right. On am335x_evm where SPL does use the "full" version of the environment, rather than the restricted version that say a3m071 we need these these callbacks to be generated. We usually build successfully since in these cases our #include of <u-boot.lst> picks up the one in include that the main SPL generates. But with enough cores we build SPL before we build this list for non-SPL, and the build fails. I shall submit a patch shortly for this.
What does am335x_evm do in the SPL that requires modifying the environment, and how does omitting the callbacks cause a build break?
The u-boot.lst issue sounds unrelated to this patch.
-Scott