Dropping macOS and Windows host tool builds and support in U-Boot

[Peter Robinson]

On Thu, 11 Dec 2025 at 13:36, Simon Glass <sjg at chromium.org> wrote:
>
> Hi Tom,
>
> On Tue, 2 Dec 2025 at 14:21, Tom Rini <trini at konsulko.com> wrote:
> >
> > On Tue, Dec 02, 2025 at 12:24:03PM -0600, Tom Rini wrote:
> >
> > > Hey all,
> > >
> > > I am wondering if at this point in time, anyone still builds our host
> > > tools (fw_printenv / fw_getenv, a few others) to run on macOS or
> > > Windows, natively.
> > >
> > > I ask for two reasons. The first of which is that a reason we still have
> > > to support Azure (despite its slowness) for CI is it's where we have
> > > macOS and Windows hosts. But at this point in time there's so many ways
> > > to have Linux userspace running on Windows or macOS that I don't know
> > > that there's any value to these builds.
> > >
> > > The second reason is more macOS specific and is that with:
> > >
> > > commit 8fbcc0e0e839a8e25f636c76e59311033d3817b5
> > > Author: Marek Vasut <marek.vasut+renesas at mailbox.org>
> > > Date:   Thu Nov 13 12:54:51 2025 +0100
> > >
> > >     boot: Assure FDT is always at 8-byte aligned address
> > >
> > >     The fitImage may contain FDT at 4-byte aligned address, because alignment
> > >     of DT tags is 4 bytes. However, libfdt and also Linux expects DT to be at
> > >     8-byte aligned address. Make sure that the DTs embedded in fitImages are
> > >     always used from 8-byte aligned addresses. In case the DT is decompressed,
> > >     make sure the target buffer is 8-byte aligned. In case the DT is only
> > >     loaded, make sure the target buffer is 8-byte aligned too.
> > >
> > >     Signed-off-by: Marek Vasut <marek.vasut+renesas at mailbox.org>
> > >
> > > Which does things we must do, we now don't build on macOS. Why? As best
> > > I can tell (and for a general purpose OS, is a good call), memalign(..)
> > > doesn't exist and you need to use posix_memalign, a not drop-in
> > > replacement. We could spend some time reworking the code here for that,
> > > but for now I've instead gone with this workaround so that CI can
> > > continue:
> > > https://lore.kernel.org/u-boot/20251202162250.2613085-1-trini@konsulko.com/
> > >
> > > But longer term, unless people say they need and use these tools, I'm
> > > inclined to remove them from CI and remove this workaround, for the
> > > v2026.04 release.
> >
> > We have solved this specific problem without a large work-around.
> > However, the more general question remains. Does anyone use these tools
> > on Windows / macOS?
>
> There are a lot of Mac users, at least.

Where do you get that data? Are they a lot of Mac users building
natively on MacOS or in Linux on Mac.

MacOS 26 adds support for native containers running Linux, I think
that this is likely the better way for us to support those tools on
Mac.

> For Windows, mkimage is used by the EDK2 people (Universal Payload).
> It might be some years before they switch to Linux. Even if Microsoft
> decides to switch out their kernel, I suspect the 'power shell' will
> still remain.

How is mkimage used by EDK2 and in what way is it used on Windows, can
you provide a link to documentation?

Windows has WSL2, which has been around longer than the Mac equivalent.

Can you explain the value that native build support brings over
supporting Linux in those subsystems on those OSes?

Peter