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@nvidia.com] Sent: Tuesday, August 28, 2012 5:08 PM To: Tom Warren; swarren@wwwdotorg.org; sjg@chromium.org; thierry.reding@avionic-design.de; dev@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,