On Mon Dec 22, 2025 at 12:13:25AM +0000, Klemens Nanni wrote: > 21.12.2025 20:42, Klemens Nanni пишет: > > 21.12.2025 15:42, Jeremie Courreges-Anglas пишет: > >> On Sat, Dec 13, 2025 at 05:07:39PM +0000, Klemens Nanni wrote: > >>> 22.11.2025 14:48, Klemens Nanni пишет: > >>>> The port itself supports any architecture, but builds only amd64 and > >>>> arm64 > >>>> as others have not been tested (riscv64 and loongson might be of > >>>> interest). > >>>> > >>>> It requires GNU tools incl. compiler and linker, we have everything > >>>> except > >>>> - ports@ "binutils: enable ld.bfd ?" > >>>> > >>>> Once all knobs and found and set properly, GNU make compiles all files > >>>> always compiles all files (see https://dox.ipxe.org/ifdef_harmful.html) > >>>> and then links targets according to config. > >>>> > >>>> I want to be able to serve images for several architectures from a single > >>>> netboot server and avoid cross compilation, so this port uses > >>>> MACHINE_ARCH > >>>> in PKGNAME and sets PKG_ARCH=*; per-arch files don't conflict and even > >>>> per-platform (e.g. EFI or BIOS) files seem to end up with unique tuples > >>>> of what upstream calls drivers and extensions, see Files below as well as > >>>> https://ipxe.org/appnote/buildtargets. > >>>> > >>>> Then I can serve, e.g. ipxe.efi over TFTP or HTTP and further do whatever > >>>> on the clients, for example through autoexec.ipxe, which it tries to load > >>>> from the server by default. > >>> Here's an updated and tidied version. As with binutils, I left support > >>> and > >>> merely omitted/commented arm64 in ONLY_FOR_ARCHS. > >>> > >>> The port is available in openbsd-wip. > >>> > >>> Feedback? OK to import once ports@ "binutils: enable ld.bfd ?" is settled? > >> > >> Not ok as is. Quoting my latest reply to the ld.bfd thread: > >> |I still think that's the wrong way to go. I see no point tying our > >> |hands with building standalone programs using a generic "native > >> |ports-gcc" + "native devel/binutils" toolchain, when all that is > >> |needed is a freestanding toolchain. > >> | > >> |Who will fix net/ipxe when it's on the way of a ports-gcc or devel/gas > >> |update? On this matter: you've explicitely made the devel/gas and > >> |devel/binutils ports tightly bound, making it impossible to update > >> |devel/gas without updating devel/binutils. Someone updating devel/gas > >> |would then feel forced to check that the new devel/binutils version > >> |can still build net/ipxe on all architectures where it is enabled. > >> | > >> |All of this disappears if you use cross-compiling with a stable > >> |toolchain like u-boot does. > >> > >> The diff below is a *PoC* to build ipxe for aarch64 using > >> devel/arm-none-eabi/*,aarch64, allowing us to cross-compile from amd64 > >> and others if desired (tested, build succeeds then fails at pcbios, > >> but this is only a PoC). _I haven't tested the resulting aarch64 > >> standalone executables_. > > Right, i missed arm-none-eabi/gcc which has ld.bfd, thanks. > > BIOS on arm64 is not supported, so it cannot build. > > > > amd64 from my new port tarball boots fine, arm64 gets tested later. > > > >> Obviously such a freestanding toolchain doesn't exist for i386/x86_64, > >> so we'd have to add that first if we wanted to go on the same path for > >> all architectures. Since I don't have a need for such a toolchain, > >> I'm not volunteering for the job. > > > > amd64 can build natively and cross every other architecture. > > > > I did that now through ONLY_FOR_ARCHS=amd64 FLAVORS=aarch64 FLAVOR= > > together with proper Makefile bits such that new architectures can be > > added for native- and/or cross-builds (after build and boot tests). > > > fixed port after rereading upstream docs and code: > - do not build arm64 .iso, fetched isolinux is amd64-only > - pass CROSS and drop ARCH as per "Cross Compile" > https://ipxe.org/appnote/buildtargets > - replace do-build with ALL_TARGET > - turn do-install into single pax command > - tidy up makefile, less variables/ifs/loops > > to illustrate, this yields ipxe-arm32-1.21.1pl1152.tgz: > > |@@ -46,3 +46,3 @@ MAINTAINER = Klemens Nanni <[email protected]> > | # Cross-compilation architectures. > |-FLAVORS = aarch64 > |+FLAVORS = aarch64 arm > | FLAVOR ?= # native build > |@@ -61,4 +61,4 @@ BUILD_DEPENDS = > devel/arm-none-eabi/binutils,${FLAVOR} \ > | devel/arm-none-eabi/gcc,${FLAVOR} > |-IPXE_ARCH = ${FLAVOR:aarch64=arm64} > |-CROSS = ${FLAVOR}-none-${FLAVOR:aarch64=elf}- > |+IPXE_ARCH = ${FLAVOR:aarch64=arm64:arm=arm32} > |+CROSS = ${FLAVOR}-none-${FLAVOR:aarch64=elf:arm=eabi}- > | .endif > > it's in the port, but with arm commented in FLAVORS (until someone needs it). > > images work for me and update-plist changes nothing. > > > > > Feedback? OK?
I have no use for this port, and it's too far away to be a simple port. All in all, it compiles, so if you're looking for a port to import, ok rsadowski. You might want to remove the non-standard top-level category: firmware. Cheers, Rafael
