[U-Boot] [ANN] U-Boot v2015.10-rc5 released

[Dennis Gilmore]

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