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

[Peter Robinson]

On Thu, Oct 15, 2015 at 9:55 PM, Tom Rini <trini at 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 at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>