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

[Albert ARIBAUD]

Hi Tom,

On Tue, 12 Mar 2013 13:47:33 -0400, Tom Rini <trini at 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 
> > <scottwood at 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.