[Arm-dev] ARM Server Standards [WAS: Re: ACPI]

Jon Masters jonathan at jonmasters.org
Sun Oct 15 16:13:57 UTC 2017

On 10/13/2017 07:17 PM, Scott Branden wrote:

> Could you point me at the ARM server standards you are referring to
> specifically?

Hi Scott,

Absolutely. The Arm server hardware standard is SBSA (Server Base System


SBSA defines what the hardware looks like. It says you must implement A
profile cores, must have a standard GIC, must wire up certain interrupts
correctly, must implement things like PCIe properly, and so on. It's
growing over time into multiple levels of compliance as we learn things
(in particular assumptions built into the industry). For example, a lot
more concrete detail on how to do PCIe right is coming.

The SBSA also specifies certain peripherals that you *MUST* implement,
including a standard PL011-compatible UART. The onus is still on those
wanting to enter the server community to read and acquaint themselves
with the specs, and to reach out to the leads to get involved in any
discussions that might happen behind the scenes on such topics - Arm
will sell you IP either way - but work is going on to make sure the
messaging gets out at that time for all future server design effort.

I still hear from people periodically with exciting plans to enter the
server space, but they've often got hackish embedded designs that they
think are "servers". I usually do a detailed design review with the
teams and tell them what they should have done (which includes pinging
me or Microsoft before taping out a chip for input on the design), then
they usually have to return to the drawing board and rework the design.
We won't be modifying software for Arm servers. We will be building a
standard OS (and we have) and everyone will target that, just like x86.
The classical thing to screw up is PCIe. We do proper ECAM using ACPI.
We don't do per-device root port drivers and other embedded weirdness.

The Arm server firmware standard is SBBR (Server Base Boot Requirements):


SBBR defines the interface between firmware and the Operating System. It
requires UEFI for boot (and specifies certain constraints), and ACPI,
DMI (SMBIOS), and other pieces for platform device enumeration. Various
other pieces are defined, including the quiescent state of devices at
boot time, runtime service calls you must implement, the required data
in SMBIOS, and the secondary boot protocol. You must implement PSCI
(ATF/whatever secure firmware interface), etc.

Currently, we have more than 10 silicon server SoC platforms that can
run the same unmodified OS, so that's good. Folks like Qualcomm and
Cavium know what they're doing with the specs and are executing. But
more broadly, I've gotten so frustrated at the broader ecosystem not
fully understanding how servers are built that I'm working on an Arm
server book which will fully specify how to begin an Arm server SoC
project, how to build it, how to make it compliant, and how to execute
correctly in market with a design that will be successful. That'll be a
2018 timeframe release under a free license (to be determined).


> -----Original Message-----
> From: Arm-dev [mailto:arm-dev-bounces at centos.org] On Behalf Of Jon Masters
> Sent: Thursday, October 12, 2017 6:57 PM
> To: arm-dev at centos.org
> Subject: [Arm-dev] ACPI
> Hi all,
> Most of you know me. For those who don't, I'm Chief ARM Architect at Red
> Hat and started the internal Red Hat ARM team back in 2011. I've also
> worked on creating most of the ARM server standards, and with every
> silicon vendor since their design was a paper napkin drawing.
> So it is with some authority I can tell you that ARM servers without ACPI
> have no future. Those of you booting with "acpi=off" are running machines
> completely in violation of the ARM server specs (which mandate the use of
> ACPI tables). You can choose to do this, but such configs have never been
> tested and are completely guaranteed to break randomly in the future when
> you update the distribution, or the hardware.
> But not everyone has fully gotten this message. Beginning in the next
> release of the upstream distro from which CentOS inherits its sources,
> there is a nasty warning message which will be printed if you boot while
> attempting to disable ACPI, or even if the platform contains DeviceTree
> tables (whether used or not). The kernel will also taint itself if it
> detects the presence of DeviceTree on a platform at all.
> Going forward, I am instituting logic that will cause the kernel to panic
> and fail to boot at all when a platform contains a DeviceTree (whether
> used or not) unless some parameter like "platform_is_broken" is passed to
> the kernel. This is irrespective of whether you actually boot with ACPI or
> not. All platforms that aren't simply ACPI must be removed from the face
> of the earth as quickly as possible and replaced with fully standardized
> ones compliant with the ARM server specs. The good news is that firmware
> updates will allow anyone still shipping a DeviceTree to remove it from
> future platform updates to be compliant.
> Now is a good time to stop thinking about disabling ACPI. It is only going
> to get much, much harder to turn it off.
> Jon.
> _______________________________________________
> Arm-dev mailing list
> Arm-dev at centos.org
> https://lists.centos.org/mailman/listinfo/arm-dev
> _______________________________________________
> Arm-dev mailing list
> Arm-dev at centos.org
> https://lists.centos.org/mailman/listinfo/arm-dev

More information about the Arm-dev mailing list