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)
signature.asc
Description: OpenPGP digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot