As in commit 9051987e40 for amd64, support up to 1024 CPU cores.
arm64 hardware with more than 256 CPU cores is currently available and
will become increasingly common over FreeBSD 14's lifetime.
PR: 269572
Reviewed by: andrew
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D41319
It is a simple RTC found in some Arm SoCs, e.g. the Arm Juno.
Reviewed by: manu
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D41267
Fix a boot-time panic in qcom_mdio_ipq4018 due to a missing bus function
and hook the file up to the build so that it will not rot away.
Test booted on an ipq807x in 2022.
X-Differential Revision: extracted from D37882
The gic driver is also probed at this pass and depending on the order of
the nodes in the dts rk_i2c can be probed first and will fail, this is the
case for the rk3328 SoC.
The PMIC drivers are also probed at this pass but on the iicbus which is created
in rk_i2c so there is no order conflict here.
Fixes: ddefad7c4f ("arm64: rockchip: Tweak i2c, pmic and iodomain order")
Sponsored by: Beckhoff Automation GmbH & Co. KG
We need i2c first to set it to MIDDLE, then we need one of the pmics
so set them to LATE, only then we can attach iodomain which needs some
regulators exposed by the pmic so set it to LAST.
Sponsored by: Beckhoff Automation GmbH & Co. KG
We create a static array of pointers to per-CPU data. Because the cpuid
space on arm64 is not sparse there is no need to add an extra level of
indirection. Move to use mallocarray to allocate the redistributors as
a single array.
Sponsored by: Arm Ltd
Match other platforms, include the kernel config in the build.
Reviewed by: emaste
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D41284
WFI and WFIT trap to EL2 when executed in a vmm guest. (Currently
WFE/WFET are not configured to trap.) We only handle WFI at the moment,
so these constants are useful when handling the exception.
Reviewed by: andrew
MFC after: 1 week
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D41199
No fields have been defined, but it has been documented in the
Architecture Reference Manual.
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D40897
While here move to decimal for the _op and _CR definitions to be used
by a future macro to define the register when the assembler doesn't
know about it.
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D40896
While here move to decimal for the _op and _CR definitions to be used
by a future macro to define the register when the assembler doesn't
know about it.
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D40895
No fields have been defined, but it has been documented in the
Architecture Reference Manual.
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D40894
It breaks a future macro that creates the alternative register name
for old compilers.
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D40892
While here move to decimal for the _op and _CR definitions to be used
by a future macro to define the register when the assembler doesn't
know about it.
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D40890
While here move to decimal for the _op and _CR definitions to be used
by a future macro to define the register when the assembler doesn't
know about it.
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D40889
While here move to decimal for the _op and _CR definitions to be used
by a future macro to define the register when the assembler doesn't
know about it.
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D40888
While here move to decimal for the _op and _CR definitions to be used
by a future macro to define the register when the assembler doesn't
know about it.
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D40887
Eliminate unnecessary TLB invalidations by pmap_kenter(),
pmap_qenter(), and pmap_mapbios() when the old page table entries
were invalid.
While I'm here, correct some nearby whitespace issues.
MFC after: 2 weeks
In order to compile lib32 libraries and other 32-bit code on arm64,
<machine/foo.h> needs to be redirected to an arm header rather
than arm64 when building with -m32. Ifdef the arm64 headers that
are installed in /usr/include/machine and used by user-level software
(including references from /usr/include/*.h) so that if __arm__ is
defined when including the arm64 version, <arm/foo.h> is included
rather than using the rest of the file's contents. Some arm headers
had no arm64 equivalent; headers were added just to do the redirection.
These files use #error if __arm__ is not defined to guard against
confusion. Also add an include/arm Makefile, and modify Makefiles
as needed to install everything, including the arm files in
/usr/include/arm. fenv.h comes from lib/msun/arm/fenv.h.
The new arm64 headers are:
acle-compat.h
cpuinfo.h
sysreg.h
Reviewed by: jrtc27, imp
Differential Revision: https://reviews.freebsd.org/D40944
Removed redundant OP_RN_SP for TYPE_02, since these addressing modes
always use the SP register, never XZR.
Reviewed by: mhorne
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D40588
Neither of the remaining callers to pmap_kremove() warrant inlining.
Those calls rarely occur. In other words, we were optimizing for the
uncommon case.
MFC after: 1 week
pmap_unmapbios() can simply call pmap_kremove_device() rather than
duplicating its code.
While I'm here, add a comment to pmap_kremove_device() explaining its
proper use, and fix a whitespace issue.
MFC after: 1 week
I believe that there are two reasons that the missing TAILQ
initialization operations haven't caused a problem. First, the TAILQ
head's first field is being initialized to zeroes elsewhere. Second,
the first access to the TAILQ head's last field is by
TAILQ_INSERT_HEAD(), which assigns to the last field without reading
it when the first field is NULL.
Reviewed by: kib, markj
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D41118
Several vm_radix tries are not initialized with vm_radix_init. That
works, for now, since static initialization zeroes the root field
anyway, but if initialization changes, these tries will fail. Add
missing initializer calls.
Reviewed by: alc, kib, markj
Differential Revision: https://reviews.freebsd.org/D40971
Strictly speaking, SYS V Aarch64 ABI does not states that lr should be
cleared, however gdb relies on lr and tryes to unwind stack further.
Reviewed by:
Differential Revision: https://reviews.freebsd.org/D40841
Use of compiler builtin ffs/ctz functions will result in optimized
instruction sequences when possible, and fall back to calling a function
provided by the compiler run-time library. We have slowly shifted our
platforms to take advantage of these builtins in 60645781d6 (arm64),
1c76d3a9fb (arm), 9e319462a0 (powerpc, partial).
Some platforms still rely on the libkern implementations of these
functions provided by libkern, namely riscv, powerpc (ffs*, flsll), and
i386 (ffsll and flsll). These routines are slow, as they perform a
linear search for the bit in question. Even on platforms lacking
dedicated bit-search instructions, such as riscv, the compiler library
will provide better-optimized routines, e.g. by using binary search.
Consolidate all definitions of these functions (whether currently using
builtins or not) to libkern.h. This should result in equivalent or
better performing routines in all cases.
One wart in all of this is the existing HAVE_INLINE_F*** macros, which
we use in a few places to conditionally avoid the slow libkern routines.
These aren't easily removed in one commit. For now, provide these
defines unconditionally, but marked for removal after subsequent
cleanup.
Removal of the now unused libkern routines will follow in the next
commit.
Reviewed by: dougm, imp (previous version)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40698
This will be used by bhyve and will allow the size to change, e.g. for SVE.
Reviewed by: markj
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D40131
In get_kernel_reg_masked we use update_lower_register to get the lower
value of two registers for a given field. It will return the entire
register value with just the single field updated.
Because of this get_kernel_reg_masked needs to use the returned value
directly rather than ORing each field together. Fix this by updating
the mask and returning that from get_kernel_reg_masked.
Reviewed by: markj
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D40846
The setting of VM_NFREEORDER and the comment describing it were copied
from sparc64 where both the page size and the number of page table
entries that fit in a cache line are different from arm64.
Reviewed by: andrew, kib, markj
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D40782
No functional change intended.
Reviewed by: andrew
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Sponsored by: Klara, Inc. (hardware)
Differential Revision: https://reviews.freebsd.org/D40502
This lets consumers fetch the value of a system register and apply a
mask over individual fields. That is, each field in the returned value
will be the "smaller" of the two provided by "mask" and the value saved
in kern_cpu_desc. This will be used by vmm to sanitize host system
register fields.
Reviewed by: andrew
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Sponsored by: Klara, Inc. (hardware)
Differential Revision: https://reviews.freebsd.org/D40500
