Re: [U-Boot] MAKEALL: Don't try to print size when ./u-boot is deleted

[Tom Rini]

On Wed, Mar 11, 2015 at 06:47:33PM -0500, Joe Hershberger wrote:

 In the case of BUILD_NBUILDS  1, MAKEALL would try to print the size
 immediately after the u-boot binary is deleted by the call to:
 
 make -s clean
 
 Move the size print to before the clean
 
 Signed-off-by: Joe Hershberger joe.hershber...@ni.com

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] MAKEALL

[Simon Glass]

Hi,

On 12 February 2014 03:42, Masahiro Yamada yamad...@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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] MAKEALL

[Albert ARIBAUD]

Hi Simon,

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

 Hi York,
 
 
 On 4 January 2014 02:21, Wolfgang Denk w...@denx.de wrote:
 
  Dear York,
 
  In message 52c7424a.4090...@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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] MAKEALL

[JYOTI DUBEY]

What is the use of executing MAKEALL file available in u-boot folder?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] MAKEALL

[Anatolij Gustschin]

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

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

./MAKEALL -h 

HTH,

Anatolij

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] MAKEALL

[Anatolij Gustschin]

first, please keep mailing list in CC.

On Wed, 29 Jan 2014 12:56:55 +0530
JYOTI DUBEY jyoti0...@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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] MAKEALL

[Simon Glass]

Hi York,


On 4 January 2014 02:21, Wolfgang Denk w...@denx.de wrote:

 Dear York,

 In message 52c7424a.4090...@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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] MAKEALL

[Wolfgang Denk]

Dear York,

In message 52c7424a.4090...@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: w...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] MAKEALL build error on usb/master branch

[Troy Kisky]

Hi Marek

I thought you might like to be aware of this error, if not already known.

Thanks
Troy


/u-boot-imx6/LOG$ cat mx28evk.ERR
mxsimage.c:18:25: fatal error: openssl/evp.h: No such file or directory
compilation terminated.
make[1]: *** [mxsimage.o] Error 1
make[1]: *** Waiting for unfinished jobs
make[1]: *** wait: No child processes.  Stop.
make: *** [tools] Error 2

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] MAKEALL build error on usb/master branch

[Marek Vasut]

Dear Troy Kisky,

 Hi Marek
 
 I thought you might like to be aware of this error, if not already known.

Known, when building for MXS (mx23 and mx28), you need libssl-dev installed 
(openssl development libs and headers). Same rule applies when you use signed 
FIT images.

So, solution is to install libssl-dev (for debian-based distro) or whatever 
your 
favorite distro has.

Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] MAKEALL build error on usb/master branch

[Troy Kisky]

On 9/26/2013 1:22 PM, Marek Vasut wrote:

Dear Troy Kisky,


Hi Marek

I thought you might like to be aware of this error, if not already known.

Known, when building for MXS (mx23 and mx28), you need libssl-dev installed
(openssl development libs and headers). Same rule applies when you use signed
FIT images.

So, solution is to install libssl-dev (for debian-based distro) or whatever your
favorite distro has.

Best regards,
Marek Vasut


Thanks Marek

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] MAKEALL: Fix case substitution for old bash

[Tom Rini]

On Fri, Mar 22, 2013 at 07:37:03AM -, York Sun wrote:

 Bash ver 3.x doesn't support the parameter expansion with case
 substitution. Use tr instead.
 
 Signed-off-by: York Sun york...@freescale.com
 Acked-by: Allen Martin amar...@nvidia.com

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] ./MAKEALL arm is buggy

[Albert ARIBAUD]

Hi Allen,

On Wed, 29 Aug 2012 11:33:06 -0700, Allen Martin amar...@nvidia.com
wrote:

 On Wed, Aug 29, 2012 at 09:55:17AM -0700, Tom Warren wrote:
  Allen/Albert,
  
   -Original Message-
   From: Allen Martin [mailto:amar...@nvidia.com]
   Sent: Tuesday, August 28, 2012 5:08 PM
   To: Tom Warren; swar...@wwwdotorg.org; s...@chromium.org;
   thierry.red...@avionic-design.de; d...@lynxeye.de
   Cc: u-boot@lists.denx.de; Allen Martin
   Subject: [PATCH v10 00/16] split tegra20 arm7 code into separate SPL
  
   This patch series fixes a long standing problem with the tegra20 u-boot
   build.  Tegra20 contains an ARM7TDMI boot processor and a Cortex A9 main
   processor.  Prior to this patch series this was accomplished by #ifdefing
   out any armv7 code from the early boot sequence and creating a single 
   binary
   that runs on both both the ARM7TDMI and A9.  This was very fragile as
   changes to compiler options or any additions or rearranging of the early
   boot code could add additional armv7 specific code causing it to fail on 
   the
   ARM7TDMI.
  
   This patch series pulls all the armv4t code out into a separate SPL that
   does nothing more than initialize the A9 and transfer control to it.  The
   resultint SPL and armv7 u-boot are concatenated together into a single
   image.
  
   This patch series is also available from:
   git://github.com/arm000/u-boot.git
   branch: tegra-spl-v10
  
   Changes:
   v10:
- added fix to MAKEALL script so that it correctly parses new  boards.cfg
  
  I applied this to u-boot-tegra/master and pushed the new code upstream. The 
  pull request remains the same (except for the inclusion of the MAKEALL 
  patch, of course). I can send a new one if required - please let me know.
  
  Currently running a ./MAKEALL arm - I assume it'll complete w/o errors 
  (except for the ohci-hcd.c warnings I mentioned previously that are not due 
  to this patch series).
  
 
 Changing subject line to get Albert's attention

My attention latency is a bit layered right now. during the week I'm
primarily going through my 'non-colorful' mail -- 'colorful' being
those with my address in Cc: (condition Orange) and To: (condition Red)
respectively -- and ARM patches, then the rest as remaining time allows.

 Thanks Tom.  I traced down why ./MAKEALL arm and ./MAKEALL -a arm
 come up with a different list of boards.  It's because the LIST_arm
 rule in MAKEALL which ./MAKEALL arm uses is buggy and error prone.
 It's building all the Atmel boards twice and skipping a bunch of others
 like the arm720t, arm946es, and arm1176 boards.
 
 I'm going to work on a patch to make LIST_arm use the same logic as
 ./MAKEALL -a arm but in the mean time I strongly suggest using
 ./MAKEALL -a arm since it generates the correct list of boards.
 
 -Allen

Just to point out that there were discussions in the past regarding the
difference between ./MAKEALL arm and ./MAKEALL -a arm; I use '-a arm'.

In any case, thanks for digging into MAKEALL! Any bug you see sure will
go in 2013.04. If you need any help for cross-checking issue on
another setup than yours, please ping me, either in To: or through IRC.

BTW, recently I have seen MAKEALL -a arm fail sporadically on some
boards during parallel builds; more specifically, with BUILD_NBUILDS=8
and BUILD_NCPUS=1. Note that the actual machine has a 4-core, 8-thread
CPU, so maybe that was because the number of parallel builds was just
equal to the number of (pseudo) CPUs available; I am now using six
parallel builds and haven't seen the issue again so far.

(also, I prepend the command with LANG=C to avoid making the error
messages any more French than they already are when I copy-paste them
to the list. Not sure how that could have any influence on the build
errors, of course.)

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] ./MAKEALL arm is buggy - scratch that...

[Albert ARIBAUD]

Scratch thtat: for some reason this old discussion popped up under my
eyes and due to my current issues with MAKEALL, I blanked on the date.
I'll repost that part on parallel MAKEALL failing in parallel apart.

Sorry for the noise. :/

On Sat, 9 Feb 2013 08:31:06 +0100, Albert ARIBAUD
albert.u.b...@aribaud.net wrote:

 Hi Allen,
 
 On Wed, 29 Aug 2012 11:33:06 -0700, Allen Martin amar...@nvidia.com
 wrote:
 
  On Wed, Aug 29, 2012 at 09:55:17AM -0700, Tom Warren wrote:
   Allen/Albert,
   
-Original Message-
From: Allen Martin [mailto:amar...@nvidia.com]
Sent: Tuesday, August 28, 2012 5:08 PM
To: Tom Warren; swar...@wwwdotorg.org; s...@chromium.org;
thierry.red...@avionic-design.de; d...@lynxeye.de
Cc: u-boot@lists.denx.de; Allen Martin
Subject: [PATCH v10 00/16] split tegra20 arm7 code into separate SPL
   
This patch series fixes a long standing problem with the tegra20 u-boot
build.  Tegra20 contains an ARM7TDMI boot processor and a Cortex A9 main
processor.  Prior to this patch series this was accomplished by 
#ifdefing
out any armv7 code from the early boot sequence and creating a single 
binary
that runs on both both the ARM7TDMI and A9.  This was very fragile as
changes to compiler options or any additions or rearranging of the early
boot code could add additional armv7 specific code causing it to fail 
on the
ARM7TDMI.
   
This patch series pulls all the armv4t code out into a separate SPL that
does nothing more than initialize the A9 and transfer control to it.  
The
resultint SPL and armv7 u-boot are concatenated together into a single
image.
   
This patch series is also available from:
git://github.com/arm000/u-boot.git
branch: tegra-spl-v10
   
Changes:
v10:
 - added fix to MAKEALL script so that it correctly parses new  
boards.cfg
   
   I applied this to u-boot-tegra/master and pushed the new code upstream. 
   The pull request remains the same (except for the inclusion of the 
   MAKEALL patch, of course). I can send a new one if required - please let 
   me know.
   
   Currently running a ./MAKEALL arm - I assume it'll complete w/o errors 
   (except for the ohci-hcd.c warnings I mentioned previously that are not 
   due to this patch series).
   
  
  Changing subject line to get Albert's attention
 
 My attention latency is a bit layered right now. during the week I'm
 primarily going through my 'non-colorful' mail -- 'colorful' being
 those with my address in Cc: (condition Orange) and To: (condition Red)
 respectively -- and ARM patches, then the rest as remaining time allows.
 
  Thanks Tom.  I traced down why ./MAKEALL arm and ./MAKEALL -a arm
  come up with a different list of boards.  It's because the LIST_arm
  rule in MAKEALL which ./MAKEALL arm uses is buggy and error prone.
  It's building all the Atmel boards twice and skipping a bunch of others
  like the arm720t, arm946es, and arm1176 boards.
  
  I'm going to work on a patch to make LIST_arm use the same logic as
  ./MAKEALL -a arm but in the mean time I strongly suggest using
  ./MAKEALL -a arm since it generates the correct list of boards.
  
  -Allen
 
 Just to point out that there were discussions in the past regarding the
 difference between ./MAKEALL arm and ./MAKEALL -a arm; I use '-a arm'.
 
 In any case, thanks for digging into MAKEALL! Any bug you see sure will
 go in 2013.04. If you need any help for cross-checking issue on
 another setup than yours, please ping me, either in To: or through IRC.
 
 BTW, recently I have seen MAKEALL -a arm fail sporadically on some
 boards during parallel builds; more specifically, with BUILD_NBUILDS=8
 and BUILD_NCPUS=1. Note that the actual machine has a 4-core, 8-thread
 CPU, so maybe that was because the number of parallel builds was just
 equal to the number of (pseudo) CPUs available; I am now using six
 parallel builds and haven't seen the issue again so far.
 
 (also, I prepend the command with LANG=C to avoid making the error
 messages any more French than they already are when I copy-paste them
 to the list. Not sure how that could have any influence on the build
 errors, of course.)
 
 Amicalement,

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] MAKEALL: add a -C/--check option to enable build checking

[Tom Rini]

On Thu, Sep 27, 2012 at 02:57:34PM -, Kim Phillips wrote:

 thanks to Tom Rini for the good idea.
 
 Signed-off-by: Kim Phillips kim.phill...@freescale.com

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] ./MAKEALL arm is buggy

[Allen Martin]

On Wed, Aug 29, 2012 at 09:55:17AM -0700, Tom Warren wrote:
 Allen/Albert,
 
  -Original Message-
  From: Allen Martin [mailto:amar...@nvidia.com]
  Sent: Tuesday, August 28, 2012 5:08 PM
  To: Tom Warren; swar...@wwwdotorg.org; s...@chromium.org;
  thierry.red...@avionic-design.de; d...@lynxeye.de
  Cc: u-boot@lists.denx.de; Allen Martin
  Subject: [PATCH v10 00/16] split tegra20 arm7 code into separate SPL
 
  This patch series fixes a long standing problem with the tegra20 u-boot
  build.  Tegra20 contains an ARM7TDMI boot processor and a Cortex A9 main
  processor.  Prior to this patch series this was accomplished by #ifdefing
  out any armv7 code from the early boot sequence and creating a single binary
  that runs on both both the ARM7TDMI and A9.  This was very fragile as
  changes to compiler options or any additions or rearranging of the early
  boot code could add additional armv7 specific code causing it to fail on the
  ARM7TDMI.
 
  This patch series pulls all the armv4t code out into a separate SPL that
  does nothing more than initialize the A9 and transfer control to it.  The
  resultint SPL and armv7 u-boot are concatenated together into a single
  image.
 
  This patch series is also available from:
  git://github.com/arm000/u-boot.git
  branch: tegra-spl-v10
 
  Changes:
  v10:
   - added fix to MAKEALL script so that it correctly parses new  boards.cfg
 
 I applied this to u-boot-tegra/master and pushed the new code upstream. The 
 pull request remains the same (except for the inclusion of the MAKEALL patch, 
 of course). I can send a new one if required - please let me know.
 
 Currently running a ./MAKEALL arm - I assume it'll complete w/o errors 
 (except for the ohci-hcd.c warnings I mentioned previously that are not due 
 to this patch series).
 

Changing subject line to get Albert's attention

Thanks Tom.  I traced down why ./MAKEALL arm and ./MAKEALL -a arm
come up with a different list of boards.  It's because the LIST_arm
rule in MAKEALL which ./MAKEALL arm uses is buggy and error prone.
It's building all the Atmel boards twice and skipping a bunch of others
like the arm720t, arm946es, and arm1176 boards.

I'm going to work on a patch to make LIST_arm use the same logic as
./MAKEALL -a arm but in the mean time I strongly suggest using
./MAKEALL -a arm since it generates the correct list of boards.

-Allen
-- 
nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [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 w...@denx.de wrote:
 Dear Mike Frysinger,

 In message 201110181301.57390.vap...@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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] MAKEALL

[Wolfgang Denk]

Dear Graeme Russ,

In message calbutc+_q+bfzumjyxjn-gbc1xfwjvged-go85lvuvp4s16...@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: w...@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.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [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=0x5000 -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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [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


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] MAKEALL

[Wolfgang Denk]

Dear Mike Frysinger,

In message 201110191025.02227.vap...@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: w...@denx.de
Lots of people drink from the wrong bottle sometimes.
-- Edith Keeler, The City on the Edge of Forever,
   stardate unknown
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] MAKEALL

[Simon Glass]

Hi,

On Tue, Oct 18, 2011 at 10:01 AM, Mike Frysinger vap...@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@lists.denx.de
 http://lists.denx.de/mailman/listinfo/u-boot

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] MAKEALL

[Tom Rini]

On Tue, Oct 18, 2011 at 10:01 AM, Mike Frysinger vap...@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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [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


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [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


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] MAKEALL

[Tom Rini]

On Tue, Oct 18, 2011 at 11:31 AM, Mike Frysinger vap...@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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [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 vap...@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


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] MAKEALL

[Wolfgang Denk]

Dear Mike Frysinger,

In message 201110181301.57390.vap...@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: w...@denx.de
Those who hate and fight must stop themselves -- otherwise it is  not
stopped.
-- Spock, Day of the Dove, stardate unknown
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [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


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] MAKEALL

[Wolfgang Denk]

Dear Mike Frysinger,

In message 201110181614.46289.vap...@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: w...@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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [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


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] MAKEALL

[Simon Glass]

Hi,

On Tue, Oct 18, 2011 at 1:55 PM, Mike Frysinger vap...@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.va...@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@lists.denx.de
 http://lists.denx.de/mailman/listinfo/u-boot


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] MAKEALL

[Wolfgang Denk]

Dear Mike Frysinger,

In message 201110181655.29507.vap...@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: w...@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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [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


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [MAKEALL arm] gcc 4.5.2/32 bit - 99 of 204 broken (was:Re: Pull request: u-boot-arm/master -- updated)

[Reinhard Meyer]

Dear Albert,
 Since this is an ARM question, I'll look into it, and since Wolfgang 
 will be on vacation, I suggest either that we either postpone -rc1, or 
 (preferably IMO) that we tag -rc1 now with a specific warning about the 
 ARM tree, and I analyze what the issue is using several ARM toolchains, 
 both on a 32 and a 64 bits system, with a resolution on -rc2.
 
 I think the resolution should be fast because on a 32-bit system (sorry, 
 don't have one any more, will keep a VM somewhere from now on...) the 
 failure rate is 100%, thus I should be able to quickly set up a 32-bit 
 VM and ELDK 4.2 and pinpoint the issue, say during the week-end.

This is my results of MAKEALL arm on current u-boot-arm/master
(6623feeaa463f5931fe684f900f605999cd844e2 Merge remote-tracking branch
'u-boot-atmel/master' into m):

- SUMMARY 
Boards compiled: 204
Boards with warnings or errors: 99 ( assabet dnp1110 gcplus lart shannon
ap7 ap720t armadillo B2 ep7312 evb4510 impa7 integratorap lpc2292sodimm
modnet50 SMN42 ap920t ap922_XA10 ap926ejs ap946es ap966 cp920t
cp922_XA10 cp926ejs cp946es cp966 edb9301 edb9302 edb9302a edb9307
edb9307a edb9312 edb9315 edb9315a edminiv2 guruplug jadecpu km_kirkwood
lpd7a400 mv88f6281gtw_ge mx1fs2 netstar openrd_base openrd_client
openrd_ultimate portl2 rd6281a sbc2410x scb9328 sheevaplug smdk2400
smdk2410 spear300 spear310 spear320 spear600 VCMA9 versatile versatileab
versatilepb voiceblue integratorcp cp1026 cp1136 omap2420h4 apollon
imx31_litekit imx31_phycore imx31_phycore_eet mx31ads mx31pdk
mx31pdk_nand qong smdk6400 dig297 igep0020 mx51evk omap3_beagle
omap3_overo omap3_evm omap3_zoom2 omap4_panda omap4_sdp4430 at91cap9adk
csb226 lubbock zylonite actux1_4_16 actux1_8_16 actux1_4_32 actux1_8_32
actux2 actux3 actux4 dvlhost ixdp425 ixdpg425 pdnb3 scpu )
--

Toolchain:
arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.5.2-8ubuntu3) 4.5.2
on ubuntu 11.04 in virtual machine (VMware) on WinXP (32 Bit)

Best Regards,
Reinhard

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] MAKEALL: Add summary information breaks MAKEALL return code

[Wolfgang Denk]

Dear Peter,

your commit 40a28f0885 (MAKEALL: Add summary information) breaks
MAKEALL because we now don't get any useful return code any more.
You may argument that we didn't get one before, which is correct for
building multiple boards in one call. But when running something like
MAKEALL board we did get a return code, so wee could use this for
example with git bisect run.

One possible fix could look like this:

diff --git a/MAKEALL b/MAKEALL
index d63c5c2..0cafed8 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -952,13 +952,16 @@ build_target() {
 #---
 
 print_stats() {
+   rc=0
echo 
echo - SUMMARY 
echo Boards compiled: ${TOTAL_CNT}
if [ ${ERR_CNT} -gt 0 ] ; then
+   rc=1
echo Boards with warnings or errors: ${ERR_CNT} (${ERR_LIST} )
fi
echo --
+   exit $rc
 }
 
 #---


But I don't really like this approach, as it still changes behaviour:
now even warnings get accounted as errors. What do you think?

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: w...@denx.de
An expert is a person who avoids the small errors while  sweeping  on
to the grand fallacy.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] MAKEALL: Add summary information breaks MAKEALL return code

[Peter Tyser]

Hi Wolfgang,

 your commit 40a28f0885 (MAKEALL: Add summary information) breaks
 MAKEALL because we now don't get any useful return code any more.
 You may argument that we didn't get one before, which is correct for
 building multiple boards in one call. But when running something like
 MAKEALL board we did get a return code, so wee could use this for
 example with git bisect run.

I'm not seeing a useful return code before the change:

pty...@petert u-boot $ git reset --hard 40a28f0885~1
HEAD is now at 71ce9bd galaxy5200: enable version environment variable
pty...@petert u-boot $ echo asdf  common/cmd_nvedit.c
pty...@petert u-boot $ ./MAKEALL MVBLUE; echo $?
Configuring for MVBLUE board...
cmd_nvedit.c:643: error: expected '=', ',', ';', 'asm' or
'__attribute__' at end of input
make[1]: *** [cmd_nvedit.o] Error 1
make[1]: *** Waiting for unfinished jobs
make: *** [common/libcommon.a] Error 2
powerpc-linux-size: './u-boot': No such file
0

pty...@petert u-boot $ git checkout master
M   common/cmd_nvedit.c
Already on master
Your branch is behind 'origin/master' by 334 commits, and can be
fast-forwarded.
pty...@petert u-boot $ echo asdf  common/cmd_nvedit.c
pty...@petert u-boot $ ./MAKEALL MVBLUE; echo $?
Configuring for MVBLUE board...
cmd_nvedit.c:644: error: expected '=', ',', ';', 'asm' or
'__attribute__' before 'asdf'
make[1]: *** [cmd_nvedit.o] Error 1
make[1]: *** Waiting for unfinished jobs
make: *** [common/libcommon.a] Error 2
powerpc-linux-size: './u-boot': No such file
0

Do you have an example of what breaks?

It seems like the behavior should be the same before/after the change.
In both cases the last command is tee -a ${LOG_DIR}/$target.MAKELOG,
which always returns 0.

I agree that it would be nice to have a valid return code either way
though:)

Peter

 One possible fix could look like this:
 
 diff --git a/MAKEALL b/MAKEALL
 index d63c5c2..0cafed8 100755
 --- a/MAKEALL
 +++ b/MAKEALL
 @@ -952,13 +952,16 @@ build_target() {
  #---
  
  print_stats() {
 + rc=0
   echo 
   echo - SUMMARY 
   echo Boards compiled: ${TOTAL_CNT}
   if [ ${ERR_CNT} -gt 0 ] ; then
 + rc=1
   echo Boards with warnings or errors: ${ERR_CNT} (${ERR_LIST} )
   fi
   echo --
 + exit $rc
  }
  
  #---
 
 
 But I don't really like this approach, as it still changes behaviour:
 now even warnings get accounted as errors. What do you think?
 
 Best regards,
 
 Wolfgang Denk
 

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] MAKEALL, don't have other cross compile

[xiangfu]

Wolfgang Denk wrote:
 Dear xiangfu,
 
 In message 4a35b1a5.3030...@gmail.com you wrote:
 I have add a new board to u-boot. and try to run MAKEALL.
 but I don't have other cross compiler. I only have mips cross compiler
 how to deal with this?
 
 How about downloading and installing one?? For example, ELDK is
 available for PowerPC, ARM and MIPS, so it's fairly easy to cover at
 least these three architectures.
 
 Best regards,
 
 Wolfgang Denk
 
Thanks Wolfgang. I will try to do that.

-- 
Best Regards
Xiangfu Liu

jabber : xiangf...@gmail.com
skype  : xiangfu.z
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] MAKEALL, don't have other cross compile

[xiangfu]

Hi

I have add a new board to u-boot. and try to run MAKEALL.
but I don't have other cross compiler. I only have mips cross compiler
how to deal with this?


-- 
Best Regards
Xiangfu Liu

jabber : xiangf...@gmail.com
skype  : xiangfu.z
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] MAKEALL ml507_flash return Not enough room forprogramheaders error

[Benny Chen]

Hi Guys,

The above error message was resolved by using the ELDK cross compiler.
Previously I was using Xilinxs powerpc-eabi-xx cross compiler to build
U-Boot. 

Cheers,
Benny

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Benny Chen
Sent: Wednesday, 5 November 2008 3:10 PM
To: Ricardo
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] MAKEALL ml507_flash return Not enough room
forprogramheaders error

Hi Ricardo,

Thanks for helping with this issue.  My real option is to do a long jump
to the _start code.   However, I am not familiar with the PPC assembler
hence, I am not able to get the longcall working.

_start is written in assembler in cpu/ppc_4xx/start.S therefore, I need
to do a longcall from assembler which I am not sure how to do.  Could
you please help advise on how I can do a longcall in assembler?

Further, investigation I found that the other option is to do a function
pointer call to _start.  When written in C this should force the use of
the CTR register which is 32-bit to hold the _start address.  But I
don't know how to do this in assembler.  If you have any idea on this it
would be much appreciated.


Thanks once again mate.

Regards,
Benny


-Original Message-
From: Ricardo [mailto:[EMAIL PROTECTED]
Sent: Tue 04/11/2008 19:13
To: Benny Chen
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] MAKEALL ml507_flash return Not enough room for
programheaders error
 
Hello Benny

  Maybe if you move your _start to the booptg section you will solve
your problem or you can also modify the jump to be a long jump.


  Best regards

On Tue, Nov 4, 2008 at 06:11, Benny Chen [EMAIL PROTECTED]
wrote:
 Hi Ricardo,
 Changing my tool chain to the ELDK 4.2 ppc-linux-x86 does build the
 default ml507_flash project.  However, because my hardware design does
 not map the FLASH chip to 0xFE00 but to 0x8600 the build
failed
 with the following error.

 /**/
 cpu/ppc4xx/start.o: In function `rsttlb':

 /usr/local/groundprobe/src/Bootloader/u-boot/cpu/ppc4xx/start.S:493:
 relocation truncated to fit: R_PPC_REL24 against symbol `_start'
defined
 in .text section in cpu/ppc4xx/start.o
 /*/

 I think this issue maybe to do with the 24bit branch address limit
with
 the PPC440x5 core. Here the _start_440 function calls a b _start and
 in this case the _start is mapped to flash in address 0x8600.
 Meaning we now need to branch from 0xFxxx to 0x8600.  I think
 this is why the linker failed at the last stage.

 Does anyone have any idea with this issue?

 Regards,
 Benny

 -Original Message-
 From: Ricardo [mailto:[EMAIL PROTECTED]
 Sent: Monday, 3 November 2008 6:26 PM
 To: Benny Chen
 Cc: u-boot@lists.denx.de
 Subject: Re: [U-Boot] MAKEALL ml507_flash return Not enough room for
 programheaders error

 Hello Benny

  I have just checkout the build of the ml507_flash and works ok for me

 [EMAIL PROTECTED]:~/curro/qtec/u-boot$ ./MAKEALL ml507_flash
 Configuring for ml507 board...
   textdata bss dec hex filename
  202132   10476   30032  242640   3b3d0 ./u-boot


  I remember that when I was using another toolchain the final link
 failed (but showing different error). Try with another toochain, I am
 using one produced by OpenEmbedded, but you will get the same results
 with the ELDK


  Best regards



 On Mon, Nov 3, 2008 at 07:59, Benny Chen [EMAIL PROTECTED]
 wrote:
 Hi there,

 I am trying to build a U-Boot image for the ML507 board running from
 FLASH and got the Not enough room for program headers error.



 The main difference for my setup is the toolchain.  I am using the
 powerpc-eabi-ld linker from Xilinx's EDK tool chain to build the
 ml507_flash design for U-Boot.



 I have seen a patch on the linker script for the mpc8555cds board and
 tried adding the patch to the Xilinx/ppc440-generic/u-boot-rom.lds
but
 got the relocation truncated to fit R_PPC_REL24 error.

 Before going further with debugging this problem, I would like to
 check
 if this problem is due to the powerpc-eabi tool chain from Xilinx?



 Thanks for your help.



 Regards,

 Benny



 $ ./MAKEALL ml507_flash

 Configuring for ml507 board...

 powerpc-eabi-ld: u-boot: Not enough room for program headers
 (allocated
 2, need 5)

 powerpc-eabi-ld: final link failed: Bad value

 make: *** [u-boot] Error 1

 size: './u-boot': No such file








 ___
 U-Boot mailing list
 U-Boot@lists.denx.de
 http://lists.denx.de/mailman/listinfo/u-boot





 --
 Ricardo Ribalda
 http://www.eps.uam.es/~rribalda/




-- 
Ricardo Ribalda
http://www.eps.uam.es/~rribalda/

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] MAKEALL ml507_flash return Not enough room for programheaders error

[Ricardo]

Hello Benny

  Maybe if you move your _start to the booptg section you will solve
your problem or you can also modify the jump to be a long jump.


  Best regards

On Tue, Nov 4, 2008 at 06:11, Benny Chen [EMAIL PROTECTED] wrote:
 Hi Ricardo,
 Changing my tool chain to the ELDK 4.2 ppc-linux-x86 does build the
 default ml507_flash project.  However, because my hardware design does
 not map the FLASH chip to 0xFE00 but to 0x8600 the build failed
 with the following error.

 /**/
 cpu/ppc4xx/start.o: In function `rsttlb':

 /usr/local/groundprobe/src/Bootloader/u-boot/cpu/ppc4xx/start.S:493:
 relocation truncated to fit: R_PPC_REL24 against symbol `_start' defined
 in .text section in cpu/ppc4xx/start.o
 /*/

 I think this issue maybe to do with the 24bit branch address limit with
 the PPC440x5 core. Here the _start_440 function calls a b _start and
 in this case the _start is mapped to flash in address 0x8600.
 Meaning we now need to branch from 0xFxxx to 0x8600.  I think
 this is why the linker failed at the last stage.

 Does anyone have any idea with this issue?

 Regards,
 Benny

 -Original Message-
 From: Ricardo [mailto:[EMAIL PROTECTED]
 Sent: Monday, 3 November 2008 6:26 PM
 To: Benny Chen
 Cc: u-boot@lists.denx.de
 Subject: Re: [U-Boot] MAKEALL ml507_flash return Not enough room for
 programheaders error

 Hello Benny

  I have just checkout the build of the ml507_flash and works ok for me

 [EMAIL PROTECTED]:~/curro/qtec/u-boot$ ./MAKEALL ml507_flash
 Configuring for ml507 board...
   textdata bss dec hex filename
  202132   10476   30032  242640   3b3d0 ./u-boot


  I remember that when I was using another toolchain the final link
 failed (but showing different error). Try with another toochain, I am
 using one produced by OpenEmbedded, but you will get the same results
 with the ELDK


  Best regards



 On Mon, Nov 3, 2008 at 07:59, Benny Chen [EMAIL PROTECTED]
 wrote:
 Hi there,

 I am trying to build a U-Boot image for the ML507 board running from
 FLASH and got the Not enough room for program headers error.



 The main difference for my setup is the toolchain.  I am using the
 powerpc-eabi-ld linker from Xilinx's EDK tool chain to build the
 ml507_flash design for U-Boot.



 I have seen a patch on the linker script for the mpc8555cds board and
 tried adding the patch to the Xilinx/ppc440-generic/u-boot-rom.lds but
 got the relocation truncated to fit R_PPC_REL24 error.

 Before going further with debugging this problem, I would like to
 check
 if this problem is due to the powerpc-eabi tool chain from Xilinx?



 Thanks for your help.



 Regards,

 Benny



 $ ./MAKEALL ml507_flash

 Configuring for ml507 board...

 powerpc-eabi-ld: u-boot: Not enough room for program headers
 (allocated
 2, need 5)

 powerpc-eabi-ld: final link failed: Bad value

 make: *** [u-boot] Error 1

 size: './u-boot': No such file








 ___
 U-Boot mailing list
 U-Boot@lists.denx.de
 http://lists.denx.de/mailman/listinfo/u-boot





 --
 Ricardo Ribalda
 http://www.eps.uam.es/~rribalda/




-- 
Ricardo Ribalda
http://www.eps.uam.es/~rribalda/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] MAKEALL ml507_flash return Not enough room for programheaders error

[Benny Chen]

Hi Ricardo,

Thanks for helping with this issue.  My real option is to do a long jump to the 
_start code.   However, I am not familiar with the PPC assembler hence, I am 
not able to get the longcall working.

_start is written in assembler in cpu/ppc_4xx/start.S therefore, I need to do a 
longcall from assembler which I am not sure how to do.  Could you please help 
advise on how I can do a longcall in assembler?

Further, investigation I found that the other option is to do a function 
pointer call to _start.  When written in C this should force the use of the CTR 
register which is 32-bit to hold the _start address.  But I don't know how to 
do this in assembler.  If you have any idea on this it would be much 
appreciated.


Thanks once again mate.

Regards,
Benny


-Original Message-
From: Ricardo [mailto:[EMAIL PROTECTED]
Sent: Tue 04/11/2008 19:13
To: Benny Chen
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] MAKEALL ml507_flash return Not enough room for 
programheaders error
 
Hello Benny

  Maybe if you move your _start to the booptg section you will solve
your problem or you can also modify the jump to be a long jump.


  Best regards

On Tue, Nov 4, 2008 at 06:11, Benny Chen [EMAIL PROTECTED] wrote:
 Hi Ricardo,
 Changing my tool chain to the ELDK 4.2 ppc-linux-x86 does build the
 default ml507_flash project.  However, because my hardware design does
 not map the FLASH chip to 0xFE00 but to 0x8600 the build failed
 with the following error.

 /**/
 cpu/ppc4xx/start.o: In function `rsttlb':

 /usr/local/groundprobe/src/Bootloader/u-boot/cpu/ppc4xx/start.S:493:
 relocation truncated to fit: R_PPC_REL24 against symbol `_start' defined
 in .text section in cpu/ppc4xx/start.o
 /*/

 I think this issue maybe to do with the 24bit branch address limit with
 the PPC440x5 core. Here the _start_440 function calls a b _start and
 in this case the _start is mapped to flash in address 0x8600.
 Meaning we now need to branch from 0xFxxx to 0x8600.  I think
 this is why the linker failed at the last stage.

 Does anyone have any idea with this issue?

 Regards,
 Benny

 -Original Message-
 From: Ricardo [mailto:[EMAIL PROTECTED]
 Sent: Monday, 3 November 2008 6:26 PM
 To: Benny Chen
 Cc: u-boot@lists.denx.de
 Subject: Re: [U-Boot] MAKEALL ml507_flash return Not enough room for
 programheaders error

 Hello Benny

  I have just checkout the build of the ml507_flash and works ok for me

 [EMAIL PROTECTED]:~/curro/qtec/u-boot$ ./MAKEALL ml507_flash
 Configuring for ml507 board...
   textdata bss dec hex filename
  202132   10476   30032  242640   3b3d0 ./u-boot


  I remember that when I was using another toolchain the final link
 failed (but showing different error). Try with another toochain, I am
 using one produced by OpenEmbedded, but you will get the same results
 with the ELDK


  Best regards



 On Mon, Nov 3, 2008 at 07:59, Benny Chen [EMAIL PROTECTED]
 wrote:
 Hi there,

 I am trying to build a U-Boot image for the ML507 board running from
 FLASH and got the Not enough room for program headers error.



 The main difference for my setup is the toolchain.  I am using the
 powerpc-eabi-ld linker from Xilinx's EDK tool chain to build the
 ml507_flash design for U-Boot.



 I have seen a patch on the linker script for the mpc8555cds board and
 tried adding the patch to the Xilinx/ppc440-generic/u-boot-rom.lds but
 got the relocation truncated to fit R_PPC_REL24 error.

 Before going further with debugging this problem, I would like to
 check
 if this problem is due to the powerpc-eabi tool chain from Xilinx?



 Thanks for your help.



 Regards,

 Benny



 $ ./MAKEALL ml507_flash

 Configuring for ml507 board...

 powerpc-eabi-ld: u-boot: Not enough room for program headers
 (allocated
 2, need 5)

 powerpc-eabi-ld: final link failed: Bad value

 make: *** [u-boot] Error 1

 size: './u-boot': No such file








 ___
 U-Boot mailing list
 U-Boot@lists.denx.de
 http://lists.denx.de/mailman/listinfo/u-boot





 --
 Ricardo Ribalda
 http://www.eps.uam.es/~rribalda/




-- 
Ricardo Ribalda
http://www.eps.uam.es/~rribalda/

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] MAKEALL ml507_flash return Not enough room for programheaders error

[Ricardo]

Hello Benny

  I have just checkout the build of the ml507_flash and works ok for me

[EMAIL PROTECTED]:~/curro/qtec/u-boot$ ./MAKEALL ml507_flash
Configuring for ml507 board...
   textdata bss dec hex filename
 202132   10476   30032  242640   3b3d0 ./u-boot


  I remember that when I was using another toolchain the final link
failed (but showing different error). Try with another toochain, I am
using one produced by OpenEmbedded, but you will get the same results
with the ELDK


  Best regards



On Mon, Nov 3, 2008 at 07:59, Benny Chen [EMAIL PROTECTED] wrote:
 Hi there,

 I am trying to build a U-Boot image for the ML507 board running from
 FLASH and got the Not enough room for program headers error.



 The main difference for my setup is the toolchain.  I am using the
 powerpc-eabi-ld linker from Xilinx's EDK tool chain to build the
 ml507_flash design for U-Boot.



 I have seen a patch on the linker script for the mpc8555cds board and
 tried adding the patch to the Xilinx/ppc440-generic/u-boot-rom.lds but
 got the relocation truncated to fit R_PPC_REL24 error.

 Before going further with debugging this problem, I would like to check
 if this problem is due to the powerpc-eabi tool chain from Xilinx?



 Thanks for your help.



 Regards,

 Benny



 $ ./MAKEALL ml507_flash

 Configuring for ml507 board...

 powerpc-eabi-ld: u-boot: Not enough room for program headers (allocated
 2, need 5)

 powerpc-eabi-ld: final link failed: Bad value

 make: *** [u-boot] Error 1

 size: './u-boot': No such file








 ___
 U-Boot mailing list
 U-Boot@lists.denx.de
 http://lists.denx.de/mailman/listinfo/u-boot





-- 
Ricardo Ribalda
http://www.eps.uam.es/~rribalda/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] MAKEALL ml507_flash return Not enough room for programheaders error

[Benny Chen]

Hi Ricardo,
Changing my tool chain to the ELDK 4.2 ppc-linux-x86 does build the
default ml507_flash project.  However, because my hardware design does
not map the FLASH chip to 0xFE00 but to 0x8600 the build failed
with the following error.

/**/
cpu/ppc4xx/start.o: In function `rsttlb':

/usr/local/groundprobe/src/Bootloader/u-boot/cpu/ppc4xx/start.S:493:
relocation truncated to fit: R_PPC_REL24 against symbol `_start' defined
in .text section in cpu/ppc4xx/start.o
/*/

I think this issue maybe to do with the 24bit branch address limit with
the PPC440x5 core. Here the _start_440 function calls a b _start and
in this case the _start is mapped to flash in address 0x8600.
Meaning we now need to branch from 0xFxxx to 0x8600.  I think
this is why the linker failed at the last stage.

Does anyone have any idea with this issue?

Regards,
Benny

-Original Message-
From: Ricardo [mailto:[EMAIL PROTECTED] 
Sent: Monday, 3 November 2008 6:26 PM
To: Benny Chen
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] MAKEALL ml507_flash return Not enough room for
programheaders error

Hello Benny

  I have just checkout the build of the ml507_flash and works ok for me

[EMAIL PROTECTED]:~/curro/qtec/u-boot$ ./MAKEALL ml507_flash
Configuring for ml507 board...
   textdata bss dec hex filename
 202132   10476   30032  242640   3b3d0 ./u-boot


  I remember that when I was using another toolchain the final link
failed (but showing different error). Try with another toochain, I am
using one produced by OpenEmbedded, but you will get the same results
with the ELDK


  Best regards



On Mon, Nov 3, 2008 at 07:59, Benny Chen [EMAIL PROTECTED]
wrote:
 Hi there,

 I am trying to build a U-Boot image for the ML507 board running from
 FLASH and got the Not enough room for program headers error.



 The main difference for my setup is the toolchain.  I am using the
 powerpc-eabi-ld linker from Xilinx's EDK tool chain to build the
 ml507_flash design for U-Boot.



 I have seen a patch on the linker script for the mpc8555cds board and
 tried adding the patch to the Xilinx/ppc440-generic/u-boot-rom.lds but
 got the relocation truncated to fit R_PPC_REL24 error.

 Before going further with debugging this problem, I would like to
check
 if this problem is due to the powerpc-eabi tool chain from Xilinx?



 Thanks for your help.



 Regards,

 Benny



 $ ./MAKEALL ml507_flash

 Configuring for ml507 board...

 powerpc-eabi-ld: u-boot: Not enough room for program headers
(allocated
 2, need 5)

 powerpc-eabi-ld: final link failed: Bad value

 make: *** [u-boot] Error 1

 size: './u-boot': No such file








 ___
 U-Boot mailing list
 U-Boot@lists.denx.de
 http://lists.denx.de/mailman/listinfo/u-boot





-- 
Ricardo Ribalda
http://www.eps.uam.es/~rribalda/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] MAKEALL ml507_flash return Not enough room for program headers error

[Benny Chen]

Hi there,

I am trying to build a U-Boot image for the ML507 board running from
FLASH and got the Not enough room for program headers error.

 

The main difference for my setup is the toolchain.  I am using the
powerpc-eabi-ld linker from Xilinx's EDK tool chain to build the
ml507_flash design for U-Boot.

 

I have seen a patch on the linker script for the mpc8555cds board and
tried adding the patch to the Xilinx/ppc440-generic/u-boot-rom.lds but
got the relocation truncated to fit R_PPC_REL24 error.  
 
Before going further with debugging this problem, I would like to check
if this problem is due to the powerpc-eabi tool chain from Xilinx? 

 

Thanks for your help.

 

Regards,

Benny

 

$ ./MAKEALL ml507_flash

Configuring for ml507 board...

powerpc-eabi-ld: u-boot: Not enough room for program headers (allocated
2, need 5)

powerpc-eabi-ld: final link failed: Bad value

make: *** [u-boot] Error 1

size: './u-boot': No such file

 

 

 

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot