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 >