[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 >