SBSA, SystemReady & the Platform Contract

• Pre-2016 Arm servers were each a little snowflake — vendor-specific boot, vendor-patched kernel, vendor device tree, vendor config for GIC/SMMU/timers.
• Ubuntu on Cavium ThunderX needed one patched kernel tree; Ubuntu on AMD Seattle needed another; neither ran on each other's box.
• This was OK in mobile (vendor bootloader + AOSP image per device) but unsuitable for datacentres where the admin wants "just boot a stock RHEL/Ubuntu/Rocky ISO".
• x86 had solved this in the 1990s: BIOS → UEFI + ACPI gave a standard runtime machine description; installers probed and worked everywhere.
• Arm needed the same contract. SBSA (2016) + SBBR + BSA (2019) + SystemReady (2020) built it.

• GICv3 (+ ITS) — interrupt controller. ITS (Interrupt Translation Service) handles MSI / LPI routing.
• SMMU-v3 — I/O MMU. Stage 1 + 2 translation, ATS / PASID / PRI, event queue.
• Generic Timer — architectural per-EL timers + memory-mapped system counter.
• PMU (PMUv3) — standardised performance counter access at EL1 + EL0.
• PCIe root complex — PCIe ECAM memory layout specified.
• UART — SBSA UART is a subset of PL011; boot console.
• Watchdog — SBSA Watchdog spec; two-stage (warn + reset).
• TPM — for SBSA 5+, a TCG-compliant TPM 2.0 at a discoverable location.

• UEFI 2.7+ (runtime services, boot services, boot manager, HII).
• ACPI 6.3+ tables describing every device:
  • RSDT / XSDT — root pointers
  • MADT — GIC topology
  • GTDT — timers
  • IORT — SMMU/PCIe topology
  • PPTT — processor cache/package hierarchy
  • SPCR — UART config
  • SLIT / SRAT — NUMA + affinity
  • MPAM / APMT / BDAT — partitioning + DRAM setup
• PSCI (Power State Coordination) — CPU_ON, CPU_OFF, SYSTEM_RESET, SYSTEM_SUSPEND.

// Boot flow on a SystemReady-SR Arm server:
// (x86-like, except EL3 secure monitor below UEFI)

BL1 (ROM loader)          → in ROM
BL2 (image loader)        → DRAM bring-up
BL31 (EL3, TF-A)          → PSCI, SDEI, SMCCC services
BL32 (optional S-EL1 TEE) → OP-TEE if present
BL33 (UEFI, EDK2)         → Boot Manager, ACPI tables

UEFI -> grub-aa64.efi -> vmlinuz + initrd

// Linux sees: ACPI tables, PSCI over SMC, GICv3, SMMUv3
// No per-vendor DTB; device description is ACPI.

• BSA (Base System Architecture) was announced in 2019 as the superset of SBSA + the equivalent for embedded / IoT / client Arm platforms.
• Same philosophy: define the standard runtime feature set so distros don't need per-device patches.
• Used by:
  • Arm-based laptops (Windows on Arm devices, Qualcomm Snapdragon Compute)
  • IoT / networking SoCs targeting Ubuntu or Fedora IoT
  • Automotive Linux targets (QNX, AGL)
• BBR is the companion firmware boot spec.
• SBSA is now effectively "BSA for servers" — has SBSA-specific extras like PCIe Root Complex requirements.

• Every transition is standardised — UEFI handoff protocol, PSCI ABI, ACPI runtime.
• Linux entry point doesn't care about vendor: reads MADT/GTDT/IORT from ACPI, brings up cores via PSCI.
• TF-A (EL3) is the same code base across 40+ SoCs with vendor-specific BL2 platforms as plugins.
• Kernel command line + initramfs fetched from EFI System Partition — same as any x86 UEFI box.

• Trusted Firmware-A (TF-A) — canonical EL3 implementation. BSD licence. Supported by virtually every Arm server SoC vendor.
• Supplies PSCI, SDEI, SMCCC, RAS handlers, EL3 secure monitor for TrustZone / RME.
• EDK2 (TianoCore) — the UEFI implementation that ships as BL33 on every SystemReady-SR box.
• EDK2 provides UEFI Boot Services (LoadImage, AllocatePages) and Runtime Services (GetTime, SetVariable).
• Linaro's OP-TEE is the canonical S-EL1 trusted OS — handles secure storage, fTPM, fingerprint, biometric matchers.
• Together: EL3 TF-A + S-EL1 OP-TEE + EL2 hypervisor + EL1 Linux is a full stack, entirely open-source.

• Guest expects SBSA-level features emulated or passed through:
  • GICv3 with vGIC (virtual distributor)
  • vSMMU (if passing through PCIe)
  • Virtual PMU (PMUv3 + SPE if enabled)
  • Generic Timer + CNTVOFF_EL2 offset
• PSCI to the guest is a trap-and-emulate into KVM.
• SBSA Level 3 is the practical "minimum VM guest" — anything newer is host-dependent.
• CCA adds a Realm VM flavour where even the host hypervisor can't introspect guest memory.

• A Neoverse hire is often responsible for one or more of:
  • Making a new SoC pass Arm ACS
  • Writing the ACPI tables
  • Debugging PSCI or SMCCC corner cases
  • Implementing MPAM at SLC
  • Certifying a box through SystemReady SR or ES
• A candidate who can't explain MADT, IORT, and PSCI is immediately out in 2024.
• A candidate who knows the layering — "SBSA says core count ≥ 4, SBBR says UEFI 2.7, ACS runs in UEFI shell" — is in.

• "What's the difference between SBSA and BSA?" → SBSA is server-specific; BSA is the superset covering servers, laptops, IoT, automotive. BSA came later (2019) as the unifying spec.
• "What tables does the Linux kernel read to discover CPUs?" → MADT (GIC topology + CPU MPIDRs), PPTT (cache/package hierarchy), SRAT (NUMA).
• "Who implements PSCI on a Neoverse box?" → EL3 TF-A. The OS SMC's up with a PSCI function ID and TF-A executes it (power up a core, system reset).

• "What's IORT for?" → maps PCIe Requester ID → SMMU stream ID → memory. Without it, DMA isolation for virt wouldn't work.
• "Why SystemReady SR vs ES vs IR?" → SR = server (full UEFI + ACPI, distro boots); ES = embedded server (edge, 5G); IR = IoT (U-Boot allowed, simpler); LS = LinuxBoot-flavoured.
• "What is the Arm ACS?" → Architecture Compliance Suite — 2000+ tests the silicon must pass for SystemReady certification. Runs in UEFI shell pre-OS.