Thanks for the comments. I don't have an armv7 with VFP anymore. I'll try to borrow one from @mw, but it'll probably be another week before I get my hands on it and look deeper into this.

In D39364#896033, @andrew wrote:

Upstream libunwind already changed to the new name in https://github.com/libunwind/libunwind/commit/99fb31d5f05ff6c96ca3a9350c792618fab23f2d

In D37419#895643, @markmi_dsl-only.net wrote:

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

My guess here is that I have IPv6 access via my ISP (not just IPv4) and that you do not have IPv6 access. I did not find any official listing of the protocols supported but I did find material claiming IPv6-only for some of the servers as an explanation of why some folks in a 2021 discussion could vs. could-not get information from the servers of interest in that discussion.

The patch has been rewritten from scratch.
In order to build it D39091 has to be applied first.
Then the ossl armv7 assembly logic has to be regenerated - crypto/openssl/crypto/aes/asm/bsaes-armv7.pl > sys/crypto/openssl/arm/bsaes-armv7.S

@andrew Do you have any more comment w.r.t. this?
If not I'll commit this patch and D38696 soon.

In D38696#880545, @markmi_dsl-only.net wrote:

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

Why does get_vfpcontext only need critical_enter/critical_exit to span so little but set_vfpcontext to span so much?

An implication is that no variation in context from the likes of, say, a cpu migration would mess up an already partially completed memcpy in get_vfpcontext. So the pcb_vfpstate storage used would apparently be unchanged over the whole memcpy operation.

Fix kernel build when VFP is not used.

This was fixed in D24922.

• Fix a shallow copy bug in cpu_fork
• Adjust the logic to match the recent changes made to arm64 implementation by andrew@.
• Remove the _MC_FP_VALID, as it's not needed.

I've applied this patch and it seems to work just fine with a ARMADA38X config, which didn't use the NEW_PCIB option before.
That is the system boots, but I don't have anything plugged into the pcie slot at the moment.
I'll look for a card that I can put in, and will let you know if it works.

LGTM, but I've mostly only looked at felix and e6000sw.

In D37421#855702, @jhb wrote:

Huh? Rejecting that would be utterly wrong. AES-GCM as a stream cipher permits payloads that are not a multiple of a block size. tools/tools/crypto/cryptocheck explicitly checks for that for stream ciphers like AES-CTR and AES-GCM in its tests with -z as well. There is no padding for IPsec when using a stream cipher.

Please remove the file mode change to tests/sys/opencrypto/runtests.sh.

Since this isn't an Armada38x specific change I believe that it should be applied to all kernel configs.
IMHO we should modify the default value in arm/include/param.h.
Another thing is that 8 pages might be more than needed, e.g. amd64 defaults to 4/6 depending on whether KASAN is enabled.
Also as mw mentioned the commit message should contain a verbose explanation why we need to increase the kernel stack size.

Fix patch context (-U9999)

Update the patch based on ngie@ comments.

This matches other occurrences of NETIF_DEBUG in this file.

sprintf -> snprintf