[U-Boot] MAKEALL

[Simon Glass]

Hi,

On Tue, Oct 18, 2011 at 1:55 PM, Mike Frysinger <vapier at gentoo.org> wrote:
> On Tuesday 18 October 2011 16:47:12 Wolfgang Denk wrote:
>> Mike Frysinger wrote:
>> > > I see no clean way to implement this - ok, we could provide an
>> > > external tool / data base that maps boards or SoC names to
>> > > CROSS_COMPILE/ARCH/PATH settings, which each user has to configure for
>> > > his own set of tool chain settings.
>> >
>> > my proposal is only for the default behavior, and it only searches $PATH.
>> >  if the auto-lookup isn't what the user wants, they still can set
>> > CROSS_COMPILE= themselves.  so all existing usage is unchanged.
>>
>> While we are at it I would like to fix the known (to me) problems of
>> the current usage - that is for example that ARCH=arm includes for
>> example both little and big endian systems, which usually require
>> different tool chains to be used.
>
> at least from code sorcery (who have been defacto arm providers), their single
> toolchain includes support for both endians in one package.  the right
> output/libraries are selected with -m{big,little}-endian.
>
> in terms of compiling all the arm in a single run, i haven't had a problem
> with my one toolchain (which defaults to little endian).  but i've been using
> the private libgcc due to the many issues (including this) that comes with
> trying to use the one provided by the toolchain.
>
> i see that some targets do add -EB/-EL/-mbig-endian to their compiler flags in
> the respective config.mk files ...
>
>> > to add a further bit of flexibility, i might also propose that MAKEALL
>> > check the variable CROSS_COMPILE_<arch> and automatically set
>> > CROSS_COMPILE to that before running `make`.  this way people can do
>> > CROSS_COMPILE_arm=... CROSS_COMPILE_powerpc=... ./MAKEALL arm powerpc.
>>
>> That would still be to coarse for above issue.  Also, you might want
>> to use different ARM tool chains for ARMv5te systemd than for ARMv6
>> and yet other ones for ARMv7a, etc.
>
> the idea is easy to extend to CROSS_COMPILE_<soc|cpu> and perhaps even
> CROSS_COMPILE_<vendor|board>
>
> if you're not against the concept, i can post a patch and we can go from
> there.  but i can say that the limited MAKEALL behavior is the single reason
> for my limited build testing in the past.  i wrote the buildall script after
> trying to do tree-wide changes in the last few months because running
> ./MAKEALL simply does not scale.
> -mike
>

With Mike's script I was able to get something running.

Boards compiled: 247
Boards with warnings or errors: 175

ohci-hcd.c: In function 'submit_control_msg':
ohci-hcd.c:1300: warning: dereferencing pointer 'data_buf.80' does
break strict-aliasing rules
ohci-hcd.c:1300: note: initialized from here
ohci-hcd.c:1303: warning: dereferencing pointer 'data_buf.80' does
break strict-aliasing rules
ohci-hcd.c:1303: note: initialized from here
ohci-hcd.c:1306: warning: dereferencing pointer 'data_buf.80' does
break strict-aliasing rules
ohci-hcd.c:1306: note: initialized from here

These seem to be fixed by Marek's commit in usb:

commit 3563664f6f5799cad08127f6fe3a63e64bfe2715
Author: Marek Vasut <marek.vasut at gmail.com>
Date:   Fri Oct 7 02:00:13 2011 +0200

    USB: Fix complaints about strict aliasing in OHCI-HCD


arm-none-linux-gnueabi-ld: stubs.o: compiled for a big endian system
and target is little endian
arm-none-linux-gnueabi-ld: failed to merge target specific data of file stubs.o

I guess this is the endian error is the one you talk about here which
I suppose can be fixed with a -m flag. How should this be added in?
Should the ARM arch have a -mlittle-endian default?

Regards,
Simon

> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
>