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

[Jon Masters]

[additional note: it is going to get much, much harder to build
non-compliant designs beginning next year. Not only do I intend to make
it impossible to avoid using ACPI, but a lot more is in the works to
compel standarized designs across the board - exciting! So if anyone
thinks I am a broken record already, boy will you enjoy what's next ]

On 10/15/2017 12:13 PM, Jon Masters wrote:
> 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
> Architecture):
> 
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0029/index.html
> 
> 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):
> 
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0044b/index.html
> 
> 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).
> 
> Jon.
> 
>> -----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
>>
> 
> _______________________________________________
> Arm-dev mailing list
> Arm-dev at centos.org
> https://lists.centos.org/mailman/listinfo/arm-dev
>