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.

Note: The following was done with a 4 GiByte RPI4B in order to avoid having a 8 GiByte RPi4B used with the U-Boot 2023.01 that FreeBSD is using: 2023.01 fails to load FreeBSD's EFI loader for a 8 GiByte RPi4B, reporting a message that is a misnomer for the actual internal problem.

Retesting my 3 armv7 tests based on use of the updates https://reviews.freebsd.org/D38696?id=117780 and https://reviews.freebsd.org/D38698?id=117779 worked fine.

Retesting my 3 armv7 tests based on use of the updates https://reviews.freebsd.org/D38696?id=117780 and https://reviews.freebsd.org/D38698?id=117779 worked fine.

With the savectx blne -> bl change, D38696.diff, and D38698.diff all applied, all
the activities with all 3 of my small example programs for the armv7 floating
point related problems look to be working just fine: no KASSERT's ( simple_dbl.c
and dbl_and_ull_via_async.cpp activities) and no odd values showing up in a
thread ( dbl_and_ull_multithread.cpp runs for minutes at a time).

With the savectx blne -> bl change, D38696.diff, and D38698.diff all applied, all
the activities with all 3 of my small example programs for the armv7 floating
point related problems look to be working just fine: no KASSERT's ( simple_dbl.c
and dbl_and_ull_via_async.cpp activities) and no odd values showing up in a
thread ( dbl_and_ull_multithread.cpp runs for minutes at a time).

Do not take the following as indicating anything is necessarily wrong. It is more about my ignorance in the subjects involved.

On the lists, I've provided 3 small C/C++ programs that when used,
sometimes mixed with some use of gdb or lldb, get assert panics
from a debug kernel or corrupted floating point datanow. Look at the
new text in the messages indicated below to see the programs with
instructions in the comments for how to build and test:

For a failure bisected (or analogous) to have started with this change, see: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268995

Looks good to me.

In D37462#860547, @karels wrote:

I found these over the weekend too, testing the snapshot images. Fixed by 4c8a257810a6.

Given a "Don't" -> "Do not" workaround after dd but before booting in order to try to see if the rest worked . . .

I tried the new main [so: 14] snapshot, dd'd to a USB3 SSD and booted:
snaphot: FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20221224-c89209c674f2-259842.img
so: FreeBSD 14.0-CURRENT #0 main-n259842-c89209c674f2: Sat Dec 24 05:52:28 UTC 2022
Result (from the serial console capture):

Starting file system checks:
/dev/ufs/rootfs: FILE SYSTEM CLEAN; SKIPPING CHECKS
/dev/ufs/rootfs: clean, 599506 free (242 frags, 74908 blocks, 0.0% fragmentation)
/etc/rc.d/growfs: 203: Syntax error: "(" unexpected (expecting "}")

FYI: After updating the kernel, my test of building the problematical devel/nasm commit via USE_TMPFS=all in poudriere-devel on/for amd64 main worked just fine. (No runaway process creation, unlike before.)

In D35962#856931, @imp wrote:

. . .

This divergence is quite old. We've been forever fixing problems with amd64 vs x86_64 in builds as well, and that dates back 15 years...

FYI:

# sysctl hw.machine
hw.machine: arm64

In D35962#856587, @pkubaj wrote:

Well, Poudriere should use uname -p. Using -p doesn't make sense. On powerpc*, it prints just powerpc on all 4 platforms and is totally misleading on 3 of them. On armv{6,7}, it's imprecise (do we deal with arm as in the removed ARMv5, armeb, armv6 or maybe armv7?), although not as incorrect as on powerpc*. On riscv64, it makes other software think it's actually riscv32, which FreeBSD doesn't even support. I have posted previously links here to software and ugly workarounds that I needed to use.

In D35962#856540, @imp wrote:

[Editied to correct inaccurate recall of old details.]

Does this change the status of the man page content for uname? :

The options are as follows:

In D37462#854293, @cperciva wrote:

Another question: Do you want to respect vm.swap_maxpages? Or just allocate the swap space and let the kernel potentially issue a warning about the device being too large and not being fully utilized?

In exploring testing a "C0T" RPi4B 8 GiByte (no odd DMA address limits) and retesting the old "B0T" one (has odd DMA address limits), I've learned that the maximum-address view is directly available via what ACPI's _DMA provides. I've updated the code and the comments for such. This is a recent change, not one that I've used for long at this point. (The prior coding has been in sustained use for a ZFS bectl context but was poorer based on what I now understand.)

". . . and the existing root is less than 40% of the disk" What if other partitions/slices than root's are taking up space as well? Do you need to use an available free space's size that is sufficiently large instead?

Is the script used with the likes of:

"other values indicate a swap size in sectors": so from media to media, with different sector sizes, the same figure means differing sizes?

What of the i386 failure example that https://lists.freebsd.org/archives/dev-commits-src-main/2022-October/010362.html reports:

ln -s efi ${DESTDIR}/boot/msdos

The update looks right to me.

When you divide and multiply by constants, the compiler will optimize this. Have you looked at the resulting assembly code using -O2 ?

Try to compile the new code and look at the assembly.

I made the same comments in D36857 . . .

Something to consider? :