On Tue, May 09, 2023 at 09:54:59AM +1000, David Gwynne wrote: > > > > On 8 May 2023, at 22:44, Mark Kettenis <mark.kette...@xs4all.nl> wrote: > > > >> From: Patrick Wildt <patr...@blueri.se> > >> Date: Mon, 8 May 2023 14:14:27 +0200 > >> > >>> Am 07.05.2023 um 19:54 schrieb Klemens Nanni <k...@openbsd.org>: > >>> > >>> On Sun, May 07, 2023 at 06:30:55PM +0200, Mark Kettenis wrote: > >>>> As I've said before, the u-boot developers have poor quality control > >>>> and this will almost certainly break some targets. > >>>> > >>>> I think the way forward is to have a u-boot port per SoC such that we > >>>> can leave older SoCs using an older U-Boot version that we know to be > >>>> good while newer SoCs can switch to a newer version after testing a > >>>> few boards. > >>> > >>> That should always work. Not sure if pulling them out of the main u-boot > >>> port one by one or all at once is better, though. > >>> > >>> For the 2207.* update it seemed as if the Pinebook Pro's breakage alone > >>> kept > >>> all others boards on outdated versions and we practically have no other > >>> way > >>> of disentangling this mess, afaict. > >>> > >>> We already have sysutils/u-boot-asahi. > >>> > >>> Would mean some ports shuffling and installing more package where boot > >>> media > >>> is built, but that doesn't seem like too much work. > >> > >> Why don‘t we change the armv7 miniroots to not provide any U-Boot, > >> like we already do on arm64, > > > > Not against doing this, but by "old" I don't necessarily mean just > > armv7. > > > >> and then we can remove the whole U-Boot port and not have to > >> maintain it? > > > > Unfortunately there isn't a good source for pre-built U-Boot binaries, > > let alone a source of pre-built U-Boot binaries that didn't somehow > > fuck up EFI support. > > > > So I think the u-boot port *is* useful even if we don't use it to > > create bootable installer images. But only as long as we don't ship a > > package with broken images. It is clear that we don't have the > > manpower and infrastructure to test a large enough fraction of the > > u-boot binaries that our current u-boot package produces. Hence my > > suggestion to split the package (and mostly forget about the older > > ones where new versions of U-Boot don't really add any new > > functionality). > > I agree completely with Mark here.
Honestly I'm not going to do the work of splitting of this U-Boot port into multiple "old but stable" ports. I'd rather have an up-to-date port where sometimes a machine doesn't boot because U-Boot people fucked up, than an old version that only works on machines built in 2020. If someone wants to split the port off into multiple ports for their favourite machine, please go ahead. But I guess I'll just continue to use a U-Boot git clone in my home directory to build one-time FW for my needs. Well actually, maybe we should just rm -rf the whole port, then there's no frustration on either end. ;) Cheers, Patrick
