The sbsa-ref board intends to look like real hardware (while the virt board is a generic board platform that doesn't match any real hardware).
The hardware part is defined by two specifications:
The Arm Base Boot Requirements (BBR) defines how the firmware reports that to any operating system.
It is intended to be a machine for developing firmware and testing standards compliance with operating systems.
The sbsa-ref board supports:
There are several options considered for future expansion of the platform:
There are system components which can be replaced by easier to use ones. But we decided to keep them as they are.
There are AHCI and XHCI controllers on a system bus. Both could be replaced with PCIe versions but we want to keep them on system bus as SBSA specification allows for it. Also they require generation of DSDT entries to make sure that an operating system knows where they are.
sbsa-ref is a static system that reports a very minimal DeviceTree to the firmware for non-discoverable information about system components. This includes both internal hardware and parts affected by the qemu command line (i.e. CPUs and memory). As a result it must have a firmware specifically built to expect a certain hardware layout (as you would in a real machine).
QEMU provides the guest EL3 firmware with minimal information about hardware platform using minimalistic DeviceTree. This is not a Linux DeviceTree. It is not even a firmware DeviceTree.
It is information passed from QEMU to describe the information a hardware platform would have other mechanisms to discover at runtime, that are affected by the QEMU command line.
Ultimately this device tree may be replaced by IPC calls to an emulated SCP. And when we do that, we won't then have to rewrite Normal world firmware to cope.
Standard setup consists of three elements:
The DeviceTree provided by the board model to the firmware is not intended to be a complete compliant DT. It currently reports:
The platform version is only for informing platform firmware about what kind of sbsa-ref board it is running on. It is neither a QEMU versioned machine type nor a reflection of the level of the SBSA/SystemReady SR support provided.
The machine-version-major value is updated when changes breaking fw compatibility are introduced. The machine-version-minor value is updated when features are added that don't break firmware compatibility.
| Platform version | Changes |
|---|---|
| 0.0 | DeviceTree holds information about CPUs, memory and platform version. |
| 0.1 | GIC information is present in DeviceTree. |
| 0.2 | GIC ITS information is present in DeviceTree. |
| 0.3 | The USB controller is an XHCI device, not EHCI. |
Current plan is to treat TF-A as a kind of EC (Embedded Controller) replacement. Its role is to initialise the platform, gather hardware information from QEMU and provide it via SMC calls to the upper firmware layer (like EDK2).
EDK2 uses information gathered from TF-A to build ACPI tables and provide information to the operating system. With the latest TF-A all hardware information should come via SMC or hardcoded values should be used. No DeviceTree parsing.
| ID | Name | Description | Arguments | Results | Status |
|---|---|---|---|---|---|
| 1 | VERSION | Get platform version | - | platform_version_major, platform_version_minor | upstream |
| 100 | GET_GIC | Get GIC address | - | gicd_base, gicr_base | upstream |
| 101 | GET_GIC_ITS | Get GIC ITS address | - | gic_its_base | upstream |
| 200 | GET_CPU_COUNT | Get amount of cpu cores | - | cpu_count | edk2 review |
| 201 | GET_CPU_NODE | Get NUMA node-id and MPIDR for requested CPU core | cpu_core_id | cpu_node_id, cpu_mpidr | edk2 review |
| 300 | GET_MEMORY_NODES_COUNT | Get amount of memory nodes | - | memory_nodes_count | edk2-review |
| 301 | GET_MEMORY_NODE | Get NUMA node-id and memory_node_id | memory_node_id | memory address, size, node id | edk2-review |