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 <scottw...@freescale.com>
> Acked-by: Joe Hershberger <joe.hershber...@gmail.com>
> Acked-by: Kim Phillips <kim.phill...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
