From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?Andreas_F=c3=a4rber?= Date: Thu, 15 Oct 2015 03:52:08 +0200 Subject: [U-Boot] [ANN] U-Boot v2015.10-rc5 released In-Reply-To: <20151015004002.GX23893@bill-the-cat> References: <20151012151845.GJ23893@bill-the-cat> <561EF332.6090102@suse.de> <20151015004002.GX23893@bill-the-cat> Message-ID: <561F06C8.5020006@suse.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.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: