On the firmware side, an ideally standard Arm machine boots using UEFI and ACPI. The other CPUs are initialised with PSCI and dynamic power management is handled with CPPC.
On the hardware side, requirements are having a GIC as an interrupt controller and a standard PCIe ECAM-compliant controller. (+ other sets of MMIO devices, which can be exposed through ACPI)
The constraints placed on the CPU core itself that have a consequence on OS support today are support for the 4KB granule in the Base System Architecture specification. The SBSA supplement adds mandatory support for the 64KB granule.
Before, all Arm platforms which officially run customer-modifiable code on the bare metal supported both 4KB and 64KB granules. With the Apple M1, that changes as that platform only supports 4KB and 16KB granules, with no support for 64KB granules. A real-world consequence of this is that current Red Hat Enterprise Linux and CentOS kernels cannot run on Apple M1 devices in a virtual machine.
Let’s see how compliant the different platforms on the market today are at a customer-accessible price point, which are either very popular or have support of standards by the manufacturer:
Raspberry Pi 4 ($35 onwards)
A SystemReady ES certified platform. The UEFI firmware is not provided by Raspberry Pi, but by a third-party instead.
That’s not devoid of consequences. The onboard SPI flash is used only for the first-stage boot loader after the boot ROM, making the Raspberry Pi unable to directly boot a standard OS image. As such, the SystemReady-compliant firmware has to be provided on external media.
Bugs: Legacy SoC devices can only access to the first GB of RAM, the PCIe controller on earlier revisions can only use the first 3GB of RAM and 64-bit MMIO accesses are disallowed for the PCIe controller.
SolidRun Honeycomb LX2K ($750, RAM not included)
The NXP Layerscape LX2160A SoM used on the Honeycomb LX2K platform is certified as SystemReady ES compliant. In this case, the firmware is provided by the manufacturer, which supports standardisation efforts.
The platform is relatively devoid of bugs which hurt the user experience significantly. However some non-standardised devices (such as the Ethernet controller) might not be supported in all OSes at this point in time.
NVIDIA Jetson AGX Xavier Developer Kit ($699)
Do not get it yet if your goal is to use SystemReady-compliant OSes. The UEFI firmware on the Xavier was released a month ago, and is still very much experimental. (for example, no display out yet)
The PCIe controller on the platform is also not ECAM compliant.
The vendor BSP still ships with Linux 4.9 today (based on the Android kernel tree no less…) , which is very far from an ideal situation.
Windows on Arm laptops ($399 onwards)
On those platforms, Secure Boot can be turned off. Power management isn’t done through CPPC but by a manufacturer-specific PEP driver. The OS gets started at EL1. A non-standard protocol, Secure Launch, is used by Windows to be able to launch its hypervisor at EL2 on this platform. This protocol isn’t supported by Linux.
Linux on this platform uses third-party made Device Trees instead of using ACPI tables provided by the firmware. (except at install time, with a minimal set of devices being supported)
Currently, modified OS install images are used for those platforms to handle platform bugs. You’ll have to extract firmware from a Windows partition after install to enable support for most SoC peripherals.
Mac Mini 2020, Apple M1 ($699)
This platform makes no pretence at all of being compliant with Arm boot-time standards. You’ll not be able to use a generic operating system on the bare metal on this platform, with adaptation for that specific hardware needed instead.
Note however that this doesn’t mean that you cannot use the same kernel image between a standards-compliant platform and an Apple platform. A kernel image can be built to support both at the same time.