On Wed, Nov 12, 2014 at 05:16:42PM -0500, Tom Rini wrote: > On Wed, Nov 12, 2014 at 04:10:06PM -0500, Tom Rini wrote: > > On Wed, Nov 12, 2014 at 12:04:39PM -0500, Tom Rini wrote: > > > On Wed, Nov 12, 2014 at 10:12:30AM +0100, Andreas Bießmann wrote: > > > > Hi Tom, > > > > > > > > On 11/10/2014 10:29 PM, Tom Rini wrote: > > > > > Hey all, > > > > > > > > > > I've pushed v2015.01-rc1 out to the repository and tarballs should > > > > > exist > > > > > soon. > > > > > > > > > > The merge window is now closed. Per both the min-summit and the > > > > > follow > > > > > up emails, I'm going to try and get into the every 2 week RC tagging > > > > > groove. And, I'm going to be relying on everyones best judgement > > > > > about > > > > > what level of changes they're going to put into a pull request to me. > > > > > > > > > > When I do a buildman of most things I see: > > > > > blackfin: + ip04 > > > > > arm: + Ippo_q8h_v5 novena openrd_base maxbcm openrd_ultimate > > > > > openrd_client tricorder db-mv784mp-gp Linksprite_pcDuino3_fdt > > > > > tricorder_flash cm_t3517 > > > > > > > > there must be something wrong: > > > > > > Compiler fun! With Linaro 2013.03 gcc 4.7.3 we're 260 bytes over the > > > limit on SPL. With ELDK 5.4's 4.7.x we're 543 bytes under the limit. > > > What I think I had been thinking was that you could move > > > CONFIG_SPL_STACK into DDR and bump the max size a bit or based on > > > CONFIG_FLASHCARD or not build NAND or MMC into MLO but not both (and > > > that'd be a bigger size savings). > > > > > > Or maybe the answer is that I need to stop using that Linaro toolchain > > > for 4.7.x testing. > > > > ... ELDK 5.5.x also has a similar slight size overflow and is 4.8.x. I > > guess for now I'll default to use ELDK 5.4 for ARM but people may need > > to consider a something-something for newer toolchains sooner rather > > than later. > > ... I'm actually running into that issue where buildman grabs things > from $PATH sometimes rather than the toolchain it found, re-running some > tests.
OK, purging the Ubuntu toolchain packages so that buildman really uses
what I tell it, I'm getting the best (build time) results with ELDK
5.5.2 for ARM. After some patches that I'm about to push:
Summary of current source for 1166 boards (6 threads, 1 job per thread)
arm: + maxbcm odroid db-mv784mp-gp
+(maxbcm) u16 reg;
+(maxbcm,maxbcm) ^
+(maxbcm) u16 devadr = CONFIG_PHY_BASE_ADDR;
+(maxbcm,maxbcm) Didn't find the file 'board/maxbcm/binary.0' in
'arm/current/.bm-work/
03/build' which is mandatory to generate the image
+(maxbcm,maxbcm,db-mv784mp-gp,db-mv784mp-gp) This file generally contains the
DDR3 training code, and should be extracted from an existing bootable
+(maxbcm,maxbcm,db-mv784mp-gp,db-mv784mp-gp) image for your board. See
'kwbimage -x' to extract it from an existing image.
+(maxbcm,db-mv784mp-gp) Could not create image
+(maxbcm,db-mv784mp-gp) make[1]: *** [u-boot.kwb] Error 1
+(maxbcm,db-mv784mp-gp) make: *** [sub-make] Error 2
+(odroid,odroid) addr = CONFIG_SYS_SDRAM_BASE + (i * SDRAM_BANK_SIZE);
+(odroid,odroid) ^
+(odroid) board/samsung/common/board.c:94:2: note: containing loop
+(odroid,odroid) for (i = 0; i < CONFIG_NR_DRAM_BANKS; i++) {
+(odroid,odroid) ^
+(odroid) board/samsung/common/board.c:106:2: note: containing loop
+(db-mv784mp-gp,db-mv784mp-gp) Didn't find the file
'board/Marvell/db-mv784mp-gp/binary.0' in 'arm/current/.bm-work/03/build' which
is mandatory to generate the image
w+(maxbcm) board/maxbcm/maxbcm.c: In function 'reset_phy':
w+(maxbcm) board/maxbcm/maxbcm.c:68:6: warning: unused variable 'reg'
[-Wunused-variable]
w+(maxbcm) board/maxbcm/maxbcm.c:66:6: warning: unused variable 'devadr'
[-Wunused-variable]
w+(odroid) board/samsung/common/board.c: In function 'dram_init':
w+(odroid) board/samsung/common/board.c:95:32: warning: iteration 4u invokes
undefined behavior [-Waggressive-loop-optimizations]
w+(odroid) board/samsung/common/board.c: In function 'dram_init_banksize':
w+(odroid) board/samsung/common/board.c:107:32: warning: iteration 4u invokes
undefined behavior [-Waggressive-loop-optimizations]
--
Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
