acpi: build dev/acpi_support/acpi_wmi_if.m on ARM64

Per Wikipedia, ACPI WMI support is available on all x86* platforms
and ARM platforms. Add the source to `files.arm64` so code that relies
on its h

acpi: build dev/acpi_support/acpi_wmi_if.m on ARM64

Per Wikipedia, ACPI WMI support is available on all x86* platforms
and ARM platforms. Add the source to `files.arm64` so code that relies
on its headers (thunderbolt(4) for instance), can be built on ARM64.

MFC after: 1 month
Reviewed By: andrew
Differential Revision: https://reviews.freebsd.org/D55535

show more ...

arm64: Add MOPS implementations of copyin/copyout

Reimplement copyin() & copyout() as ifuncs.

Reviewed by: andrew
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D54947

aw_ccu: Add clocks for H616

Reviewed by: manu, adrian
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D54927

aw_gpio: Add support for H616

This adds padconf files for the two gpio ranges on the H616 SOC and adds
the SOC include.

Reviewed by: manu
Sponsored by: The FreeBSD Foundation
Differential Revisio

aw_gpio: Add support for H616

This adds padconf files for the two gpio ranges on the H616 SOC and adds
the SOC include.

Reviewed by: manu
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D54915

show more ...

vchiq: fix build with clang 21

When compiling vchiq with clang 21, the following -Werror warning is
produced:

sys/contrib/vchiq/interface/vchiq_arm/vchiq_arm.c:728:27: error: default initializa

vchiq: fix build with clang 21

When compiling vchiq with clang 21, the following -Werror warning is
produced:

sys/contrib/vchiq/interface/vchiq_arm/vchiq_arm.c:728:27: error: default initialization of an object of type 'VCHIQ_QUEUE_MESSAGE32_T' with const member leaves the object uninitialized [-Werror,-Wdefault-const-init-field-unsafe]
728 | VCHIQ_QUEUE_MESSAGE32_T args32;
| ^
sys/contrib/vchiq/interface/vchiq_arm/vchiq_ioctl.h:151:40: note: member 'elements' declared 'const' here
151 | const /*VCHIQ_ELEMENT_T * */ uint32_t elements;
| ^

While the warning is formally correct, the 'args32' object is
immediately initialized after its declaration. Therefore, suppress the
warning.

MFC after: 3 days

show more ...

ixl(4): Enable building driver on ARM64

For consistency with other drivers enable building ixl
on ARM64 target.

Please be advised that it is only compile tested.
Intel will continue to test Etherne

ixl(4): Enable building driver on ARM64

For consistency with other drivers enable building ixl
on ARM64 target.

Please be advised that it is only compile tested.
Intel will continue to test Ethernet drivers only on x86-64
platforms, and is not going to provide support for issues,
which cannot be reproduced in such environment.

Signed-off-by: Krzysztof Galazka <krzysztof.galazka@intel.com>

Suggested by: Dave Cottlehuber <dch@FreeBSD.org>
Reviewed by: manu
Approved by: kbowling (mentor)
MFC after: 2 weeks
Sponsored by: Intel Corporation
Differential Revision: https://reviews.freebsd.org/D54289

show more ...

arm64: Add missing dtrace_isa.c

MFC after: 1 week

conf: Mark vchiq as depending on fdt

Fix an ACPI only kernel by only building the vchiq files when FDT is
enabled.

Fixes: 745c4aa5e8f0 ("Make BRCM2837 port conform FreeBSD/ARM64 guidelines")
Sponso

conf: Mark vchiq as depending on fdt

Fix an ACPI only kernel by only building the vchiq files when FDT is
enabled.

Fixes: 745c4aa5e8f0 ("Make BRCM2837 port conform FreeBSD/ARM64 guidelines")
Sponsored by: Arm Ltd

show more ...

arm64: Add Arm SPE support

Add support for the Arm Statistical Profiling Extension (SPE). This
is an optional extension added in Armv8.1 to provide profiling of
software using randomised instruction

arm64: Add Arm SPE support

Add support for the Arm Statistical Profiling Extension (SPE). This
is an optional extension added in Armv8.1 to provide profiling of
software using randomised instruction sampling.

This adds the initial driver, and attached it to the hardware tracing
framework, hwt(4), in CPU mode to allow tracing of all threads on
a given CPU.

(commit message by andrew@)

Co-authored-by: Sarah Walker <sarah.walker2@arm.com>
Co-authored-by: Andrew Turner <andrew@FreeBSD.org>
Reviewed by: andrew
Sponsored by: Arm Ltd
Sponsored by: The FreeBSD Foundation (early driver)
Differential Revision: https://reviews.freebsd.org/D46241

show more ...

kexec: Introduce basic arm64 support

This works on older arm64 platforms, but may not work with arm64 devices
using GICv3, due to a quirk in the GICv3, where some registers are
write-once.

Most of

kexec: Introduce basic arm64 support

This works on older arm64 platforms, but may not work with arm64 devices
using GICv3, due to a quirk in the GICv3, where some registers are
write-once.

Most of the kexec reboot work on arm64 can be done entirely in C code,
by disabling the MMU, as the kernel is carved out of the vm_phys_segs
array, so cannot be overwritten.

Reviewed by: andrew
Sponsored by: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D51621

show more ...

arm64: Move BP hardening and SSBD workaround to CPU_FEAT framework

Port the BP hardening and SSBD workaround from cpu_quirks to the
CPU_FEAT framework.

Reviewed by: andrew
Sponsored by: Arm Ltd
Dif

arm64: Move BP hardening and SSBD workaround to CPU_FEAT framework

Port the BP hardening and SSBD workaround from cpu_quirks to the
CPU_FEAT framework.

Reviewed by: andrew
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D53112

show more ...

sys/conf: Fix arm64 vmm_nvhe dependencies

These files include a vmm_hyp equivalent file but don't have a
dependency recorded. Fix this by manually adding this dependency.

This is only a problem in

sys/conf: Fix arm64 vmm_nvhe dependencies

These files include a vmm_hyp equivalent file but don't have a
dependency recorded. Fix this by manually adding this dependency.

This is only a problem in a non-GENERIC configuration as normally vmm
is loaded as vmm.ko.

Reviewed by: imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D51822

show more ...

ossl: Add chacha-armv8-sve.S on aarch64

Fixes: 4757b351ea9d ("openssl: Import version 3.5.1")

ice: Fix aarch64 LINT kernel

Fixes: bc761988b724
(cherry picked from commit 3630e74d8d1c8a068478a4457f825e4efc2b77f0)

arm64: add a GPIO driver for Apple Silicon

This is a ported version of OpenBSD's work, modulo interrupt
functionality. We won't need GPIO interrupts until we start to get
closer to audio support, a

arm64: add a GPIO driver for Apple Silicon

This is a ported version of OpenBSD's work, modulo interrupt
functionality. We won't need GPIO interrupts until we start to get
closer to audio support, and the existing version is sufficient for,
e.g., pcie.

Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D49630

show more ...

arm64: add a driver for the uart found on Apple Silicon machines

This is a revival of the old exynos4210 driver, with some additional
bits to configure the apple "s5l" uart (which is actually slight

arm64: add a driver for the uart found on Apple Silicon machines

This is a revival of the old exynos4210 driver, with some additional
bits to configure the apple "s5l" uart (which is actually slightly
different to operate).

This hasn't been tested on anything that would hit the non-s5l path, so
banish it off to the apple/ domain until someone cares to confirm that
none of the other hardware is broken -- it may be that nobody does, but
the complexity isn't too bad: mostly the driver1 construct added to the
uart_bas that we use to avoid having a whole bunch of shims for uart
driver methods and hardcoded references to the cfg structs.

Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D48120

show more ...

Add driver for the RK3328 GPIO_MUTE pin

This is used in in the ROC-RK3328-CC to control a regulator.

Reviewed by: manu
Differential Revision: https://reviews.freebsd.org/D49399

arm64: Split EFI map parsing code to a common file

Motivation: I would like to enable the EFI memory map parsing on riscv,
which is preferable to parsing memory regions from the device tree. I
could

arm64: Split EFI map parsing code to a common file

Motivation: I would like to enable the EFI memory map parsing on riscv,
which is preferable to parsing memory regions from the device tree. I
could easily duplicate the functionality, but it can be shared without
much extra effort. There are a couple of similar implementations
existing already.

In this commit, the arm64 version of the code is moved to the new file,
and enabled for this platform. No functional change intended. armv7 and
riscv will follow.

amd64 could be converted to use this interface too, but it doesn't use
the common "physmem" interfaces for managing physical memory, and would
therefore require further tweaks. I am not inclined to make this change
at this time.

Reviewed by: imp, andrew
Discussed with: emaste (copyright attribution)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D47746

show more ...

vmm: Consolidate code which manages guest memory regions

On all three platforms supported by vmm, we have mostly duplicated code
to manage guest physical memory regions. Deduplicate much of this co

vmm: Consolidate code which manages guest memory regions

On all three platforms supported by vmm, we have mostly duplicated code
to manage guest physical memory regions. Deduplicate much of this code
and move it into sys/dev/vmm/vmm_mem.c.

To avoid exporting struct vm outside of machdep vmm.c, add a new
struct vm_mem to contain the memory segment descriptors, and add a
vm_mem() accessor, akin to vm_vmspace(). This way vmm_mem.c can
implement its routines without needing to see the layout of struct vm.

The handling of the per-VM vmspace is also duplicated but will be moved
to vmm_mem.c in a follow-up patch.

On amd64, move the ppt_is_mmio() check out of vm_mem_allocated() to keep
the code MI, as PPT is only implemented on amd64. There are only a
couple of callers, so this is not unreasonable.

No functional change intended.

Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D48270

show more ...

sdhci: Refactor the generic FDT driver

This patch refactors the 'sdhci_fdt.c' driver by moving all vendor
specific routines into separate files and making the base 'sdhci_fdt'
driver subclassable. T

sdhci: Refactor the generic FDT driver

This patch refactors the 'sdhci_fdt.c' driver by moving all vendor
specific routines into separate files and making the base 'sdhci_fdt'
driver subclassable. The goal is to make adding new FDT-based drivers
easier and more maintainable. No functional change intended.

Reviewed by: manu, imp
Differential Revision: https://reviews.freebsd.org/D48527

show more ...

aw_timer: rename driver from a10_timer

This reflects its expanded support for platforms other than the A10.

Functions specific to A10/A13 retain the a10 prefix, but the majority of
names in the dri

aw_timer: rename driver from a10_timer

This reflects its expanded support for platforms other than the A10.

Functions specific to A10/A13 retain the a10 prefix, but the majority of
names in the driver are changed, e.g. a10_timer_softc becomes
aw_timer_softc.

Reviewed by: manu, ganbold
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48671

show more ...

psci: Support the arm64 Errata ABI

Add support for the Arm Errata Management Firmware Interface (Errata
ABI) [1]. This provides an interface for the kernel to query the status
of an erratum workarou

psci: Support the arm64 Errata ABI

Add support for the Arm Errata Management Firmware Interface (Errata
ABI) [1]. This provides an interface for the kernel to query the status
of an erratum workaround.

Some errata may be mitigated depending on the other hardware in a SoC,
e.g. Cortex-A78 erratum 2712571 is not affected in systems that use
an Arm interconnect. As there may not be a way for the kernel to know
if this is the case then it would have to implement the workaround
even when not needed.

There are other cases where the needed workaround is implemented in
firmware and if not implemented then the kernel may decide to not use
a feature. In this case we can query the firmware before deciding if
we should use a feature or now.

There is a known issue with some firmware implementations of the Errata
ABI that incorrectly returns a status indicating the erratum is fully
mitigated by the firmware, however there is a kernel component needed,
e.g. Neoverse-N1 erratum 1542419. To handle this case we tell the
caller there is some workaround implemented in the firmware and it can
decide how to handle it. If this is fixed in a way we can detect we can
add a new erratum status value to indicate this.

[1] https://developer.arm.com/documentation/den0100/latest/

Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D48055

show more ...

arm64: Add a new CPU feature framework

This will be used to enable features that are discoverable on boot. It
has support to check if a feature needs to be enabled, and if there is
any errata associ

arm64: Add a new CPU feature framework

This will be used to enable features that are discoverable on boot. It
has support to check if a feature needs to be enabled, and if there is
any errata associated with the feature that mean it shouldn't be
enabled. It can also be used to enable errata workarounds that aren't
associated with a specific feature, e.g. where we need to trap access
to a register in userspace to emulate it.

As some features need to be enabled early, while others can wait there
are two options for when to enable a feature:
* CPU_FEAT_EARLY_BOOT: The feature will be enabled early in the boot.
On the boot CPU this is in initarm, while on secondary CPUs this
is before signalling the CPU has started.
* CPU_FEAT_AFTER_DEV: The feature will be enabled after devices have
attached but before interrupts are enabled.

There are also two scopes for where to enable the feature:
* CPU_FEAT_PER_CPU: The feature will be checked and enabled on all
CPU cores.
* CPU_FEAT_SYSTEM: The feature will only be checked and enabled on a
single core.
It is expected the former will be used for most features, while the
latter is for features that set a global variable to be checked.

Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D47812

show more ...

arm64: rockchip: Add a new rk8xx device

This device will select the base driver for Rockchip PMIC.
While here also add a new rk808 device which selects the PMIC used for RK3399

Reviewed by: andrew

arm64: rockchip: Add a new rk8xx device

This device will select the base driver for Rockchip PMIC.
While here also add a new rk808 device which selects the PMIC used for RK3399

Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D48287

show more ...

arm64: Add a new SOC_ROCKCHIP option

A lot of drivers are shared between all rockchip SoCs, each time we add
suppot for a new SoC we need to add the options in the files.arm64 lines.
Add a new optio

arm64: Add a new SOC_ROCKCHIP option

A lot of drivers are shared between all rockchip SoCs, each time we add
suppot for a new SoC we need to add the options in the files.arm64 lines.
Add a new option SOC_ROCKCHIP that will help simplify this file.

Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D48286

show more ...