[U-Boot] [ANN] U-Boot v2015.01-rc1 released
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 powerpc: + kmcoge4 taishan kmlion1 dlvision
And I'd really like to see those sorted out, one way or another for -rc2.
As always, if anything is broken please speak up.
Thanks all!
On Mon, 10 Nov 2014 16:29:38 -0500 Tom Rini trini@ti.com wrote:
Hey all,
I've pushed v2015.01-rc1 out to the repository and tarballs should exist soon.
Half a day has passed since Tom's "I've pushed v2015.rc-rc1" mail, but I still don't see it.
I have been often wondering why we can see the release much lator of Tom's announce mail.
When I push my u-boot-uniphier repo, I can see the update on the public repo.
Best Regards Masahiro Yamada
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:
---8<--- abiessmann@punisher % git describe v2015.01-rc1-14-g63f7af9 abiessmann@punisher % PATH=/opt/CS.Toolchain-0.3.0-rc1/arm-arm926ejs-linux-gnueabi/bin:$PATH make O=/tmp/build-tricorder CROSS_COMPILE=arm-arm926ejs-linux-gnueabi- -s -j16 tricorder_defconfig In file included from scripts/kconfig/zconf.tab.c:2537:0: /home/abiessmann/src/u-boot/scripts/kconfig/menu.c: In function ‘get_symbol_str’: /home/abiessmann/src/u-boot/scripts/kconfig/menu.c:590:18: warning: ‘jump’ may be used uninitialized in this function [-Wmaybe-uninitialized] jump->offset = strlen(r->s); ^ /home/abiessmann/src/u-boot/scripts/kconfig/menu.c:551:19: note: ‘jump’ was declared here struct jump_key *jump; ^ # # configuration written to .config # # # configuration written to spl/.config # abiessmann@punisher % PATH=/opt/CS.Toolchain-0.3.0-rc1/arm-arm926ejs-linux-gnueabi/bin:$PATH make O=/tmp/build-tricorder CROSS_COMPILE=arm-arm926ejs-linux-gnueabi- -s -j16 PATH=/opt/CS.Toolchain-0.3.0-rc1/arm-arm926ejs-linux-gnueabi/bin:$PATH make 36.56s user 1.68s system 404% cpu 9.463 total abiessmann@punisher % rm -rf /tmp/build-tricorder abiessmann@punisher % PATH=/opt/CS.Toolchain-0.3.0-rc1/arm-arm926ejs-linux-gnueabi/bin:$PATH make O=/tmp/build-tricorder CROSS_COMPILE=arm-arm926ejs-linux-gnueabi- -s -j16 tricorder_flash_defconfig In file included from scripts/kconfig/zconf.tab.c:2537:0: /home/abiessmann/src/u-boot/scripts/kconfig/menu.c: In function ‘get_symbol_str’: /home/abiessmann/src/u-boot/scripts/kconfig/menu.c:590:18: warning: ‘jump’ may be used uninitialized in this function [-Wmaybe-uninitialized] jump->offset = strlen(r->s); ^ /home/abiessmann/src/u-boot/scripts/kconfig/menu.c:551:19: note: ‘jump’ was declared here struct jump_key *jump; ^ # # configuration written to .config # # # configuration written to spl/.config # abiessmann@punisher % PATH=/opt/CS.Toolchain-0.3.0-rc1/arm-arm926ejs-linux-gnueabi/bin:$PATH make O=/tmp/build-tricorder CROSS_COMPILE=arm-arm926ejs-linux-gnueabi- -s -j16 PATH=/opt/CS.Toolchain-0.3.0-rc1/arm-arm926ejs-linux-gnueabi/bin:$PATH make 35.62s user 1.58s system 526% cpu 7.063 total abiessmann@punisher % abiessmann@punisher % ./tools/buildman/buildman -o /tmp/testbuild -c 1 -b master tricorder boards.cfg is up to date. Nothing to do. Building 1 commit for 2 boards (2 threads, 4 jobs per thread) Cloning repo for thread 0 Cloning repo for thread 1 2 0 0 /2 0:00:10 : tricorder ./tools/buildman/buildman -o /tmp/testbuild -c 1 -b master tricorder 73.72s user 4.00s system 338% cpu 22.986 total abiessmann@punisher % --->8---
Best regards
Andreas Bießmann
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.
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.
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.
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]
Hi Tom,
On 11/10/2014 11: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
I am able to build cm_t3517 without any problems.
On Wed, Nov 12, 2014 at 08:24:47PM +0200, Nikita Kiryanov wrote:
Hi Tom,
On 11/10/2014 11: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
I am able to build cm_t3517 without any problems.
OK, that failure was a race condition, sorry for the noise!
Hi Marek,
On 10/11/2014 22:29, 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
I confirm the issue with novena after pulling mainline into u-boot-imx. It looks like that CONFIG_SPL_LDSCRIPT is somewhere unset (I do not why, gw_ventana is built fine).
Marek, can you take a look at it ?
Thanks !
Stefano
On Thursday, November 13, 2014 at 10:46:16 AM, Stefano Babic wrote:
Hi Marek,
On 10/11/2014 22:29, 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_t3517I confirm the issue with novena after pulling mainline into u-boot-imx. It looks like that CONFIG_SPL_LDSCRIPT is somewhere unset (I do not why, gw_ventana is built fine).
Marek, can you take a look at it ?
Yes, you have an email fixing this.
Best regards, Marek Vasut
Hey Tom,
2014-11-10 22:29 GMT+01:00 Tom Rini trini@ti.com:
... 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 powerpc: + kmcoge4 taishan kmlion1 dlvision
And I'd really like to see those sorted out, one way or another for -rc2.
dlvision should be fixed with the "Update gdsys board support" series that is already under review by Stefan Roese and Kim Phillips.
Cheers Dirk
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 powerpc: + kmcoge4 taishan kmlion1 dlvision
And I'd really like to see those sorted out, one way or another for -rc2.
For both kmcoge4 and kmlion1, the error is fixed by [1].
Hopefully York will be able to review this, also with the 2 patches for the migration of the keymile powerpc board to generic board, for -rc2.
Best Regards
Valentin
participants (8)
-
Andreas Bießmann -
Dirk Eibach -
Marek Vasut -
Masahiro Yamada -
Nikita Kiryanov -
Stefano Babic -
Tom Rini -
Valentin Longchamp