Hi Tom, On Tue, 12 Mar 2013 13:47:33 -0400, Tom Rini <tr...@ti.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 03/12/2013 01:19 PM, Albert ARIBAUD wrote: > > Hi Scott, > > > > On Tue, 12 Mar 2013 12:06:53 -0500, Scott Wood > > <scottw...@freescale.com> wrote: > > > >> On 03/12/2013 12:02:56 PM, Tom Rini wrote: > >>> On Tue, Mar 12, 2013 at 11:55:22AM -0500, Scott Wood wrote: > >>>> On 03/12/2013 10:30:40 AM, Tom Rini wrote: > >>>>> On Fri, Mar 08, 2013 at 06:35:04PM -0600, Scott Wood > >>>>> wrote: > >>>>>> 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. > >>>> > >>>> So it would break just as hard if we happened to turn off > >>>> all of the things that register callbacks. > >>>> > >>>>> 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. > >>>> > >>>> That's fine, but it's still a bad mechanism. > >>> > >>> Yes, the mechanism has a breaking condition on trying to > >>> reference an empty list (which is what SPL ends up with, in > >>> this case). Poking Albert and Marek in case they have any > >>> ideas, but this seems like a feature not a bug. > >> > >> How is it a feature? One of the main benefit of linker lists is > >> for things to just work when things are configured in/out > >> without needing ifdefs and such. Why should "everything > >> configured out" be a special case requiring an ifdef? > >> > >> If we want to save some code by ifdeffing the listwalking code > >> for SPL, that's a separate matter. > > > > Normally my reworked linker_list code should work fine with some > > code going through an empty list, precisely because list start and > > end symbols, like list entries, are generated by the compiler > > irrespective of one another and then whatever was generated is > > sorted by the linker. So an empty list ends up as two symbols at > > the same address (and indeed, env callbacks, in many boards, > > showed this pattern in the map file). > > OK, where's the latest/greatest of this re-work? I'll see if it also > solves the problem I have. In patchwork (assigned to me, and soon to be applied on u-boot-arm if this works for you): http://patchwork.ozlabs.org/patch/222904/ http://patchwork.ozlabs.org/patch/222905/ http://patchwork.ozlabs.org/patch/222906/ http://patchwork.ozlabs.org/patch/222908/ (http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/152754/focus=154634) Amicalement, -- Albert. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
