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.
Hi Jon,
Could you point me at the ARM server standards you are referring to specifically?
Thanks, Scott
-----Original Message----- From: Arm-dev [mailto:arm-dev-bounces@centos.org] On Behalf Of Jon Masters Sent: Thursday, October 12, 2017 6:57 PM To: arm-dev@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@centos.org https://lists.centos.org/mailman/listinfo/arm-dev
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.ht...
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.h...
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@centos.org] On Behalf Of Jon Masters Sent: Thursday, October 12, 2017 6:57 PM To: arm-dev@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@centos.org https://lists.centos.org/mailman/listinfo/arm-dev _______________________________________________ Arm-dev mailing list Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev
[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.ht...
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.h...
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@centos.org] On Behalf Of Jon Masters Sent: Thursday, October 12, 2017 6:57 PM To: arm-dev@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@centos.org https://lists.centos.org/mailman/listinfo/arm-dev _______________________________________________ Arm-dev mailing list Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev
Arm-dev mailing list Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev
Jon et al.
I'd like to see the Firmware Test Suite aka fwts available in one of those CentOS repositories. Do you happen to be working on pushing it to the release or do we have to get hold of someone who is in charge Jim?
Itaru
On 10/16/17 1:13 AM, 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.ht...
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.h...
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@centos.org] On Behalf Of Jon Masters Sent: Thursday, October 12, 2017 6:57 PM To: arm-dev@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@centos.org https://lists.centos.org/mailman/listinfo/arm-dev _______________________________________________ Arm-dev mailing list Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev
Arm-dev mailing list Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev
-
Itaru Kitayama -
Jon Masters -
Scott Branden