On Thu, Oct 15, 2015 at 9:55 PM, Tom Rini <tr...@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@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot