"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:

The official FreeBSD builds for aarch64 RPi* (including the for the RPi4Bs) use: /usr/ports/sysutils/u-boot-rpi-arm64/
instead of using /usr/ports/sysutils/u-boot-rpi4/ . As stands that includes the likes of:

It might be appropriate for sbin/bectl/bectl.8 to now explicitly mention the default implicit promotion in its activate description. As I remember, the historical text was not explicit at all about what to expect related to what promotion controls. But, with the change, both alternatives become possibilities.

This was a continuation/completion of https://reviews.freebsd.org/D40903 which reported:

Any reason to not use "gpart show -p nda1" for the style of command? It avoids needing to know the naming correspondence.

In D46239#1055922, @brooks wrote:

I'd be happy to add a --threads=1 patch since that seems to be useful. I'm not sure if we should do it for all 32-bit platforms or make it an option that defaults to enabled on 32-bit platforms.

The native armv7, 2 GiByte, Cortex-A7, OrangePi+ 2ed test with BE_NATIVE but without BE_AMDGPU and without BE_WASM build of devel/llvm19 finally finished successfully, over 46 hrs after it started, so somewhat under 4 times as long as on the RPi4B. The OPi+2ed has somewhat more "avail memory" than resulted from the RPi4B total_mem assignment that I'd used.

With BE_FREEBSD and BE_WASM but not BE_AMDCPU built just fine but took somewhat longer on the RPi4B (no surprise): 13:11:04 vs. NE_NATIVE with BE_WASM's 12:09:45. Its AVAIL_RAM+SWAP use [3070 MiBytes (A+W+L+SU+InAct)] was between the BE_NATIVE+BE_WASM without BE_AMDGPU [1958 MiBytes] and with BE_AMDGPU [5062 Mi Byte+, stopped early due to size vs. configuration]:

With BE_WASM (so: WebAssembly) built just fine, taking 12:09:45 instead of the 12:01:54 on the RPi4B that was used without both BE_AMDGPU and BE_WASM. Slightly less RAM+SWAP usage showing (so: within the range of variation).

There does not seem to be a resource-usage-based reason to avoid BE_WASM as a default:

With BE_AMDGPU and BE_WASM enabled I already see that it has gone through a stage (AMDGPU building) that nearly used up the swap space I've set up:

For reference (just examples):

It built on the RPi4B just fine:

I got the the 2 GiByte RAM Cortex-A7 OrangePi+ 2ed restored to a status where only devel/llvm19 needs to build. So likely days instead of most or all of a week, presuming it can complete.

As a cross check on the intent: The build log with no manual OPTION settings shows the defaults that resulted are:

As it turned out that I could not use Win11Pro Hyper-V to form my intended test contexts for armv7 builds on the Windows Dev Kit 2023, I'm using a RPi4B instead. config.txt can use total_mem=2048 to limit the amount of RAM used. Initial experiments are based on that and: I'm using 3584 MiBytes of swap space and there are only 4 cores. I'm using USE_TMPFS=no , ALLOW_MAKE_JOBS= , no imposed MAKE_JOBS_NUMBER_LIMIT or the like. I'm using -gline-tables-only just to see if that fits. devel/llvm19 having no other builders active in parallel with its own build. The aarch64 environment (like on builders) allows larger armv7 processes than my native armv7 context does. I'm using the updated Makefile (without any changes by me).

FYI: I'm working on getting updated to a context with llvm19 19.1.0.r2 based on the new debug information size tradeoffs, leading me to avoid a default of -g for my optimized but with debug-information build activities. llvm19's package in my historical aarch64-as-aarch64 -g usage context ended up with a 27.9 GiByte flat size and took a little under 2 hr for pre-package build stages and slightly over 4 hr 40 min to package on that Windows DevKit 2023, so slightly over 6 hr 40min total.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270509 is getting reports that the hardware associated with x11-drivers/xf86-video-mga is common across various servers and its removal has messed up having support for the video on such servers.

Mark, I took the list of __eabi_ functions from the list of symbols emitted by libc (minus the floating point symbols).

FYI from doing a llvm/lib/Target/ARM/ARMISelLowering.cpp extraction for RTLIB:: with __aebi_ for isTargetAEABI and isAAPCS_ABI both holding:
(avoiding listing name duplicates for 16 and 8)

. . .
We did a ports exp-run and fixed the fallout that was found. The main type of issue was blindly enabling a compatibility implementation of execvpe leading to declaration clashes. Did the poster find an issue or just wonder?

On Discord a question has been asked related to if the modern execvpe no longer has the kind of issues that lead to: https://cgit.freebsd.org/src/commit/?id=c605eea952146348e5e1ad5cab6c127d7a1bd164 :

FYI: sys/dev/clk/clk.c reports:

In D43746#1003698, @pldrouin_gmail.com wrote:

In D43746#1003688, @bz wrote:

In D43746#999338, @pldrouin_gmail.com wrote:

Merging the code with the existing driver in D43811. This differential is now obsolete.

Can you "abandon" this one so it's no longer open?

Where can I do that? I fail to find such an option...

In D43811#999391, @pldrouin_gmail.com wrote:

Updating copyright notice and credits.

. . .
Thanks Mark. I am not the first one making changes though, I think at least @dgr_semihalf.com and @val_packett.cool did significant changes as well.

If I understand right, the usual Copyright procedure for changes to a file that still has substantial original material but also substantial new material is to add copyright lines (for the new author's material, with years if in dated form), leaving the original Copyright line in place as well.

In D43746#998187, @pldrouin_gmail.com wrote:

Revised version with all requested changes

The templates shown at https://www.freebsd.org/internal/software-license/ have a (nearly) blank line after the Copyright . . . line:

* Copyright (c) [year] [your name]
*
* Redistribution and use in source and binary forms, with or without

In general it is a good place to look at for comparisons.

Avoid use of "All rights reserved." in copyright notices? https://www.freebsd.org/internal/software-license/ reports:

With the ratification of the Berne Convention in 2000, it became obsolete. As such, the FreeBSD project recommends that new code omit the phrase and encourages existing copyright holders to remove it. In 2018, the project updated its templates to remove it.

In D24917#550057, @val_packett.cool wrote:

Looks like this needs to wait until there's some way to get the clock without devicetree (I guess Linux runs with fdt+acpi both to make it work..)

FYI: https://uefi.org/specs/ACPI/6.5/19_ASL_Reference.html#clock-input-resource-descriptor-macro reports:

If "[i]ts mostly a clone of the linux driver" means copying of GPL licensed source code, FreeBSD avoids adding GPL licensed source code, so that the resultant source code in FreeBSD is not GPL licensed. Relicensing GPL source code to enable its addition into FreeBSD needs to be explicit with the original owners of the original source code license(s)/copyrights.

This leads the port net/py-libdnet to be broken:

Freescale i.MX51, i.MX53, . . .

armv6 for main [so: 14] is now in:

The summary's "new arm64 headers are" list is out of date and should not be blindly copied into commit notes.

As a matter of curiosity, did something specific prompt having this form of PCI Configuration Space Access added? FreeBSD has been able to boot the RPi4B's for a long time, even via EDK2. So the test case does not seem to be a driving use case. Are there other known examples of this form of PCI Configuration Space Access needing-to-be/being-able-to-be used?

In D34697#808973, @imp wrote:

. . .
arm would have trouble here, but we no longer make compat libs for arm.
. . .

In D34697#808973, @imp wrote:

. . .
Also arm64 doesn't support -m32, . . .

A list of the FreeBSD servers is maintained at: https://github.com/bdrewery/pkg-status.freebsd.org/blob/master/servers.txt

Going to https://reviews.freebsd.org/D37419 and clicking on the link shows the log just fine for me. (I just tried it again.) ampere2.nyi.freebsd.org is a well known FreeBSD builder machine.

Looks to me like https://developer.arm.com/documentation/100336/0002/aba1429015078674 has the description of the GICD Distributor registers by offset from the Physical Base Address:

I did the 3 tests via booting an installed FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20230302-005cca8361a4-261233.img.xz (from today) and they all worked fine.

I did the 3 tests via booting an installed FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20230302-005cca8361a4-261233.img.xz (from today) and they all worked fine.