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

["Andreas Färber" <afaerber@suse.de>]

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

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton; HRB 21284 (AG N?rnberg)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20151015/008246fd/attachment.sig>