This post is part
During Linaro Connect MAD24 I attended several talks about SystemReady IR and discussed that subject with countless people. And it left me with a feeling that I need to write some words about it.
What is SystemReady at all?
SystemReady program replaced ServerReady one when people realized that it would be good to have standards compliant hardware in all device types.
The SystemReady whitepaper says:
Arm SystemReady is a set of standards and a compliance certification program that enables interoperability with generic off-the-shelf operating systems and hypervisors. You will see the term “just works” used throughout this white paper and in other Arm SystemReady materials. When we use the term just works, we mean the process of enabling operating systems to work out of the box on Arm-based devices, through the adoption of these standards and tools. Because Arm SystemReady standards allows software to just work, our ecosystem can focus on innovation and differentiation.
In a perfectly round world all Arm hardware would be SystemReady compliant. We are not there yet.
Bands?
There are several bands (types) of SystemReady hardware:
-
LS aka “Linux Server” for some weird server types where Linux is used as a firmware. From what I was told we can forget about it as it just got removed.
-
SR aka “ServerReady” for Arm servers. Common set of hardware (defined by SBSA specification) with UEFI and ACPI on top.
-
IR aka “IoT Ready” for everything which is not a server. Any EFI implementation (U-Boot usually) with DeviceTree for hardware description.
-
ES aka “Embedded Server” for IR devices but with ACPI used instead of DeviceTree.
-
VE aka “Virtual Environment” for virtualisation platforms
You may ask “so four or five?” here. The thing is that there are:
- five if you just count them
- four to deal with (LS is gone)
- three when it comes to physical hardware
- two which really matter (SR, IR)
Let me write something about each one from my point of view. In an order of my preference.
SR (Server Ready)
Server Ready system has simple hardware controlled by UEFI firmware providing EFI services and ACPI tables to the operating system. There are specifications listing both hardware (BSA, SBSA) and firmware (BBR) components which needs to be present.
The problem with SR is that is no longer about servers. Client PC systems need to be SR as well. Time to end with laptops being smartphones with larger screen and keyboard (like it is with Apple Macbooks or Windows on Arm laptops).
ACPI vs DeviceTree philosophy difference
From what I heard during Linaro Connect many developers have a problem with switching from DeviceTree world to EFI+ACPI one. They feel like giving up control over the platform.
So I cannot put system to sleep by toggling GPIO16 anymore?
No, you still can. But now it is done in firmware while operating system have to
call GoToSleep() kind of function provided by firmware. From OS point of view
all SR systems go to sleep same way — by firmware call. OS does not really need
to know what happens under it (some systems will “toggle GPIO16”, some may send
50KB of XML files between 8 chips on motherboard).
I call it “philosophy change”. Less work on OS side, more on firmware one. Once done, you may even get older editions of distributions running without any OS changes (which may have “a business case” for some of your customers).
IR (IoT Ready)
In my opinion IR is the most important one. When vendor is not capable of following requirements of SR band.
On some level it is the same as good vendor is supposed to do now. Mainline U-Boot and kernel support, put firmware in on-board storage and have your device boot out-of-the-box.
Hardware has to pass BSA tests, firmware requirements are described in EBBR specification. What is specific to IR band?
You need to have firmware providing EFI services (which nowadays means properly configured U-Boot, Tianocore EDK2 or other implementation). Hardware description needs to be provided in form of DeviceTree blob (if you want ACPI then look at ES band).
ES (Embedded Server)
For quite a while ES felt like “Eat Shit”. I think that vendors should go for IR or SR for their products while there can be interesting use of ES in community.
Community members may learn EFI, EDK2, ACPI by using IR certified hardware. First get EDK2 running in DT mode, then migrate to ACPI. Learn new philosophy where firmware cooperates with OS rather than “here is DT and see ya”.