https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=299004 looks to be a report of this change leading to passing the clang-specific command line option to gcc/binutils's ld ( /usr/local/bin/ld ), breaking more official port/package builds.

I tested this (with D59827) in a personal kernel build to format a DC P4800 Optane ("INTEL SSDPE21K015TA E2010650") to be 4096 based (no meta data) with "sysctl dev.nvme.0.format_timeout_period=1800" (so: 30 min) and it finished fine in a little under 23 minutes, waiting as it should.

Seems odd to me that this loader.efi / GOP related change is in the middle of a stack of nmve related updates: it looks completely independent. Did the wrong change show up in the stack?

I'm going to note one possibly unintended consequence of earlier test activities. It happened on the amd64 system used in testing.

1.20260521 did not actually fix the aarch64 RPi4B "green LED 7 short flashes (Kernel image not found)" issue that happens when GPT is involved on microsd cards used in the built-in slot, GPT used as in the test image that I was given for use in my testing.

In D58197#1361279, @jlduran wrote:

In D58197#1361256, @markmi_dsl-only.net wrote:

In D58197#1361225, @jlduran wrote:

In D58197#1361219, @markmi_dsl-only.net wrote:

. . .

. . .

To put is simple:

# gpart show
=>      40  31116208  sdda0  GPT  (15G)
        40      8152         - free -  (4.0M)
      8192   1024000      1  ms-basic-data  (500M)
   1032192    532480      2  efi  (260M)
   1564672  29551576      3  freebsd-zfs  (14G)

# sysctl hw.fdt
hw.fdt.serial-number: 100000009df81ae6
hw.fdt.compatible: raspberrypi,4-model-b brcm,bcm2711
hw.fdt.model: Raspberry Pi 4 Model B Rev 1.4

Without the update in this revision, this was not possible.

Much older RPI* files (and, likely, u-boot and such) used with an official pkgbase distribution of main from a while back:

# sysctl hw.fdt
hw.fdt.serial-number: 10000000c740af3c
hw.fdt.compatible: raspberrypi,4-model-b brcm,bcm2711
hw.fdt.model: Raspberry Pi 4 Model B Rev 1.5
# uname -apKU
FreeBSD aarch64-main-PkgBase 16.0-CURRENT FreeBSD 16.0-CURRENT main-n287813-a77257d60058 GENERIC-NODEBUG arm64 aarch64 1600019 1600019
aarch64-main-PkgBase aarch64  1600019 1600019 # ls -lodTt /boot/efi/*
drwxr-xr-x  1 root wheel -        8192 Oct 24 12:48:26 2025 /boot/efi/dtb
-rwxr-xr-x  1 root wheel uarch       0 Feb 20 02:29:58 2024 /boot/efi/timeout
-rwxr-xr-x  1 root wheel uarch  623400 Jan 24 09:59:48 2024 /boot/efi/u-boot.bin
drwxr-xr-x  1 root wheel -        8192 Jan 11 09:39:34 2024 /boot/efi/overlays
drwxr-xr-x  1 root wheel -        8192 Jan 11 09:39:22 2024 /boot/efi/EFI
-rwxr-xr-x  1 root wheel uarch    5888 Jan 11 05:43:38 2024 /boot/efi/armstub8-gic.bin
-rwxr-xr-x  1 root wheel uarch    5888 Jan 11 05:43:38 2024 /boot/efi/armstub8.bin
-rwxr-xr-x  1 root wheel uarch     240 Jan 11 05:34:58 2024 /boot/efi/README
-rwxr-xr-x  1 root wheel uarch    1480 Jan  4 11:50:04 2024 /boot/efi/config.txt
-rwxr-xr-x  1 root wheel uarch    1594 Apr  5 11:32:16 2023 /boot/efi/LICENCE.broadcom
-rwxr-xr-x  1 root wheel uarch   30390 Apr  5 11:32:16 2023 /boot/efi/bcm2710-rpi-2-b.dtb
-rwxr-xr-x  1 root wheel uarch   32753 Apr  5 11:32:16 2023 /boot/efi/bcm2710-rpi-3-b-plus.dtb
-rwxr-xr-x  1 root wheel uarch   32142 Apr  5 11:32:16 2023 /boot/efi/bcm2710-rpi-3-b.dtb
-rwxr-xr-x  1 root wheel uarch   30285 Apr  5 11:32:16 2023 /boot/efi/bcm2710-rpi-cm3.dtb
-rwxr-xr-x  1 root wheel uarch   52593 Apr  5 11:32:16 2023 /boot/efi/bcm2711-rpi-4-b.dtb
-rwxr-xr-x  1 root wheel uarch   52476 Apr  5 11:32:16 2023 /boot/efi/bootcode.bin
-rwxr-xr-x  1 root wheel uarch    7266 Apr  5 11:32:16 2023 /boot/efi/fixup.dat
-rwxr-xr-x  1 root wheel uarch    5399 Apr  5 11:32:16 2023 /boot/efi/fixup4.dat
-rwxr-xr-x  1 root wheel uarch    3173 Apr  5 11:32:16 2023 /boot/efi/fixup4cd.dat
-rwxr-xr-x  1 root wheel uarch    8381 Apr  5 11:32:16 2023 /boot/efi/fixup4db.dat
-rwxr-xr-x  1 root wheel uarch    8387 Apr  5 11:32:16 2023 /boot/efi/fixup4x.dat
-rwxr-xr-x  1 root wheel uarch    3173 Apr  5 11:32:16 2023 /boot/efi/fixup_cd.dat
-rwxr-xr-x  1 root wheel uarch   10230 Apr  5 11:32:16 2023 /boot/efi/fixup_db.dat
-rwxr-xr-x  1 root wheel uarch   10228 Apr  5 11:32:16 2023 /boot/efi/fixup_x.dat
-rwxr-xr-x  1 root wheel uarch 2975680 Apr  5 11:32:16 2023 /boot/efi/start.elf
-rwxr-xr-x  1 root wheel uarch 2251392 Apr  5 11:32:16 2023 /boot/efi/start4.elf
-rwxr-xr-x  1 root wheel uarch  805756 Apr  5 11:32:16 2023 /boot/efi/start4cd.elf
-rwxr-xr-x  1 root wheel uarch 3747688 Apr  5 11:32:16 2023 /boot/efi/start4db.elf
-rwxr-xr-x  1 root wheel uarch 2998888 Apr  5 11:32:16 2023 /boot/efi/start4x.elf
-rwxr-xr-x  1 root wheel uarch  805756 Apr  5 11:32:16 2023 /boot/efi/start_cd.elf
-rwxr-xr-x  1 root wheel uarch 4819624 Apr  5 11:32:16 2023 /boot/efi/start_db.elf
-rwxr-xr-x  1 root wheel uarch 3722504 Apr  5 11:32:16 2023 /boot/efi/start_x.elf
-rwxr-xr-x  1 root wheel uarch      88 Dec 31 23:00:00 1979 /boot/efi/ubootefi.var
# gpart show 
=>        34  1875384941  da0  GPT  (894G)
          34       32734       - free -  (16M)
       32768      501760    1  efi  (245M)
      534528    20971520    2  freebsd-swap  (10G)
    21506048    29360128    3  freebsd-swap  (14G)
    50866176    33554432    4  freebsd-swap  (16G)
    84420608    67108864    5  freebsd-swap  (32G)
   151529472    96468992    6  freebsd-swap  (46G)
   247998464   268435456    7  freebsd-swap  (128G)
   516433920     7340032    8  freebsd-swap  (3.5G)
   523773952    13631488   10  freebsd-swap  (6.5G)
   537405440  1337979528    9  freebsd-ufs  (638G)
  1875384968           7       - free -  (3.5K)
# gpart show -p
=>        34  1875384941     da0  GPT  (894G)
          34       32734          - free -  (16M)
       32768      501760   da0p1  efi  (245M)
      534528    20971520   da0p2  freebsd-swap  (10G)
    21506048    29360128   da0p3  freebsd-swap  (14G)
    50866176    33554432   da0p4  freebsd-swap  (16G)
    84420608    67108864   da0p5  freebsd-swap  (32G)
   151529472    96468992   da0p6  freebsd-swap  (46G)
   247998464   268435456   da0p7  freebsd-swap  (128G)
   516433920     7340032   da0p8  freebsd-swap  (3.5G)
   523773952    13631488  da0p10  freebsd-swap  (6.5G)
   537405440  1337979528   da0p9  freebsd-ufs  (638G)
  1875384968           7          - free -  (3.5K)
# gpart show -pl
=>        34  1875384941     da0  GPT  (894G)
          34       32734          - free -  (16M)
       32768      501760   da0p1  PkgBaseEFI  (245M)
      534528    20971520   da0p2  PkgBaseSwp10  (10G)
    21506048    29360128   da0p3  PkgBaseSwp14  (14G)
    50866176    33554432   da0p4  PkgBaseSwp16  (16G)
    84420608    67108864   da0p5  PkgBaseSwp32  (32G)
   151529472    96468992   da0p6  PkgBaseSwp46  (46G)
   247998464   268435456   da0p7  PkgBaseSwp128  (128G)
   516433920     7340032   da0p8  PkgBaseSwp3p5  (3.5G)
   523773952    13631488  da0p10  PkgBaseSwp6p5  (6.5G)
   537405440  1337979528   da0p9  PkgBaseUFS  (638G)
  1875384968           7          - free -  (3.5K)

Note: There are lots of files not used/needed by the RPi4 because this same media boots other systems: not minimal. (I did not show subdirectory contents above: shorter.) My config.txt is customized. My use of timeout is because I have some media that need the extra time and all the RPI* capable boot media have the file.

In D58197#1361225, @jlduran wrote:

In D58197#1361219, @markmi_dsl-only.net wrote:

. . .

Thanks for taking a closer look at this. To clarify, are you suggesting a revert, or is this primarily a request to make the commit message more explicitly descriptive of what was tested?

The RPi4 variants and RPi5 variants have the firmware in the EEPROM, not on external media. (*.dtb are still on external media.)

I'll note that efi_bootloader_update.sh could be considered to be of direct use for folks using pkgbase: pkgbase does not deal with updating the FreeBSD loaders in the ESP.

Something on a related github page: "MBR (non-GPT) disks Not supported (BIOS-only, legacy)"

Note: my examples show things that are possible for installations based on examples I have (or had). They may be all "no plan/reason to support for freebsd-update for EFI updating". If true, I'm fine with that. At least such likely would end up being explicitly indicated now.

Is it deliberate that there is coverage of armv7 and its bootarm.efi ?

As I understand it, 14.5-RELEASE is based on llvm21 and, so, will likely have the aarch64 erratum 843419 problem as stands.

Jenkins shows aarch64 build failures since: https://ci.freebsd.org/job/FreeBSD-main-aarch64-build/35832/ :

sys/compat/linux/linux_emul.h:58:49: error: declaration of
 'struct image_args' will not be visible outside of this function [-Werror,-Wvisibility]
   58 | int     linux_common_execve(struct thread *, struct image_args*);
      |                                                     ^
1 error generated.

In D58495#1345218, @ivy wrote:

In D58495#1345206, @markmi_dsl-only.net wrote:

A note on some terminology in the summary (and for the related commits):

are you going to follow me around everywhere on the Internet to post this comment?

i'm well aware of the technical difference between "const pointer to mutable T" and "mutable pointer to const T", but in colloquial language, everyone understands what "const pointer" means in this context and there is no need to "clarify" it with pointless nitpicking.

A note on some terminology in the summary (and for the related commits):

This is apparently making some port-package build fail with:

Does:
. . .
STANDARDS

The stat() and fstat() system calls are expected to conform to IEEE Std
1003.1-1990 (“POSIX.1”).  The fstatat() system call follows The Open
Group Extended API Set 2 specification.

. . .

In D57721#1333711, @chris.longros_gmail.com wrote:

So will this commit land to main ? :)

Because I recently discovered that the FreeBSD kernel's rman usage again allows the RPi4's to be booted via the EDK2, I again have this kind of patched code for building my personal kernel builds. So I'm again able to have contexts without the 3 GiByte limitation, such as on a C0 stepping 8 GiByte RPi4 actually having the 8 GiBytes for use for an EDK2 based boot.

I will note that this "fixed" the ability to boot RPi4 via its EDK2. Instead of the prior panic, in this order the overlap testing ends up doing (I explain the result being okay afterwards):

rman_reserve_resource: <I/O memory addresses> request: [0x7e20c000, 0x7e20c027], length 0x28, flags 0, device (null)
rman_reserve_resource: trying 0x3fffff <0x7e20c000,0x27>
rman_reserve_resource: tried 0x3fffff <0x7e20c000,0x27>
rman_reserve_resource: tried 0x2ebfffff <0x7e20c000,0x27>
rman_reserve_resource: tried 0x3017dfff <0x7e20c000,0x27>
rman_reserve_resource: tried 0x37fbffff <0x7e20c000,0x27>
rman_reserve_resource: tried 0x37feffff <0x7e20c000,0x27>
rman_reserve_resource: tried 0x380dffff <0x7e20c000,0x27>
rman_reserve_resource: tried 0x3813ffff <0x7e20c000,0x27>
rman_reserve_resource: tried 0x3851ffff <0x7e20c000,0x27>
rman_reserve_resource: tried 0x3875ffff <0x7e20c000,0x27>
rman_reserve_resource: tried 0x3877ffff <0x7e20c000,0x27>
rman_reserve_resource: tried 0x387bffff <0x7e20c000,0x27>
rman_reserve_resource: tried 0x38960fff <0x7e20c000,0x27>
rman_reserve_resource: tried 0x38963fff <0x7e20c000,0x27>
rman_reserve_resource: tried 0x3897ffff <0x7e20c000,0x27>
rman_reserve_resource: tried 0x38980fff <0x7e20c000,0x27>
rman_reserve_resource: tried 0x38eaafff <0x7e20c000,0x27>
rman_reserve_resource: tried 0x38eabfff <0x7e20c000,0x27>
rman_reserve_resource: tried 0x39bdffff <0x7e20c000,0x27>
rman_reserve_resource: tried 0x39fbffff <0x7e20c000,0x27>
rman_reserve_resource: tried 0x3b3fffff <0x7e20c000,0x27>
rman_reserve_resource: tried 0x4024afff <0x7e20c000,0x27>
considering [0x4024b000, 0xbfffffff]
region is allocated
considering [0xc0000000, 0xfd57ffff]
s->r_start (0xc0000000) + count - 1> end (0x7e20c027)
no unshared regions found

The RPi4's have DMA engines (or other such) that do not use the aarch64 address space and [0x7e20c000, 0x7e20c027] with length 0x28 (which is for PWM0) is one of them and is used only with those DMA engines (or whatever). The overlap with [0x4024b000, 0xbfffffff] for ram0 is actually irrelevant. But in the old ordering it was treated as relevant and reported the overlap via a panic. As stands with the new order, the overlap is the indication of the address space not being the aarch64 address space and allowing the (fake) overlap is the right thing to do.

In the kind of context that I originally reported based on:

It was determined that zpool status and zfs list are not the commands used in the original context. Instead:

[I'm removing the note about the EDK2 _CRS issue after discovering that the FreeBSD kernel no longer classifies a conflict because it has enough context to identify ram0 vs. (null) vs. gic0 (as in its debug messages) as distinct, none conflicting contexts. It no longer panics for a conflict detection for RPi4 booting via EDK2.]

What is the relationship of this type of change to use of ${PREFIX} when ports install themselves and it is not the /usr/local default value? (There is also a linux compatibility related standard default for PREFIX and folks can specify things like /opt .) There was a later change to use /usr/local/ when LOCALBASE was undefined.

https://lists.freebsd.org/archives/freebsd-current/2026-April/010130.html ("Re: panic: assertion failed in iflib_txq_drain()") points to the commit for this as reverting it being sufficient to avoid the new panics.

In D56139#1284436, @kib wrote:

In D56139#1284163, @markmi_dsl-only.net wrote:

. . .

I have no idea why it grown this way, and what was the rationale of the arch maintainers when it did.
I am only interested in re-checking that my patch does not change the current state there. If somebody do it, I would appreciate.

The status of fegetexcept, feenableexcept, and fedisableexcept and their relationship to __BSD_VISIBLE seems to be rather variable. Some of that variability may be incorrect and other parts expected. I just note the variability itself. A quick look seemed to show:

In D49967#1237244, @markmi_dsl-only.net wrote:

It turns out that this change looks to have notable port-package build time consequences for at least aarch64 on ampere[123] and on, for example, the Microsoft Dev Kit 2023 that I have access to.
. . .

That said, it is not necessarily a 'release.conf' issue, but the issue that 'src/release/Makefile' does not have an 'ftp' equivalent target for creating the .txz distribution sets for armv6,armv7. And after poking around at release/Makefile*, I

Ah, I just realized that the 'ftp' distribution sets are created as a part of the '{bootonly,disc1,dvd1}.iso' targets. So, that particular mystery is solved.

In D55255#1263686, @mmel wrote:

Sorry for my poorly formulated question.
The hidden but not weak aeabi_unwind_cpp_pr* symbols means that we don't expect or want to process exceptions generated in libsys because the unwinder always ends in an abort/trap. So why don't we simply compile libsys with -fno-exceptions?
. . .

Well, folks that do not use poudriere(-devel) have been locally putting back ar=${AR} in some places so that their make/Makefile or portmaster style of working can find the right ar. An example is:

Looking at the history, a fix in this area was tried 13 years ago and reverted for breaking devstat use. 12 years ago the below type of fix was committed instead and then reverted, sighting lessons learned from the prior attempt.

I am getting signal 11 core dumps on armv7 for "gpart show". i386 and 32-bit powerpc would likely also have problems.

It turns out that this change looks to have notable port-package build time consequences for at least aarch64 on ampere[123] and on, for example, the Microsoft Dev Kit 2023 that I have access to.

. . .

@mmel you have been testing on ARMv7, correct?

. . . testing on ARMv7, correct? Also, you have the option enabled in jemalloc to write junk in the freed pages, correct? And, jemalloc is complaining upon recycling the memory that it didn't find the expected junk values in the memory?

"efi" vs. "eficom"? The limited contexts where comconsole should be used there days (does it presume x86/i368?)?

Yea. Another paragraph from that part of that man pages says:

man 8 loader_simp reports:

See also:

Looking at the history: armeb support ended with 11.4 and was removed after that.

In an experiment on aarch64 based on changing poudriere-devel to use FreeBSD-set-minimal-jail FreeBSD-set-devel FreeBSD-set-lib32 (still leaving FreeBSD-src-sys separate), I got a:

[00:00:01] Setting schg on jail base paths
chflags: /usr/local/poudriere/data/.m/main-min-devel-lib32-aarch64-default/ref/boot/modules: No such file or directory
chflags: /usr/local/poudriere/data/.m/main-min-devel-lib32-aarch64-default/ref/boot/firmware: No such file or directory
Error: (84516) /usr/local/share/poudriere/bulk.sh:jail_start:255: set -e error: status = 1

Mostly that is of interest for noting boot/firmware can also be missing.

I wondered if "bsdinstall --jail" for base-jail would establish materials in the jail that would be associated with: "/set tags=package=bootloader". So I tried it with the old BSD-root.dist in place and looking after the creation:

# ls -loaT jail-pkgbase-base-jail/boot/
total 8
drwxr-xr-x   2 root wheel - 512 Oct  7 10:38:43 2025 .
drwxr-xr-x  17 root wheel - 512 Oct  7 10:38:43 2025 ..

(So boot/ showed up but nothing inside it did for use of the old BSD.root.dist . That does not seem to be from interpreting/applying BSD.root.dist .)

In D52621#1202250, @portmaster_BSDforge.com wrote:

. . . It appears we'll reach nearly 30 packages if we continue to split
things up. . . .

Note: This lead to a sizable increase in what pkgbase'd poudriere-devel jail creations include, including a full copy of /usr/src/ ( not just sys/ ) and more.

This broke building rust 1.88 via poudriere-devel :

  = note: ld: error: undefined symbol: readdir_r
          >>> referenced by std.d8968a002452916e-cgu.07
          >>>               std-de94806a57729acc.std.d8968a002452916e-cgu.07.rcgu.o:(std::sys::fs::unix::remove_dir_impl::remove_dir_all_recursive::hbe1160129d2c5f7c) in archive /wrkdirs/usr/ports/lan
g/rust/work/bootstrap/lib/rustlib/x86_64-unknown-freebsd/lib/libstd-de94806a57729acc.rlib
          >>> did you mean: readdir_r@FBSD_1.5
          >>> defined in: /lib/libc.so.7
          cc: error: linker command failed with exit code 1 (use -v to see invocation)

In D52412#1197023, @ivy wrote:

add devmatch to minimal

the -dtb package should be in minimal when building on aarch64, see the change to release/packages/ucl/dtb-all.ucl in this diff. you can test this by building a package set with this diff applied, then looking at the "set" annotation in pkg info FreeBSD-dtb.

Just for reference, from looking at my live aarch64 and amd64 environments, "+" lines for unique to amd64 and "-" lines for unique to aarch64, but not based on more recent adjustments:

this change will not be MFC'd to stable/14.

In D52412#1196934, @ivy wrote:

for reference, here's a list of every package and the set it's included in: https://people.freebsd.org/~ivy/tmp/pkgsets.txt -- but note that sets might pull in more packages than listed here due to explicit or library dependencies.

I'd argue a little harder for MALLOC_PRODUCTION staying as-is since that's more broadly applicable. Though, we have src.conf knobs for both of these exactly so that folks can just flip them easily for their own use-cases without having to constantly argue defaults, and the current defaults reflect generally what we do with debug features in the kernel (as you noted).

Not finding a documentation for the likes of ilog2_long, I gather that (trying to reference mostly mathematics, not programming language implementation details):

In any case, beyond the hz topic, there's also that people will inevitably ask about kern.vm_guest not set whereas running in a virtual machine, and we have already set a precedent with VM_GUEST_BHYVE, VM_GUEST_PARALLELS and VM_GUEST_NVMM (which are only cosmetic but for hz). So I'd rather for now make sure that kern.vm_guest is not none under QEMU, even if in the end this is essentially cosmetic. Having a special value seems slightly better, but VM_GUEST_VM (generic) could also work.

virtualbox guest tools, I think, may exit doing nothing if not running under virtual box. HyperV has special code activated. I think xen does too. I don't think those two have useland tools depending on it

Ignoring kern.hz : Is there any other reason that it is important for FreeBSD to have the explicit indication that it is running under a VM?

Here is from amd64 Parallels on amd64 macOS:

For reference, taken from my list report for aarch64 Parallels on macOS. I'll likely separately submit one from amd64 Parallels on macOS as well.

It used to matter a lot so we'd get hz right, but that doesn't matter anymore (though we bogusly still do it sometimes). Hz hasn't mattered since mav@ made the kernel tickless.

I was under the impression Apple's VM in this case was parallel's, and UTM just provided a fancy / different GUI for it.

In D49084#1119093, @imp wrote:

So there are multiple ways to run under qemu: system emulation, kvm, nvmm, and hvf. These overlap with others in the list (parallels uses hvf also).

UTM on macOS can use either QEMU or Apple's VM as I understand. But I do not know of FreeBSD is actually operable with Apple's VM in use. If operable, Apple's VM likely leads to another new name to test for? (This might be another example of: Treat FreeBSD as-if it was a Linux variant, like I did for Parallels to get it basically working there. I then disabled virtio_gpu via /boot/device.hints so that efifb would be used, which worked fine for my purposes.)

Probably does not match Parallels running on amd64 either, as the string seem more similar to what is contained in 'smbios.planar.product' ("Virtual Platform", and not "Virtual Machine), which we don't use.

Activity on discord by "Vince (darkain)" for FreeBSD kernel is reporting the following still use hardware this driver supports: PowerEdge servers.
'its literally the mezzanine NIC common in Dell PowerEdge servers'

Basic 14.2-RELEASE testing and main testing [so: 15 as stands] and 13.4-RELEASE testing might be appropriate?

The release referenced was fairly quickly replaced. Sometimes this indicates problematical prior releases. Most recent to oldest:

Is pkg-static use appropriate because of things like when llibmd.so.6 -> libmd.so.7 happened? Both dependencies ended up involved, one indirectly via /usr/lib/liblzma.so.5 , stopping pkg from being able to run.

Wondering somewhat beyond the specific changes here to the original commit . . . (I noticed by considering how I'd test the updated script.)

I'll note that upstream 1.20230405 had bcm2711-rpi-cm4s.dtb but the port did not. But if that was deliberate vs. not I cannot tell.

I also commented on the addition of lots of unsupported RPi5 / bcm2712 related files. As I understand, historically any unsupported RPi*'s normally have their files omitted in this port.

So far as I know, any notable difference is just from different rpi_*_defconfig selections: