[U-Boot] [U-Boot, v2] env: don't generate callback list entries for SPL

[Tom Rini]

On Fri, Mar 08, 2013 at 06:35:04PM -0600, Scott Wood wrote:
> On 03/08/2013 02:59:47 PM, Tom Rini wrote:
> >-----BEGIN PGP SIGNED MESSAGE-----
> >Hash: SHA1
> >
> >On 03/08/2013 03:34 PM, Scott Wood wrote:
> >> 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 at freescale.com> Acked-by:
> >>>> Joe Hershberger <joe.hershberger at gmail.com> Acked-by: Kim
> >>>> Phillips <kim.phillips at 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?
> >
> >It requires the full network stack which in turn means we can't just
> >discard most of the environment related functions.  And some parts of
> >the callback infrastructure aren't opt-in'able.
> 
> I still don't follow -- the only effect of this patch should be that
> the callbacks don't get called, which is only relevant when writing
> to the environment.  We're not ripping out anything, just declining
> to reference the callback functions.  If something else still
> references them, they'll be retained.

It's not that they don't get called, it's that they don't get put into
the special section.

> >> The u-boot.lst issue sounds unrelated to this patch.
> >
> >The problem is undefined references at link time to
> >_u_boot_env_clbk__start/__end from common/env_callbacks.c where it
> >tries to look at our empty list of callbacks (we are able to discard
> >all of those).
> 
> Why would eliminating all individual callbacks cause start/end to go
> away?  If that's the way the list mechanism works, the mechanism
> needs fixing.

Yes, that's how the mechanism works.  Rather than having to declare that
you expect to have a linker list of name $foo, we dynamically determine
what linker lists we have and setup the linker section entry.  I'm not
sure it's broken exactly, I think maybe we just need to say no env
callback support in SPL since it's not really user editable.

I've got an idea that I'm going to go test now and then if it works,
post patches for.

> >And part of the issue is that we're always using the
> >wrong u-boot.lst file for SPL.  It's just that in most cases the wrong
> >one (the main U-Boot one) is also fine enough for SPL since it's just
> >a few extra symbols and we aren't so constrained for space that we've
> >noticed.
> 
> That sounds familiar: a6d0f62a0ccac7669b1efe320e28c276b1b8084b
> :-)

Not quite the same problem.  This one shows up with separate obj
directories too.  It really is that with a small enough job number we
generate include/u-boot.lst before trying to link u-boot-spl, and that is
used, and gives us the start/end symbols (at the same address as we've
discarded the callbacks themselves).

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130312/ae466f08/attachment.pgp>