> Date: Tue, 02 Dec 2025 21:01:26 +0100 > From: Heinrich Schuchardt <[email protected]> > > Am 2. Dezember 2025 20:46:21 MEZ schrieb Mark Kettenis > <[email protected]>: > >> Date: Tue, 2 Dec 2025 12:52:22 -0600 > >> From: Tom Rini <[email protected]> > >> > >> 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 <[email protected]> > >> > > >> > 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 <[email protected]> > >> > > 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 <[email protected]> > >> > > > >> > > 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/[email protected]/ > >> > > >> > 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. > >
