> 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).
