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

[Albert ARIBAUD <albert.u.boot@aribaud.net>]

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.boot@aribaud.net> wrote:

> Hi Allen,
> 
> On Wed, 29 Aug 2012 11:33:06 -0700, Allen Martin <amartin@nvidia.com>
> wrote:
> 
> > On Wed, Aug 29, 2012 at 09:55:17AM -0700, Tom Warren wrote:
> > > Allen/Albert,
> > > 
> > > > -----Original Message-----
> > > > From: Allen Martin [mailto:amartin at nvidia.com]
> > > > Sent: Tuesday, August 28, 2012 5:08 PM
> > > > To: Tom Warren; swarren at wwwdotorg.org; sjg at chromium.org;
> > > > thierry.reding at avionic-design.de; dev at lynxeye.de
> > > > Cc: u-boot at 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.