[U-Boot] MAKEALL

[U-Boot] MAKEALL

[JYOTI DUBEY]

What is the use of executing MAKEALL file available in u-boot folder?

[U-Boot] MAKEALL

[Anatolij Gustschin]

On Wed, 29 Jan 2014 12:43:30 +0530
JYOTI DUBEY <jyoti0801@gmail.com> wrote:

> What is the use of executing MAKEALL file available in u-boot folder?

./MAKEALL -h 

HTH,

Anatolij

[U-Boot] MAKEALL

[Anatolij Gustschin]

first, please keep mailing list in CC.

On Wed, 29 Jan 2014 12:56:55 +0530
JYOTI DUBEY <jyoti0801@gmail.com> wrote:

> How can I compile u-boot for arm processor and nitrogen6x board?

install armv7a cross toolchain and setup the environment for cross
compiling, then run

 ./MAKEALL nitrogen6q

There are another targets for nitrogen6 board variants with more
DRAM and/or dual or solo CPU:

nitrogen6q2g, nitrogen6dl, nitrogen6dl2g, nitrogen6s, nitrogen6s1g.

So, use what is suitable for your board variant.

HTH,

Anatolij

[U-Boot] MAKEALL

[York Sun]

Wolfgang,

I have some troubles to run MAKEALL with BUILD_NBUILDS. If I set BUILD_NBUILDS
to 2 or greater, there is a good chance the total number of targets is not an
integral multiple of BUILD_NBUILDS. It has two undesired results.

1. The status report has wrong number of passed builds.
2. This script throws out SIGTERM.

The second one is troubling me. I am using Jenkins to monitor and build
automatically. I can trap the SIGTERM on some hosts but not all of them.

Can you shed some light on this?

York

[U-Boot] MAKEALL

[Wolfgang Denk]

Dear York,

In message <52C7424A.4090205@freescale.com> you wrote:
> 
> I have some troubles to run MAKEALL with BUILD_NBUILDS. If I set BUILD_NBUILDS
> to 2 or greater, there is a good chance the total number of targets is not an
> integral multiple of BUILD_NBUILDS. It has two undesired results.
> 
> 1. The status report has wrong number of passed builds.
> 2. This script throws out SIGTERM.
> 
> The second one is troubling me. I am using Jenkins to monitor and build
> automatically. I can trap the SIGTERM on some hosts but not all of them.
> 
> Can you shed some light on this?

I'm sorry, but I am not familiar with this BUILD_NBUILDS code at all.
It was added by Andy Fleming, so maybe he can help.

Andy?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de

[U-Boot] MAKEALL

[Simon Glass]

Hi York,


On 4 January 2014 02:21, Wolfgang Denk <wd@denx.de> wrote:

> Dear York,
>
> In message <52C7424A.4090205@freescale.com> you wrote:
> >
> > I have some troubles to run MAKEALL with BUILD_NBUILDS. If I set
> BUILD_NBUILDS
> > to 2 or greater, there is a good chance the total number of targets is
> not an
> > integral multiple of BUILD_NBUILDS. It has two undesired results.
> >
> > 1. The status report has wrong number of passed builds.
> > 2. This script throws out SIGTERM.
> >
> > The second one is troubling me. I am using Jenkins to monitor and build
> > automatically. I can trap the SIGTERM on some hosts but not all of them.
> >
> > Can you shed some light on this?
>
> I'm sorry, but I am not familiar with this BUILD_NBUILDS code at all.
> It was added by Andy Fleming, so maybe he can help.
>
> Andy?
>

It might also be worth looking at tools/buildman, which automatically
allocates one build thread per CPU.

Regards,
Simon

[U-Boot] MAKEALL

[Albert ARIBAUD]

Hi Simon,

On Wed, 8 Jan 2014 09:54:47 -0700, Simon Glass <sjg@chromium.org> wrote:

> Hi York,
> 
> 
> On 4 January 2014 02:21, Wolfgang Denk <wd@denx.de> wrote:
> 
> > Dear York,
> >
> > In message <52C7424A.4090205@freescale.com> you wrote:
> > >
> > > I have some troubles to run MAKEALL with BUILD_NBUILDS. If I set
> > BUILD_NBUILDS
> > > to 2 or greater, there is a good chance the total number of targets is
> > not an
> > > integral multiple of BUILD_NBUILDS. It has two undesired results.
> > >
> > > 1. The status report has wrong number of passed builds.
> > > 2. This script throws out SIGTERM.
> > >
> > > The second one is troubling me. I am using Jenkins to monitor and build
> > > automatically. I can trap the SIGTERM on some hosts but not all of them.
> > >
> > > Can you shed some light on this?
> >
> > I'm sorry, but I am not familiar with this BUILD_NBUILDS code at all.
> > It was added by Andy Fleming, so maybe he can help.
> >
> > Andy?
> >
> 
> It might also be worth looking at tools/buildman, which automatically
> allocates one build thread per CPU.

Jumping in late, but my question is incidental and not urgent anyway.

Would using buildman make the multiple build / multiple CPU code in
MAKEALL useless? I'm wondering whether we could apply the Unix
philosophy here (1), let buildman alone deal with handling parallel
builds, and remove code from MAKEALL.

(1) not the "unix is user-friendly, it's just picky about who its
friends are" one; the "do one thing well" one.

> Regards,
> Simon

Amicalement,
-- 
Albert.

[U-Boot] MAKEALL

[Masahiro Yamada]

Hi Albert,


> > It might also be worth looking at tools/buildman, which automatically
> > allocates one build thread per CPU.
> 
> Jumping in late, but my question is incidental and not urgent anyway.
> 
> Would using buildman make the multiple build / multiple CPU code in
> MAKEALL useless? I'm wondering whether we could apply the Unix
> philosophy here (1), let buildman alone deal with handling parallel
> builds, and remove code from MAKEALL.

I think parallel build feature is missing from buildman.
So, buildman cannot check if -j option is working correctly.

Note:
Please do not be confused by the difference of
what "parallel" means.

[1] MAKEALL runs single "make" thread by default. 
(You can change this with BUILD_NBUILDS variable)
One "make" thread runs multiple jobs by giving -j option.
(You can change this with BUILD_NCPUS variable)

[2] buildman runs multiple "make" threads.
Each make thread runs one job (that is, always  -j 1 ).



Besides parallel build , I notice some differences between MAKEALL and
buildman.

 - MAKEALL runs "make mrproper" everty time before "make",
    but buildman doesn't.
    This means objects are remaining, that were generated
    by the previous commit.
    So, even if some build rules in makefiles get broken at an
    intermediate commit,  buildman possibly cannot detect the error.

 - MAKEALL can select in-tree-build or out-of-tree build
   by BUILD_DIR option, but buildman always does out-of-tree build.

(Simon, please correct me if I am wrong.)

If you touch only C sources, buildman is enough (and faster).

But if you change make targets, it is highly recommended
to check with MAKEALL.
At least, I need both. (for Kbuild and Kconfig work)

I guess we cannot replace MAKEALL with buildman for now.


Best Regards
Masahiro Yamada

[U-Boot] MAKEALL

[Simon Glass]

Hi,

On 12 February 2014 03:42, Masahiro Yamada <yamada.m@jp.panasonic.com> wrote:
> Hi Albert,
>
>
>> > It might also be worth looking at tools/buildman, which automatically
>> > allocates one build thread per CPU.
>>
>> Jumping in late, but my question is incidental and not urgent anyway.
>>
>> Would using buildman make the multiple build / multiple CPU code in
>> MAKEALL useless? I'm wondering whether we could apply the Unix
>> philosophy here (1), let buildman alone deal with handling parallel
>> builds, and remove code from MAKEALL.
>

This is a good summary thank you, but I have a few comments as well.

> I think parallel build feature is missing from buildman.
> So, buildman cannot check if -j option is working correctly.

It is not used by default, but there is a -j option. If you use -j,
first make sure you reduce the number of threads to compensate. So for
example you can use:

   buildman -j 8 -T 1

to use -j8 with only a single thread on a 8-core machine. I typically
find that building with -j1 and increasing the thread count is much
faster. Another tip if you are not using your machine for anything
else is to use -T with a number 20-30% larger than the number of CPUs
you have.

>
> Note:
> Please do not be confused by the difference of
> what "parallel" means.
>
> [1] MAKEALL runs single "make" thread by default.
> (You can change this with BUILD_NBUILDS variable)
> One "make" thread runs multiple jobs by giving -j option.
> (You can change this with BUILD_NCPUS variable)
>
> [2] buildman runs multiple "make" threads.
> Each make thread runs one job (that is, always  -j 1 ).
>

Indeed, this is the default behaviour, but it can be changed with options.

>
>
> Besides parallel build , I notice some differences between MAKEALL and
> buildman.
>
>  - MAKEALL runs "make mrproper" everty time before "make",
>     but buildman doesn't.
>     This means objects are remaining, that were generated
>     by the previous commit.
>     So, even if some build rules in makefiles get broken at an
>     intermediate commit,  buildman possibly cannot detect the error.

That is correct. To get the MAKEALL behaviour you need to give the -f option.

>
>  - MAKEALL can select in-tree-build or out-of-tree build
>    by BUILD_DIR option, but buildman always does out-of-tree build.

That's right, in fact buildman does not support in-tree build at all
unfortunately. However, given that every thread has its own git tree,
it would actually be fairly easy to add this feature.

>
> (Simon, please correct me if I am wrong.)
>
> If you touch only C sources, buildman is enough (and faster).
>
> But if you change make targets, it is highly recommended
> to check with MAKEALL.
> At least, I need both. (for Kbuild and Kconfig work)
>
> I guess we cannot replace MAKEALL with buildman for now.

The intent was that buildman supported everything that MAKEALL does
and more. I believe that is true except for the in-tree build you
mention above. However, I think there might also be some small
difference between the way the -f option is implemented in buildman,
and the way MAKEALL works. It might be worth splitting the -f option
into two:

- one to force rebuild of a board
- another to force a reconfigure on every build

Then we could be sure. In summary, if we do that and support in-tree
builds then I think buildman has all the features of MAKEALL.

BTW a few other options that buildman has, which people may not have noticed:

-S   - shows increase/decrease of image sizes across commits
-B   - same but for individual functions
-k    - keep the build outputs
-d    - show detailed board information
-S   - allows building every second commit, or only first and last, etc.

Regards,
Simon

[U-Boot] MAKEALL

[Masahiro Yamada]

Hello Simon,


> It is not used by default, but there is a -j option. If you use -j,
> first make sure you reduce the number of threads to compensate. So for
> example you can use:
> 
>    buildman -j 8 -T 1

Ooh! I did not know buildman has such options.
Thanks!



> The intent was that buildman supported everything that MAKEALL does
> and more. I believe that is true except for the in-tree build you
> mention above. However, I think there might also be some small
> difference between the way the -f option is implemented in buildman,
> and the way MAKEALL works. It might be worth splitting the -f option
> into two:
> 
> - one to force rebuild of a board
> - another to force a reconfigure on every build
> 
> Then we could be sure. In summary, if we do that and support in-tree
> builds then I think buildman has all the features of MAKEALL.

That's good to know.


Best Regards
Masahiro Yamada

[U-Boot] [STATUS] "Quality" of patches / testing.

[Wolfgang Denk]

Hi all,

the patches that have been submitted for this release turn out to of
of shockingly bad quality.  About every other batch of patches I apply
will break building not only for a single board r a few boards, but
for large numbers of boards, including whole processor families and
even whole architectures.

Not to mention the huge number of patches that have to be rejected
because they raise tons or errors and warnings from checkpatch.pl


The time I have available is limited even without such avoidable
problems, and I really, really rather spend it on constructive work
instead of continuously running git bisect to track down the culprits.

What's even worse is that it appears that I am the only person in this
whole community who runs any build tests.  Or how comes that it's
always me who detects such build breakages?


Note # 3 at http://www.denx.de/wiki/U-Boot/Patches says:

	Before sending the patch, you must run the MAKEALL script on
	your patched source tree and make sure that no errors or
	warnings are reported for any of the boards. Well, at least
	not any more warnings than without your patch.

	It is strongly recommended to verify that out-of-tree building
	(with "-O" make option resp. "BUILD_DIR" environment variable)
	is still working. For example, run:

	$ BUILD_DIR=/tmp/u-boot-build ./MAKEALL

Why is nobody doing this?


I cannot continue like that.  We need to find ways to improve the
quality of the submitted patches, and to distribute the work load for
testing.

I need your help.


Thanks.

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
There are no data that cannot be plotted on a straight  line  if  the
axis are chosen correctly.

[U-Boot] MAKEALL

[Mike Frysinger]

On Tuesday 18 October 2011 02:23:10 Wolfgang Denk wrote:
> 	Before sending the patch, you must run the MAKEALL script on
> 	your patched source tree and make sure that no errors or
> 	warnings are reported for any of the boards. Well, at least
> 	not any more warnings than without your patch.
> 
> 	It is strongly recommended to verify that out-of-tree building
> 	(with "-O" make option resp. "BUILD_DIR" environment variable)
> 	is still working. For example, run:
> 
> 	$ BUILD_DIR=/tmp/u-boot-build ./MAKEALL
> 
> Why is nobody doing this?

because MAKEALL is a pita to use.  it has no automatic CROSS_COMPILE support, 
and the current logic only allows one-CROSS_COMPILE-setting-per-run.  so you 
have to run MAKEALL by hand once per arch.

the documentation you quote only shows running MAKEALL for powerpc (since 
that's the default), so even the docs are a bit unclear.

ideally, MAKEALL should be intelligent and automatically find an appropriate 
toolchain if one isn't setup in the env.  much like the buildall script i 
posted recently.
-mike

[U-Boot] MAKEALL

[Simon Glass]

Hi,

On Tue, Oct 18, 2011 at 10:01 AM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Tuesday 18 October 2011 02:23:10 Wolfgang Denk wrote:
>> ? ? ? Before sending the patch, you must run the MAKEALL script on
>> ? ? ? your patched source tree and make sure that no errors or
>> ? ? ? warnings are reported for any of the boards. Well, at least
>> ? ? ? not any more warnings than without your patch.
>>
>> ? ? ? It is strongly recommended to verify that out-of-tree building
>> ? ? ? (with "-O" make option resp. "BUILD_DIR" environment variable)
>> ? ? ? is still working. For example, run:
>>
>> ? ? ? $ BUILD_DIR=/tmp/u-boot-build ./MAKEALL
>>
>> Why is nobody doing this?
>
> because MAKEALL is a pita to use. ?it has no automatic CROSS_COMPILE support,
> and the current logic only allows one-CROSS_COMPILE-setting-per-run. ?so you
> have to run MAKEALL by hand once per arch.
>
> the documentation you quote only shows running MAKEALL for powerpc (since
> that's the default), so even the docs are a bit unclear.
>
> ideally, MAKEALL should be intelligent and automatically find an appropriate
> toolchain if one isn't setup in the env. ?much like the buildall script i
> posted recently.

Yes I think this is along the right track. I tried MAKEALL a long time
ago and it didn't work (just got an error about incorrect
architecture) so I assumed it was broken. Apart from full docs, it
would be good to have a place to download all the toolchains needed
for MAKEALL.

Regards,
Simon

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

[U-Boot] MAKEALL

[Tom Rini]

On Tue, Oct 18, 2011 at 10:01 AM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Tuesday 18 October 2011 02:23:10 Wolfgang Denk wrote:
>> ? ? ? Before sending the patch, you must run the MAKEALL script on
>> ? ? ? your patched source tree and make sure that no errors or
>> ? ? ? warnings are reported for any of the boards. Well, at least
>> ? ? ? not any more warnings than without your patch.
>>
>> ? ? ? It is strongly recommended to verify that out-of-tree building
>> ? ? ? (with "-O" make option resp. "BUILD_DIR" environment variable)
>> ? ? ? is still working. For example, run:
>>
>> ? ? ? $ BUILD_DIR=/tmp/u-boot-build ./MAKEALL
>>
>> Why is nobody doing this?
>
> because MAKEALL is a pita to use. ?it has no automatic CROSS_COMPILE support,
> and the current logic only allows one-CROSS_COMPILE-setting-per-run. ?so you
> have to run MAKEALL by hand once per arch.
>
> the documentation you quote only shows running MAKEALL for powerpc (since
> that's the default), so even the docs are a bit unclear.
>
> ideally, MAKEALL should be intelligent and automatically find an appropriate
> toolchain if one isn't setup in the env. ?much like the buildall script i
> posted recently.

If we're going to throw out feature requests, I'd like more than one
SoC family support.
I've got a wrapper around MAKEALL right now to build omap3 then omap4
then davinci.

-- 
Tom

[U-Boot] MAKEALL

[Mike Frysinger]

On Tuesday 18 October 2011 13:58:22 Tom Rini wrote:
> On Tue, Oct 18, 2011 at 10:01 AM, Mike Frysinger wrote:
> > On Tuesday 18 October 2011 02:23:10 Wolfgang Denk wrote:
> >>       Before sending the patch, you must run the MAKEALL script on
> >>       your patched source tree and make sure that no errors or
> >>       warnings are reported for any of the boards. Well, at least
> >>       not any more warnings than without your patch.
> >> 
> >>       It is strongly recommended to verify that out-of-tree building
> >>       (with "-O" make option resp. "BUILD_DIR" environment variable)
> >>       is still working. For example, run:
> >> 
> >>       $ BUILD_DIR=/tmp/u-boot-build ./MAKEALL
> >> 
> >> Why is nobody doing this?
> > 
> > because MAKEALL is a pita to use.  it has no automatic CROSS_COMPILE
> > support, and the current logic only allows
> > one-CROSS_COMPILE-setting-per-run.  so you have to run MAKEALL by hand
> > once per arch.
> > 
> > the documentation you quote only shows running MAKEALL for powerpc (since
> > that's the default), so even the docs are a bit unclear.
> > 
> > ideally, MAKEALL should be intelligent and automatically find an
> > appropriate toolchain if one isn't setup in the env.  much like the
> > buildall script i posted recently.
> 
> If we're going to throw out feature requests, I'd like more than one
> SoC family support.
> I've got a wrapper around MAKEALL right now to build omap3 then omap4
> then davinci.

well, i think yours has a much easier chance of being implemented.  and should 
be trivial to do with boards_by_soc.  although i think i have a better idea.  
i'll post a patch.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111018/b2b0af6a/attachment.pgp 

[U-Boot] MAKEALL

[Mike Frysinger]

On Tuesday 18 October 2011 13:58:22 Tom Rini wrote:
> If we're going to throw out feature requests, I'd like more than one
> SoC family support.
> I've got a wrapper around MAKEALL right now to build omap3 then omap4
> then davinci.

hmm, actually doesn't the newish -s flag do what you want ?
	./MAKEALL -s omap3 arm
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111018/15e512e7/attachment.pgp 

[U-Boot] MAKEALL

[Tom Rini]

On Tue, Oct 18, 2011 at 11:31 AM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Tuesday 18 October 2011 13:58:22 Tom Rini wrote:
>> If we're going to throw out feature requests, I'd like more than one
>> SoC family support.
>> I've got a wrapper around MAKEALL right now to build omap3 then omap4
>> then davinci.
>
> hmm, actually doesn't the newish -s flag do what you want ?
> ? ? ? ?./MAKEALL -s omap3 arm

So, -s omap3 -s omap4 looks like it does what I want, -s omap3,omap4 (what I
first guessed) didn't.  So just another vote for more / better docs
that I of course
should help to provide.  Maybe it's time for at least a doc/README.MAKEALL?

-- 
Tom

[U-Boot] MAKEALL

[Mike Frysinger]

On Tuesday 18 October 2011 14:54:09 Tom Rini wrote:
> On Tue, Oct 18, 2011 at 11:31 AM, Mike Frysinger <vapier@gentoo.org> wrote:
> > On Tuesday 18 October 2011 13:58:22 Tom Rini wrote:
> >> If we're going to throw out feature requests, I'd like more than one
> >> SoC family support.
> >> I've got a wrapper around MAKEALL right now to build omap3 then omap4
> >> then davinci.
> > 
> > hmm, actually doesn't the newish -s flag do what you want ?
> >        ./MAKEALL -s omap3 arm
> 
> So, -s omap3 -s omap4 looks like it does what I want, -s omap3,omap4 (what
> I first guessed) didn't.  So just another vote for more / better docs that
> I of course
> should help to provide.  Maybe it's time for at least a doc/README.MAKEALL?

./MAKEALL -h
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111018/379e2086/attachment.pgp 

[U-Boot] MAKEALL

[Wolfgang Denk]

Dear Mike Frysinger,

In message <201110181301.57390.vapier@gentoo.org> you wrote:
>
> because MAKEALL is a pita to use.  it has no automatic CROSS_COMPILE support, 
> and the current logic only allows one-CROSS_COMPILE-setting-per-run.  so you 
> have to run MAKEALL by hand once per arch.
> 
> the documentation you quote only shows running MAKEALL for powerpc (since 
> that's the default), so even the docs are a bit unclear.
> 
> ideally, MAKEALL should be intelligent and automatically find an appropriate 
> toolchain if one isn't setup in the env.  much like the buildall script i 
> posted recently.

How is this supposed to work?  Assume I have a number of different
tool chains, say I want to use the tool chain in /opt/eldk-5.1/armv5te
for all ARM9 systems, that in /opt/eldk-5.1/armv7a for all OMAP based
boards, that in /opt/eldk-5.1/armv6 for Kirkwood processors and yet
another one for the (bix endian) PXA boards.  In all cases we have
ARCH=arm and CROSS_COMPILE=arm-linux-gnueabi-

And then, for compatibility testings, I want to compile all this with
ELDK 4.2.  Or ELDK 4.1. Or CodeSourcery xxx. Or...

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.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Those who hate and fight must stop themselves -- otherwise it is  not
stopped.
	-- Spock, "Day of the Dove", stardate unknown

[U-Boot] MAKEALL

[Mike Frysinger]

On Tuesday 18 October 2011 16:07:38 Wolfgang Denk wrote:
> Mike Frysinger wrote:
> > because MAKEALL is a pita to use.  it has no automatic CROSS_COMPILE
> > support, and the current logic only allows
> > one-CROSS_COMPILE-setting-per-run.  so you have to run MAKEALL by hand
> > once per arch.
> > 
> > the documentation you quote only shows running MAKEALL for powerpc (since
> > that's the default), so even the docs are a bit unclear.
> > 
> > ideally, MAKEALL should be intelligent and automatically find an
> > appropriate toolchain if one isn't setup in the env.  much like the
> > buildall script i posted recently.
> 
> How is this supposed to work?  Assume I have a number of different
> tool chains, say I want to use the tool chain in /opt/eldk-5.1/armv5te
> for all ARM9 systems, that in /opt/eldk-5.1/armv7a for all OMAP based
> boards, that in /opt/eldk-5.1/armv6 for Kirkwood processors and yet
> another one for the (bix endian) PXA boards.  In all cases we have
> ARCH=arm and CROSS_COMPILE=arm-linux-gnueabi-
> 
> And then, for compatibility testings, I want to compile all this with
> ELDK 4.2.  Or ELDK 4.1. Or CodeSourcery xxx. Or...
> 
> 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.

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.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111018/7d206005/attachment.pgp 

[U-Boot] MAKEALL

[Wolfgang Denk]

Dear Mike Frysinger,

In message <201110181614.46289.vapier@gentoo.org> you 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.

> 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.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
In my experience the best way to get something done  is to give it to
someone who is busy.               - Terry Pratchett, _Going_Postal_

[U-Boot] MAKEALL

[Mike Frysinger]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111018/67cf36ed/attachment.pgp 

[U-Boot] MAKEALL

[Simon Glass]

Hi,

On Tue, Oct 18, 2011 at 1:55 PM, Mike Frysinger <vapier@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@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
>
>

[U-Boot] MAKEALL

[Mike Frysinger]

On Tuesday 18 October 2011 17:30:30 Simon Glass wrote:
> 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?

i fear that would break some boards where the maintainer has always used a big 
endian toolchain.  i don't think there are any CONFIG_xxx knobs for boards to 
say "i am big endian" or "i am little endian".
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111018/0e723928/attachment.pgp 

[U-Boot] MAKEALL

[Albert ARIBAUD]

Le 19/10/2011 00:21, Mike Frysinger a ?crit :
> On Tuesday 18 October 2011 17:30:30 Simon Glass wrote:
>> 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?
>
> i fear that would break some boards where the maintainer has always used a big
> endian toolchain.  i don't think there are any CONFIG_xxx knobs for boards to
> say "i am big endian" or "i am little endian".
> -mike

Actually the issue is not with the compiler -- it does build big-endian 
(example taken with scpu):

arm-linux-gcc  -g  -Os   -fno-common -ffixed-r8 -msoft-float 
-mbig-endian -ffunction-sections  -D__KERNEL__ 
-DCONFIG_SYS_TEXT_BASE=0x50000000 -I/home/uboot/src/u-boot-arm/include 
-fno-builtin -ffreestanding -nostdinc -isystem 
/home/uboot/eldk42/usr/bin/../lib/gcc/arm-linux-gnueabi/4.2.2/include 
-pipe  -DCONFIG_ARM -D__ARM__ -marm  -mabi=aapcs-linux 
-mno-thumb-interwork -mbig-endian -march=armv5te -mtune=strongarm1100 
-Wall -Wstrict-prototypes -fno-stack-protector -Wno-format-nonliteral 
-Wno-format-security -fno-toplevel-reorder     -o stubs.o stubs.c -c
arm-linux-ld  -r -o libstubs.o  stubs.o

Notice the -mbig-endian compiler switch.

The issue is with the linker:

arm-linux-ld -r -o libstubs.o  stubs.o

This fails because the linker does not specify -EB and thus links in 
little, not big, endian.

Note that further issues may prevent a big-endian build such as the 
absence of big-endian run-time libs.

Amicalement,
-- 
Albert.	

[U-Boot] MAKEALL

[Mike Frysinger]

On Wednesday 19 October 2011 07:36:15 Albert ARIBAUD wrote:
> Le 19/10/2011 00:21, Mike Frysinger a ?crit :
> > On Tuesday 18 October 2011 17:30:30 Simon Glass wrote:
> >> 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?
> > 
> > i fear that would break some boards where the maintainer has always used
> > a big endian toolchain.  i don't think there are any CONFIG_xxx knobs
> > for boards to say "i am big endian" or "i am little endian".
> 
> Actually the issue is not with the compiler -- it does build big-endian
> (example taken with scpu):

that's because the target you picked has a config.mk which forces -mbig-endian 
in arch/arm/cpu/ixp/config.mk.  that is the only arm soc that does.  i'm pretty 
sure many of the other arm soc's support either big or little endian and it's 
just a matter of what the board wants to do.

> The issue is with the linker:
> 
> arm-linux-ld -r -o libstubs.o  stubs.o
> 
> This fails because the linker does not specify -EB and thus links in
> little, not big, endian.

that's a failing on the part of ixp/config.mk.  it should be adding -EB to the 
linker flags when it forces -mbig-endian.

> Note that further issues may prevent a big-endian build such as the
> absence of big-endian run-time libs.

there is no run-time libs.  only libgcc.a is taken external of u-boot, and 
that issue is resolved by using the private libgcc.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111019/0477ccc1/attachment.pgp 

[U-Boot] MAKEALL

[Wolfgang Denk]

Dear Mike Frysinger,

In message <201110191025.02227.vapier@gentoo.org> you wrote:
>
> there is no run-time libs.  only libgcc.a is taken external of u-boot, and
> that issue is resolved by using the private libgcc.

No.  This is not a solution, it is only a workaround for what I call a
broken tool chain.

If the compiler builds BE code, it must also provie the needed BE
libgcc functions.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Lots of people drink from the wrong bottle sometimes.
	-- Edith Keeler, "The City on the Edge of Forever",
	   stardate unknown

[U-Boot] MAKEALL

[Wolfgang Denk]

Dear Mike Frysinger,

In message <201110181655.29507.vapier@gentoo.org> you wrote:
>
> > 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>

The problem is that this does not differentiate the tool chains.

CROSS_COMPILE would be arm-linux-gnueabi- in all these cases - it's
PATH that needs to be different in my case.  Eventually we should not
try to catch all situations directly, but allow for a
soc|cpu|vendor|board|whatever specific file name to be sourced by the
script, which then would be responsible to set up the environment as
needed?

> 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.

I'm all for improving the current situation.  Thanks!

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
It became apparent that one reason why the Ice Giants were  known  as
the  Ice  Giants  was  because they were, well, giants. The other was
that they were made of ice.              -Terry Pratchett, _Sourcery_

[U-Boot] MAKEALL

[Mike Frysinger]

On Tuesday 18 October 2011 17:50:52 Wolfgang Denk wrote:
> Mike Frysinger wrote:
> > > 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>
> 
> The problem is that this does not differentiate the tool chains.
> 
> CROSS_COMPILE would be arm-linux-gnueabi- in all these cases - it's
> PATH that needs to be different in my case.

or a full path to the toolchain base:
	CROSS_COMPILE=/path/to/foo/arm-linux-gnueabi-

> Eventually we should not try to catch all situations directly, but allow for 
> a soc|cpu|vendor|board|whatever specific file name to be sourced by the
> script, which then would be responsible to set up the environment as
> needed?

toolchains tend to be site-specific.  i use compilers i created myself, or 
found via kernel.org, or i've gotten directly from SoC vendors.  all of which 
have different names.  so while i think it'd be fine for maintainers to specify 
a preference, it would merely be that.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111018/2152920f/attachment.pgp 

[U-Boot] MAKEALL

[Graeme Russ]

Hi Wolfgang,

On Wed, Oct 19, 2011 at 7:07 AM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Mike Frysinger,
>
> In message <201110181301.57390.vapier@gentoo.org> you wrote:
>>
>> because MAKEALL is a pita to use.  it has no automatic CROSS_COMPILE support,
>> and the current logic only allows one-CROSS_COMPILE-setting-per-run.  so you
>> have to run MAKEALL by hand once per arch.
>>
>> the documentation you quote only shows running MAKEALL for powerpc (since
>> that's the default), so even the docs are a bit unclear.
>>
>> ideally, MAKEALL should be intelligent and automatically find an appropriate
>> toolchain if one isn't setup in the env.  much like the buildall script i
>> posted recently.
>
> How is this supposed to work?  Assume I have a number of different
> tool chains, say I want to use the tool chain in /opt/eldk-5.1/armv5te
> for all ARM9 systems, that in /opt/eldk-5.1/armv7a for all OMAP based
> boards, that in /opt/eldk-5.1/armv6 for Kirkwood processors and yet
> another one for the (bix endian) PXA boards.  In all cases we have
> ARCH=arm and CROSS_COMPILE=arm-linux-gnueabi-
>
> And then, for compatibility testings, I want to compile all this with
> ELDK 4.2.  Or ELDK 4.1. Or CodeSourcery xxx. Or...
>
> 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.

IMHO, for running MAKEALL, I see no problem with this. If we had a
'toolchains.cfg' file which could be a format like:

#ARCH	SOC	BOARD	TOOLCHAIN
x86	sc520	-	/path/to/gcc

This would give new developers a head-up as to what the defacto toolchains
are

We can then have 'toolchains.cfg.local' which is added to .gitignore so
individual users can override the toolchain. But all patch submissions
must pass MAKEALL without using toolchains.cfg.local (something like
'MAKEALL --no-custom-toolchains'. The first thing MAKEALL should do is
scan toolchains.cfg (and toolchains.cfg.local if required) for each
selected arch and check that each toolchain is available and spit out
'toolchain not available' warnings.

All we need to do then is setup our build machines to do an automated
git-pull and MAKEALL

Regards,

Graeme

[U-Boot] MAKEALL

[Andreas Bießmann]

Dear Graeme Russ,

Am 19.10.2011 00:33, schrieb Graeme Russ:
> Hi Wolfgang,
> 
> On Wed, Oct 19, 2011 at 7:07 AM, Wolfgang Denk <wd@denx.de> wrote:
>> Dear Mike Frysinger,
>>
>> In message <201110181301.57390.vapier@gentoo.org> you wrote:

<snip>

>> And then, for compatibility testings, I want to compile all this with
>> ELDK 4.2.  Or ELDK 4.1. Or CodeSourcery xxx. Or...
>>
>> 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.
> 
> IMHO, for running MAKEALL, I see no problem with this. If we had a
> 'toolchains.cfg' file which could be a format like:
> 
> #ARCH	SOC	BOARD	TOOLCHAIN
> x86	sc520	-	/path/to/gcc
> 
> This would give new developers a head-up as to what the defacto toolchains
> are

That is OK.

> We can then have 'toolchains.cfg.local' which is added to .gitignore so
> individual users can override the toolchain. But all patch submissions
> must pass MAKEALL without using toolchains.cfg.local (something like
> 'MAKEALL --no-custom-toolchains'. The first thing MAKEALL should do is
> scan toolchains.cfg (and toolchains.cfg.local if required) for each
> selected arch and check that each toolchain is available and spit out
> 'toolchain not available' warnings.

But I don't like to force the users to have _all_ toolchains installed
on their work station. I think the current procedure to MAKEALL _at
least_ two different arches is enough.
Furthermore I don't like to force the users to have a specific toolchain
for submitting a patch to the list. I think it is a benefit to have a
lot of different toolchains on different host systems building the code,
but one should see the build-environment in MAKEALL output to be able to
distinguish between error from patch or error from toolchain.

> All we need to do then is setup our build machines to do an automated
> git-pull and MAKEALL

It is a good idea for some automated build process which runs in the
backyard and spit out some error/warning messages if one patch does
break the build unattended (i.e. the two arches MAKEALL did fail).

best regards

Andreas Bie?mann

[U-Boot] MAKEALL

[Wolfgang Denk]

Dear Graeme Russ,

In message <CALButC+_q+bfZuMJyXjn-GbC1XFWjvGeD-go85LVUvp4S16WnA@mail.gmail.com> you 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.
> 
> IMHO, for running MAKEALL, I see no problem with this. If we had a
> 'toolchains.cfg' file which could be a format like:
> 
> #ARCH	SOC	BOARD	TOOLCHAIN
> x86	sc520	-	/path/to/gcc
> 
> This would give new developers a head-up as to what the defacto toolchains
> are

This is IMO not flexible enough.  The longer I think the more I like
the idea of providing a hook (script file name) that gets passed all
relevant parameters as arguments (target name, arch, cpu, board name,
vendor, soc, options) and that gets sourced by MAKEALL, so it is able
to modify any environment variables (PATH, ARCH, CROSS_COMPILE,
eventually more) as needed.

> We can then have 'toolchains.cfg.local' which is added to .gitignore so
> individual users can override the toolchain. But all patch submissions
> must pass MAKEALL without using toolchains.cfg.local (something like
> 'MAKEALL --no-custom-toolchains'. The first thing MAKEALL should do is
> scan toolchains.cfg (and toolchains.cfg.local if required) for each
> selected arch and check that each toolchain is available and spit out
> 'toolchain not available' warnings.

As mentioned before: a decision based on ARCH alone is not sufficient;
see for example the issues with the big endian ARM boards (PXA).

> All we need to do then is setup our build machines to do an automated
> git-pull and MAKEALL

:-)

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A stone was placed at a ford in a river with the inscription:
"When this stone is covered it is dangerous to ford here."