While in previous EPEL releases we've only build the tools, for EPEL 10 we would like to request a full uboot build, including the images. Among other things, this will make it easier to work on platform enablement for Apple Silicon downstream, which is something the CentOS Hyperscale SIG is interested in pursuing. Also please note that the tools don't currently build as-is on EPEL 10 because of the openssl ENGINE removal in RHEL 10.

I have a tentative patch to allow building without the ENGINE at https://pagure.io/fedora-asahi/uboot-tools/blob/main/f/openssl-no-engine.patch . Will submit this upstream after some additional testing.

(In reply to Davide Cavalca from comment #1)
> While in previous EPEL releases we've only build the tools, for EPEL 10 we
> would like to request a full uboot build, including the images. Among other
> things, this will make it easier to work on platform enablement for Apple
> Silicon downstream, which is something the CentOS Hyperscale SIG is
> interested in pursuing. Also please note that the tools don't currently
> build as-is on EPEL 10 because of the openssl ENGINE removal in RHEL 10.

There's other work around crypto stuff upstream so it's possible this might move to mBedTLS.

U-Boot images is LOT of work, can you provide a link to the platforms the hyperscale SIG are pursuing, mailing list discussions etc? How is the kernel work done to support the platforms? Is it the RHEL c10s kernel or is there another kernel as there's a LOT of devices that aren't supported in the RHEL kernel so how much sense does it make to build all the current Fedora ones?

Thanks Peter. For Hyperscale specifically, we need apple_m1; for the kernel we're going to use a tree based on https://gitlab.com/fedora-asahi/kernel-asahi (which itself is based on ARK), at least until more of this gets upstreamed. I also know the Alternative Images SIG is interested in Raspberry Pi support (especially rpi4), so enabling those targets would be useful as well. Finally, there's some initial discussions around the new Snapdragon platforms (Thinkpad x13s and the new x1e systems), but nothing concrete there yet.

> Snapdragon platforms (Thinkpad x13s and the new x1e systems), but nothing concrete there yet.

They're not supported in U-Boot, you use the vendor firmware, I am writing this on an X13s.

Please, as requested, point to where this is all documented or the discussions are happening.

This work has mostly been discussed in Matrix so far, specifically in #centos-hyperscale:fedoraproject.org (for Hyperscale) and #centos-alt-images:fedora.im (for AltImages). It also came up recently in the latest AltImages meeting (see https://meetbot.fedoraproject.org/meeting-1_matrix_fedoraproject-org/2024-10-10/altimages.2024-10-10-19.01.log.html); it also came up multiple times in Hyperscale meetings but I don't have the logs for those handy right now. For Apple Silicon specifically I have a copr for staging and experimentation at https://copr.fedorainfracloud.org/coprs/dcavalca/asahi-centos-stream but it's definitely not in a usable state yet. We also have tickets tracking other components needed (e.g. https://bugzilla.redhat.com/show_bug.cgi?id=2315498 for m1n1 and its dependencies). For the Snapdragon platforms as I mentioned there's nothing concrete yet, it was just something people had brought up before as an area of interest, I haven't personally looked into that yet.

So for RPi4 and apple_m1 there's no dependency on trusted-firmwae.a so is that dep still needed, it can always be added later if an request for an explicit platform that needs it.

Cool, thanks for checking. I'll drop that then for now.

I haven't forgotten this, have been aligning a few things with upstream, should be done shortly, likely the 2025.04 release.

Looks like 2025.04 is out now, any update on this? Thanks!

Yep, still working through some bugs in .04, will push that build once I have those sorted.