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