This post is part 5 of the "SBSA Reference Platform in QEMU" series:
- Versioning of sbsa-ref machine
- SBSA Reference Platform update
- Testing *BSD on SBSA Reference Platform
- Running SBSA Reference Platform
- DT-free EDK2 on SBSA Reference Platform
- ConfigurationManager in EDK2: just say no
During last weeks we worked on getting rid of DeviceTree from EDK2 on SBSA Reference Platform. And finally we managed!
All code is merged into upstream EDK2 repository.
What?
Someone may wonder where DeviceTree was in SBSA Reference Platform. Wasn’t it UEFI and ACPI platform?
Yes, from Operating System point of view it is UEFI and ACPI. But if you look deeper you will see DeviceTree hidden inside our chain of software components:
/dts-v1/;
/ {
machine-version-minor = <0x03>;
machine-version-major = <0x00>;
#size-cells = <0x02>;
#address-cells = <0x02>;
compatible = "linux,sbsa-ref";
chosen {
};
memory@10000000000 {
reg = <0x100 0x00 0x00 0x40000000>;
device_type = "memory";
};
intc {
reg = <0x00 0x40060000 0x00 0x10000
0x00 0x40080000 0x00 0x4000000>;
its {
reg = <0x00 0x44081000 0x00 0x20000>;
};
};
cpus {
#size-cells = <0x00>;
#address-cells = <0x02>;
cpu@0 {
reg = <0x00 0x00>;
};
cpu@1 {
reg = <0x00 0x01>;
};
cpu@2 {
reg = <0x00 0x02>;
};
cpu@3 {
reg = <0x00 0x03>;
};
};
};
It is very minimal one, providing us with only those information we need. It does not even pass any compliance checks. For example for Linux, GIC node (/intc/ one) should have gazillion of fields, but we only need addresses.
Trusted Firmware reads it, parses and provides information from it via Secure Monitor Calls (SMC) to upper firmware level (EDK2 in our case). DeviceTree is provided too but we do not read it any more.
Why?
Our goal is to treat software components a bit different then people may expect. QEMU is “virtual hardware” layer, TF-A provides interface to “embedded controller” (EC) layer and EDK2 is firmware layer on top.
On physical hardware firmware assumes some parts and asks EC for the rest of system information. QEMU does not give us that, while giving us a way to alter system configuration more than it would be possible on most of hardware platforms using a bunch of cli arguments.
EDK2 asks for CPU, GIC and Memory. When there is no info about processors or memory, it informs the user and shutdowns the system (such situation does not have a chance of happening but it works as an example).
Bonus stuff: NUMA
Bonus part of this work was adding firmware support for NUMA configuration. When QEMU is run with NUMA arguments then operating system gets whole memory and proper configuration information.
QEMU arguments used:
-smp 4,sockets=4,maxcpus=4
-m 4G,slots=2,maxmem=5G
-object memory-backend-ram,size=1G,id=m0
-object memory-backend-ram,size=3G,id=m1
-numa node,nodeid=0,cpus=0-1,memdev=m0
-numa node,nodeid=1,cpus=2,memdev=m1
-numa node,nodeid=2,cpus=3
How Operating System sees NUMA information:
root@sbsa-ref:~# numactl --hardware
available: 3 nodes (0-2)
node 0 cpus: 0 1
node 0 size: 975 MB
node 0 free: 840 MB
node 1 cpus: 2
node 1 size: 2950 MB
node 1 free: 2909 MB
node 2 cpus: 3
node 2 size: 0 MB
node 2 free: 0 MB
node distances:
node 0 1 2
0: 10 20 20
1: 20 10 20
2: 20 20 10
What next?
There is CPU topology information in review queue. All those sockets, clusters, cores and threads. QEMU will pass it in DeviceTree, TF-A will give it via SMC and then EDK2 will put it in one of ACPI tables (PPTT == Processor Properties Topology Table).
If someone decide to write own firmware for SBSA Reference Platform (like port of U-Boot) then both DeviceTree and set of SMC calls will wait for them, ready to be used to gather hardware information.