[U-Boot] [PATCH v4 05/13] Move memcpy(), memset() into new lib/membasic.c

[Simon Glass]

Hi Graeme,

On Tue, Mar 6, 2012 at 9:50 PM, Graeme Russ <graeme.russ at gmail.com> wrote:
> Hi Mike,
>
> On Wed, Mar 7, 2012 at 3:20 AM, Mike Frysinger <vapier at gentoo.org> wrote:
>> On Tuesday 06 March 2012 01:34:24 Simon Glass wrote:
>>> On Mon, Mar 5, 2012 at 9:05 PM, Mike Frysinger wrote:
>>> > On Monday 20 February 2012 20:32:47 Simon Glass wrote:
>>> >> These basic functions are needed by relocation. To avoid bringing in all
>>> >> string.c functions (and the resulting code bloat for architectures where
>>> >> -ffunction-sections is not used), move these into their own file.
>>> >
>>> > seems like fixing -f{data,function}-sections would be a more useful goal.
>>> >  i don't know why arm doesn't support this today ... it's fairly easy to
>>> > do.
>>>
>>> I did enable it for Tegra at one point with no ill effects except for
>>> breaking warmboot, which relied on function ordering. I notice the
>>> no-toplevel-reorder flag on x86 but not with ARM. But I assumed there
>>> must be some reason it is not used and thought this patch safer, since
>>> it is just a minor tweak on a series that has has some review.
>>
>> if we keep assuming that, then it'll never get fixed, and we'll sit on a steady
>> stream of "small safe patches".  plus, fixing this yields general improvements
>> in anti-bloat for everyone.
>>
>> function ordering sounds like something that should be imposed at the linker
>> level ... for Blackfin, all i had to care about was the entry point was at the
>> start of the .text, although warmbooting is fairly low level magic, and i
>> handle that in the SPL-like core.
>
> Can't the entry point be forced to be at the start of the u-boot image by
> putting that function in a dedicated section and specifying that section
> as the first in the linker script?
>
> This has always bothered me:
>
> #########################################################################
> # U-Boot objects....order is important (i.e. start must be first)
>
> OBJS  = $(CPUDIR)/start.o
> ifeq ($(CPU),x86)
> OBJS += $(CPUDIR)/start16.o
> OBJS += $(CPUDIR)/resetvec.o
> endif
> ifeq ($(CPU),ppc4xx)
> OBJS += $(CPUDIR)/resetvec.o
> endif
> ifeq ($(CPU),mpc85xx)
> OBJS += $(CPUDIR)/resetvec.o
> endif
>
> I've been meaning to get rid of this for x86 as I believe this can be
> adequately handled by putting the code in relevant sections and locating
> the sections at the correct location using the linker script.
>
> For x86 there are only two requirements:
>  - The first byte of resetvec.o sits 16 bytes from the end of flash
>  - The first byte of start.o is the first byte of the core u-boot image
>   (there is other cruft above it in the flash like an embedded kernel
>    image)
>

Yes I don't think the order is important now as we have a link script
as you say.

> Regards,
>
> Graeme