[U-Boot] [ANN] U-Boot v2015.10-rc5 released
Hey all,
Today is the scheduled release date for v2015.10. But as you can tell from the list of patches I just merged, a lot of stuff needed to go in still and while I'm "happy" it's all safe it's also too much to not do another -rc. So here we are and I'm expecting to do the release next Monday. So please, test this. If you have a regression, speak up. If you have a bugfix, speak up.
And to the maintainers, if you want to start on your "next" branch now so that you can just rebase it to master next week, that might not be a bad idea. I might even do that myself (but please keep your stuff based on my master). Thanks!
Dear Tom,
In message 20151012151845.GJ23893@bill-the-cat you wrote:
Today is the scheduled release date for v2015.10. But as you can tell from the list of patches I just merged, a lot of stuff needed to go in still and while I'm "happy" it's all safe it's also too much to not do another -rc. So here we are and I'm expecting to do the release next Monday. So please, test this. If you have a regression, speak up. If you have a bugfix, speak up.
Thanks. Tarballs are available both on the FTP server and ACD.
Best regards,
Wolfgang Denk
Hello Tom,
Am 12.10.2015 um 17:18 schrieb Tom Rini:
Hey all,
Today is the scheduled release date for v2015.10. But as you can tell from the list of patches I just merged, a lot of stuff needed to go in still and while I'm "happy" it's all safe it's also too much to not do another -rc. So here we are and I'm expecting to do the release next Monday. So please, test this. If you have a regression, speak up. If you have a bugfix, speak up.
I just tested this and ubi on the aristainetos2 board and dfu on the smartweb board seems fine.
As we talked on the U-Boot sumit about automated testsystems, I had successfully setup my tbot [1] I talked, on my raspberry pi at my home.
I start it through buidlbot [2] also running on the raspberry. I use buildbot, because it has fancy possibilities for triggering tests, like nightly builds or if new git commits arrive in tree ...
Also it has a webinterface for presenting the results, see them for my testdemonstration here [3] (maybe slow, because I have a slow internet connection, and the raspberry pi is not the fastest machine ...). There are 2 U-Boot tests:
ari_ubi: ubi/ubifs tests on the aristainetos2 board smartweb_dfu: dfu tests on the smartweb board
You can look into the logs and see, what is done in the tests, currently very basic tests ...
I trigger the tests currently manually. The boards are in the denx vlab in munich, while I am living in hungary ... So I tried in tbot to make it easy to add new labs, which contains 1-n boards. So everybody who has a board can add it, without the need to build up somewhere a big testlab with all boards in it ...
bye, Heiko [1] https://github.com/hsdenx/tbot [2] http://buildbot.net/ [3] http://xeidos.ddns.net/buildbot/waterfall
Hi Tom,
Am 12.10.2015 um 17:18 schrieb Tom Rini:
If you have a regression, speak up.
For -rc4 I had reported that CONFIG_API is broken for sunxi among others. I was told this was fallout of the new Driver Model. Has anyone thought about how to fix this? Is that already a lost cause for 2015.10?
Improving test coverage for such off-by-default features will also be helpful going forward. For instance, Simon's brand-new rk3288 code was lacking some MMC define for CONFIG_API to build iirc - that part is trivial to fix when actually build-testing. I'll see if I can polish some of my fixes in time.
I had also tried building the qemu-ppce500 target and got lots of linker errors with our native gcc 5.x on ppc (duplicate function definitions with arch/powerpc/include/asm/byteorder.h). My first try of a ppc target, haven't found time to investigate further yet, so not sure if a regression or just compiler-dependent.
https://build.opensuse.org/package/live_build_log/home:a_faerber:u-boot:ppc/...
Regards, Andreas
On Thu, Oct 15, 2015 at 02:28:34AM +0200, Andreas Färber wrote:
Hi Tom,
Am 12.10.2015 um 17:18 schrieb Tom Rini:
If you have a regression, speak up.
For -rc4 I had reported that CONFIG_API is broken for sunxi among others. I was told this was fallout of the new Driver Model. Has anyone thought about how to fix this? Is that already a lost cause for 2015.10?
Improving test coverage for such off-by-default features will also be helpful going forward. For instance, Simon's brand-new rk3288 code was lacking some MMC define for CONFIG_API to build iirc - that part is trivial to fix when actually build-testing. I'll see if I can polish some of my fixes in time.
I'm just not sure what to do about CONFIG_API some days. I know one use case is for GRUB but I'd like to move away from that if possible (distros should be doing the generic distro bits and extlinux.conf). After that, I'm only hazily aware of the real use-cases.
I had also tried building the qemu-ppce500 target and got lots of linker errors with our native gcc 5.x on ppc (duplicate function definitions with arch/powerpc/include/asm/byteorder.h). My first try of a ppc target, haven't found time to investigate further yet, so not sure if a regression or just compiler-dependent.
It builds for me but I don't have a gcc 5.x compiler handy. I probably need to find the time to rectify that soon.
Am 15.10.2015 um 02:40 schrieb Tom Rini:
On Thu, Oct 15, 2015 at 02:28:34AM +0200, Andreas Färber wrote:
Am 12.10.2015 um 17:18 schrieb Tom Rini:
If you have a regression, speak up.
For -rc4 I had reported that CONFIG_API is broken for sunxi among others. I was told this was fallout of the new Driver Model. Has anyone thought about how to fix this? Is that already a lost cause for 2015.10?
Improving test coverage for such off-by-default features will also be helpful going forward. For instance, Simon's brand-new rk3288 code was lacking some MMC define for CONFIG_API to build iirc - that part is trivial to fix when actually build-testing. I'll see if I can polish some of my fixes in time.
I'm just not sure what to do about CONFIG_API some days. I know one use case is for GRUB but I'd like to move away from that if possible (distros should be doing the generic distro bits and extlinux.conf). After that, I'm only hazily aware of the real use-cases.
The problem is that no other platform uses those. On x86_64, ppc64le, s390x, aarch64, etc. we always use GRUB2. Whether it's boot.scr, extlinux.conf or anything else, it'll require changes to distro tools that end up being special-cased to 32-bit arm. With more and more server vendors adopting UEFI and aarch64, that seems a waste of effort.
A boot.scr is easy to generate once for an installation image, and I see Guillaume has been helping to make it usable where necessary, but as long as that points to a single zImage / initrd / dtb (ext4 symlinks pointing to the latest), after the user installs a new kernel package, things might simply become unbootable for the average user. That's where GRUB is handy in offering a selection of multiple kernels to go back to a previously working state. I'm not particularly attached to CONFIG_API myself - if the same can be achieved either in GRUB without CONFIG_API or inside U-Boot with scripts and without GRUB, I'd be happy to hear about it. :)
Regarding GRUB, I've mainly tested it on jetson-tk1 (adjusting grub's hardcoded RAM offsets), and I've found it to load unreliably, as if there's garbage in memory. Might be our 2.02~beta2 is missing some backports. bootz works fine, so I guess bootm is not to blame there.
Anyway, I think it's valid to say that we should either fix CONFIG_API to build okay, or drop it completely, but not carry it around in decaying state. ;)
BTW some api example failed to link for some targets, too. According to my spec file, that was with snow, spring and odroid-xu3 (in -rc4), running into an undefined memset (link order maybe?).
Regards, Andreas
On Thu, Oct 15, 2015 at 03:52:08AM +0200, Andreas Färber wrote:
Am 15.10.2015 um 02:40 schrieb Tom Rini:
On Thu, Oct 15, 2015 at 02:28:34AM +0200, Andreas Färber wrote:
Am 12.10.2015 um 17:18 schrieb Tom Rini:
If you have a regression, speak up.
For -rc4 I had reported that CONFIG_API is broken for sunxi among others. I was told this was fallout of the new Driver Model. Has anyone thought about how to fix this? Is that already a lost cause for 2015.10?
Improving test coverage for such off-by-default features will also be helpful going forward. For instance, Simon's brand-new rk3288 code was lacking some MMC define for CONFIG_API to build iirc - that part is trivial to fix when actually build-testing. I'll see if I can polish some of my fixes in time.
I'm just not sure what to do about CONFIG_API some days. I know one use case is for GRUB but I'd like to move away from that if possible (distros should be doing the generic distro bits and extlinux.conf). After that, I'm only hazily aware of the real use-cases.
The problem is that no other platform uses those. On x86_64, ppc64le, s390x, aarch64, etc. we always use GRUB2. Whether it's boot.scr, extlinux.conf or anything else, it'll require changes to distro tools that end up being special-cased to 32-bit arm. With more and more server vendors adopting UEFI and aarch64, that seems a waste of effort.
That's a thing to ponder, yes. There's nothing ARM32 centric about the generic distro framework and it's on my TODO list now to poke Fedora about enabling the extlinux.conf knob on x86 because there's a growing number of platforms using U-Boot there. And hikey does (and Juno should/will) be doing it as well.
A boot.scr is easy to generate once for an installation image, and I see Guillaume has been helping to make it usable where necessary, but as long as that points to a single zImage / initrd / dtb (ext4 symlinks pointing to the latest), after the user installs a new kernel package, things might simply become unbootable for the average user. That's where GRUB is handy in offering a selection of multiple kernels to go back to a previously working state. I'm not particularly attached to CONFIG_API myself - if the same can be achieved either in GRUB without CONFIG_API or inside U-Boot with scripts and without GRUB, I'd be happy to hear about it. :)
Well, that roughly is the point of the whole config_distro_defaults / config_distro_bootcmd stuff is that the distro doesn't have to care what board it's on, it can just boot.
Regarding GRUB, I've mainly tested it on jetson-tk1 (adjusting grub's hardcoded RAM offsets), and I've found it to load unreliably, as if there's garbage in memory. Might be our 2.02~beta2 is missing some backports. bootz works fine, so I guess bootm is not to blame there.
Anyway, I think it's valid to say that we should either fix CONFIG_API to build okay, or drop it completely, but not carry it around in decaying state. ;)
So as Wolfgang brought up, FreeBSD uses CONFIG_API so some care must be taken here, but we need to cover things a lot better than we do today.
On Thu, Oct 15, 2015 at 9:55 PM, Tom Rini trini@konsulko.com wrote:
On Thu, Oct 15, 2015 at 03:52:08AM +0200, Andreas Färber wrote:
Am 15.10.2015 um 02:40 schrieb Tom Rini:
On Thu, Oct 15, 2015 at 02:28:34AM +0200, Andreas Färber wrote:
Am 12.10.2015 um 17:18 schrieb Tom Rini:
If you have a regression, speak up.
For -rc4 I had reported that CONFIG_API is broken for sunxi among others. I was told this was fallout of the new Driver Model. Has anyone thought about how to fix this? Is that already a lost cause for 2015.10?
Improving test coverage for such off-by-default features will also be helpful going forward. For instance, Simon's brand-new rk3288 code was lacking some MMC define for CONFIG_API to build iirc - that part is trivial to fix when actually build-testing. I'll see if I can polish some of my fixes in time.
I'm just not sure what to do about CONFIG_API some days. I know one use case is for GRUB but I'd like to move away from that if possible (distros should be doing the generic distro bits and extlinux.conf). After that, I'm only hazily aware of the real use-cases.
The problem is that no other platform uses those. On x86_64, ppc64le, s390x, aarch64, etc. we always use GRUB2. Whether it's boot.scr, extlinux.conf or anything else, it'll require changes to distro tools that end up being special-cased to 32-bit arm. With more and more server vendors adopting UEFI and aarch64, that seems a waste of effort.
That's a thing to ponder, yes. There's nothing ARM32 centric about the generic distro framework and it's on my TODO list now to poke Fedora about enabling the extlinux.conf knob on x86 because there's a growing number of platforms using U-Boot there. And hikey does (and Juno should/will) be doing it as well.
Sure, do you mean patches against the various boards or something in the actual Fedora shipped components, either way both Dennis and I are on the list.
A boot.scr is easy to generate once for an installation image, and I see Guillaume has been helping to make it usable where necessary, but as long as that points to a single zImage / initrd / dtb (ext4 symlinks pointing to the latest), after the user installs a new kernel package, things might simply become unbootable for the average user. That's where GRUB is handy in offering a selection of multiple kernels to go back to a previously working state. I'm not particularly attached to CONFIG_API myself - if the same can be achieved either in GRUB without CONFIG_API or inside U-Boot with scripts and without GRUB, I'd be happy to hear about it. :)
Well, that roughly is the point of the whole config_distro_defaults / config_distro_bootcmd stuff is that the distro doesn't have to care what board it's on, it can just boot.
And for the platforms that have it enabled it works really well :-)
Regarding GRUB, I've mainly tested it on jetson-tk1 (adjusting grub's hardcoded RAM offsets), and I've found it to load unreliably, as if there's garbage in memory. Might be our 2.02~beta2 is missing some backports. bootz works fine, so I guess bootm is not to blame there.
Anyway, I think it's valid to say that we should either fix CONFIG_API to build okay, or drop it completely, but not carry it around in decaying state. ;)
So as Wolfgang brought up, FreeBSD uses CONFIG_API so some care must be taken here, but we need to cover things a lot better than we do today.
-- Tom
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
On Fri, Oct 16, 2015 at 01:50:47AM +0100, Peter Robinson wrote:
On Thu, Oct 15, 2015 at 9:55 PM, Tom Rini trini@konsulko.com wrote:
On Thu, Oct 15, 2015 at 03:52:08AM +0200, Andreas Färber wrote:
Am 15.10.2015 um 02:40 schrieb Tom Rini:
On Thu, Oct 15, 2015 at 02:28:34AM +0200, Andreas Färber wrote:
Am 12.10.2015 um 17:18 schrieb Tom Rini:
If you have a regression, speak up.
For -rc4 I had reported that CONFIG_API is broken for sunxi among others. I was told this was fallout of the new Driver Model. Has anyone thought about how to fix this? Is that already a lost cause for 2015.10?
Improving test coverage for such off-by-default features will also be helpful going forward. For instance, Simon's brand-new rk3288 code was lacking some MMC define for CONFIG_API to build iirc - that part is trivial to fix when actually build-testing. I'll see if I can polish some of my fixes in time.
I'm just not sure what to do about CONFIG_API some days. I know one use case is for GRUB but I'd like to move away from that if possible (distros should be doing the generic distro bits and extlinux.conf). After that, I'm only hazily aware of the real use-cases.
The problem is that no other platform uses those. On x86_64, ppc64le, s390x, aarch64, etc. we always use GRUB2. Whether it's boot.scr, extlinux.conf or anything else, it'll require changes to distro tools that end up being special-cased to 32-bit arm. With more and more server vendors adopting UEFI and aarch64, that seems a waste of effort.
That's a thing to ponder, yes. There's nothing ARM32 centric about the generic distro framework and it's on my TODO list now to poke Fedora about enabling the extlinux.conf knob on x86 because there's a growing number of platforms using U-Boot there. And hikey does (and Juno should/will) be doing it as well.
Sure, do you mean patches against the various boards or something in the actual Fedora shipped components, either way both Dennis and I are on the list.
With respect to Fedora, it would be pretty nice if I could install F23 on my Minnowboard Max and have it use config_distro_bootcmd stuff. I think I mentioned this to Hans at ELCE and he said I probably just need to ask and x86 can have the same extlinux.conf generation stuff that ARM has :) I of course need to go whack the minnow config in U-Boot, but that's on me..
> If you have a regression, speak up.
For -rc4 I had reported that CONFIG_API is broken for sunxi among others. I was told this was fallout of the new Driver Model. Has anyone thought about how to fix this? Is that already a lost cause for 2015.10?
Improving test coverage for such off-by-default features will also be helpful going forward. For instance, Simon's brand-new rk3288 code was lacking some MMC define for CONFIG_API to build iirc - that part is trivial to fix when actually build-testing. I'll see if I can polish some of my fixes in time.
I'm just not sure what to do about CONFIG_API some days. I know one use case is for GRUB but I'd like to move away from that if possible (distros should be doing the generic distro bits and extlinux.conf). After that, I'm only hazily aware of the real use-cases.
The problem is that no other platform uses those. On x86_64, ppc64le, s390x, aarch64, etc. we always use GRUB2. Whether it's boot.scr, extlinux.conf or anything else, it'll require changes to distro tools that end up being special-cased to 32-bit arm. With more and more server vendors adopting UEFI and aarch64, that seems a waste of effort.
That's a thing to ponder, yes. There's nothing ARM32 centric about the generic distro framework and it's on my TODO list now to poke Fedora about enabling the extlinux.conf knob on x86 because there's a growing number of platforms using U-Boot there. And hikey does (and Juno should/will) be doing it as well.
Sure, do you mean patches against the various boards or something in the actual Fedora shipped components, either way both Dennis and I are on the list.
With respect to Fedora, it would be pretty nice if I could install F23 on my Minnowboard Max and have it use config_distro_bootcmd stuff. I think I mentioned this to Hans at ELCE and he said I probably just need to ask and x86 can have the same extlinux.conf generation stuff that ARM has :) I of course need to go whack the minnow config in U-Boot, but that's on me..
Ah, that's one for installer support so if it sees u-boot on x86 it updates the appropriate bits of the bootloader. Those bits should be relatively straight forward, it's on my list to investigate for aarch64 too so I'll keep it in mine when I try to get around to doing that.
Peter
On Thursday, October 15, 2015 04:55:55 PM Tom Rini wrote:
On Thu, Oct 15, 2015 at 03:52:08AM +0200, Andreas Färber wrote:
Am 15.10.2015 um 02:40 schrieb Tom Rini:
On Thu, Oct 15, 2015 at 02:28:34AM +0200, Andreas Färber wrote:
Am 12.10.2015 um 17:18 schrieb Tom Rini:
If you have a regression, speak up.
For -rc4 I had reported that CONFIG_API is broken for sunxi among others. I was told this was fallout of the new Driver Model. Has anyone thought about how to fix this? Is that already a lost cause for 2015.10?
Improving test coverage for such off-by-default features will also be helpful going forward. For instance, Simon's brand-new rk3288 code was lacking some MMC define for CONFIG_API to build iirc - that part is trivial to fix when actually build-testing. I'll see if I can polish some of my fixes in time.
I'm just not sure what to do about CONFIG_API some days. I know one use case is for GRUB but I'd like to move away from that if possible (distros should be doing the generic distro bits and extlinux.conf). After that, I'm only hazily aware of the real use-cases.
The problem is that no other platform uses those. On x86_64, ppc64le, s390x, aarch64, etc. we always use GRUB2. Whether it's boot.scr, extlinux.conf or anything else, it'll require changes to distro tools that end up being special-cased to 32-bit arm. With more and more server vendors adopting UEFI and aarch64, that seems a waste of effort.
That's a thing to ponder, yes. There's nothing ARM32 centric about the generic distro framework and it's on my TODO list now to poke Fedora about enabling the extlinux.conf knob on x86 because there's a growing number of platforms using U-Boot there. And hikey does (and Juno should/will) be doing it as well.
it is already there https://rhinstaller.github.io/anaconda/boot-options.html#boot-loader-options add extlinux to the boot arguments on a x86 install and it will use extlinux.
A boot.scr is easy to generate once for an installation image, and I see Guillaume has been helping to make it usable where necessary, but as long as that points to a single zImage / initrd / dtb (ext4 symlinks pointing to the latest), after the user installs a new kernel package, things might simply become unbootable for the average user. That's where GRUB is handy in offering a selection of multiple kernels to go back to a previously working state. I'm not particularly attached to CONFIG_API myself - if the same can be achieved either in GRUB without CONFIG_API or inside U-Boot with scripts and without GRUB, I'd be happy to hear about it. :)
Well, that roughly is the point of the whole config_distro_defaults / config_distro_bootcmd stuff is that the distro doesn't have to care what board it's on, it can just boot.
yep :)
Regarding GRUB, I've mainly tested it on jetson-tk1 (adjusting grub's hardcoded RAM offsets), and I've found it to load unreliably, as if there's garbage in memory. Might be our 2.02~beta2 is missing some backports. bootz works fine, so I guess bootm is not to blame there.
Anyway, I think it's valid to say that we should either fix CONFIG_API to build okay, or drop it completely, but not carry it around in decaying state. ;)
So as Wolfgang brought up, FreeBSD uses CONFIG_API so some care must be taken here, but we need to cover things a lot better than we do today.
the reason we did not look at grub was that it needed hard coded values, so you would need different grub builds for different boards. and a whole world of extra pain, and no one was actively working on the arm port of grub. u-boot had the extlinux support built in. though I need to find time to extend it a bit.
Dennis
Dear Tom,
In message 20151015004002.GX23893@bill-the-cat you wrote:
I'm just not sure what to do about CONFIG_API some days. I know one use case is for GRUB but I'd like to move away from that if possible (distros should be doing the generic distro bits and extlinux.conf). After that, I'm only hazily aware of the real use-cases.
The major use case (as I understand it) are the FreeBSD users who need this API for booting. I'm adding Rafal and Bartek to Cc: as they should know best if this interface is still in wide use.
Best regards,
Wolfgang Denk
Hi Wolfgang, Tom,
On Thu, Oct 15, 2015 at 9:28 AM, Wolfgang Denk wd@denx.de wrote:
Dear Tom,
In message 20151015004002.GX23893@bill-the-cat you wrote:
I'm just not sure what to do about CONFIG_API some days. I know one use case is for GRUB but I'd like to move away from that if possible (distros should be doing the generic distro bits and extlinux.conf). After that, I'm only hazily aware of the real use-cases.
The major use case (as I understand it) are the FreeBSD users who need this API for booting. I'm adding Rafal and Bartek to Cc: as they should know best if this interface is still in wide use.
Indeed, it's actively and widely used by the FreeBSD [last stage] bootloader.
Thanks, Rafal
participants (7)
-
Andreas Färber -
Dennis Gilmore -
Heiko Schocher -
Peter Robinson -
Rafal Jaworowski -
Tom Rini -
Wolfgang Denk