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

Mark Kettenis mark.kettenis at xs4all.nl
Tue Dec 2 21:19:41 CET 2025


> Date: Tue, 02 Dec 2025 21:01:26 +0100
> From: Heinrich Schuchardt <xypron.glpk at gmx.de>
> 
> Am 2. Dezember 2025 20:46:21 MEZ schrieb Mark Kettenis <mark.kettenis at xs4all.nl>:
> >> Date: Tue, 2 Dec 2025 12:52:22 -0600
> >> From: Tom Rini <trini at konsulko.com>
> >> 
> >> On Tue, Dec 02, 2025 at 07:49:07PM +0100, Mark Kettenis wrote:
> >> > > Date: Tue, 2 Dec 2025 12:24:03 -0600
> >> > > From: Tom Rini <trini at konsulko.com>
> >> > 
> >> > Hi Tom,
> >> > 
> >> > > 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/
> >> > 
> >> > Are you sure about this?
> >> > 
> >> > The code in boot/image-fdt.c is part of U-Boot itself, not the host
> >> > tools.  As such it should be irrelevant whether the host OS provides
> >> > memalign() or not; U-Boot provides its own implementation.
> >> 
> >> We use parts of this code as-is (and some other less obvious files) when
> >> building host tools.
> >> 
> >> > OpenBSD doesn't have memalign() either.  But I can still build the
> >> > targets I care about on OpenBSD.
> 
> We require C11 for building U-Boot. C11 defines function aligned_alloc(). If we add that function in our U-Boot library we can rid of the #ifdef in Tom's patch.

That should work for OpenBSD.  And almost certainly for the other BSDs as well.

> >> > 
> >> > Or is this about sandbox?  Did sandbox ever work on macOS?
> >> 
> >> It's about "tools-only" build target, but also I suspect that if you try
> >> the next branch right now it'll also fail and we'll need to figure
> >> something out.
> >
> >Ah, it is only on the next branch.  Yes
> >
> >  In file included from tools/generated/boot/image-fit.c:1:
> >  In file included from ./tools/../boot/image-fit.c:38:
> >  include/malloc.h:824:20: error: conflicting types for 'sbrk'
> >    824 | extern Void_t*     sbrk(ptrdiff_t);
> >        |                    ^
> >  /usr/include/unistd.h:449:7: note: previous declaration is here
> >    449 | void    *sbrk(int);
> >        |          ^
> >  1 error generated.
> >
> >Which points out another issue with sharing code between U-Boot itself
> >and the host tools this way.
> 
> 


More information about the U-Boot-Custodians mailing list