Shared publicly  - 
Too bad ARM put the text under clause 5 (ii and iv in particular) in the license agreement to DOWNLOAD THEIR OPEN SPEC. Because now I can't download the spec to read it.

Why? Because if I do, I might not be able to discuss how we could solve something better than what their spec says. Or at least, I need written consent from ARM before I do so.

What a bummer.
Congratulations to #ARM  on today's announcement of the Server Base System Architecture (SBSA):

You'll see me quoted in some related press over the coming hours. This is the beginning of a standardization journey and we have been diligently addressing compatibility issues ahead of time for the past few years. When you buy a 64-bit ARM server later this year, it will be standardized, will support a standardized platform, will run standardized Operating System software, and will just work. Sorry other architectures, you'll have to find somewhere else to attack.
Ben Pfaff's profile photoArnd Bergmann's profile photoMark Brown's profile photoPantelis Antoniou's profile photo
I always question whether this sort of clause is really enforceable for information that is obviously not being handled as a trade secret, but obviously the "safe" course is to act as if it is.
In case you are wondering about the contents, it's not super exciting. SBSA describes various hardware components that are required for a compliant server. Things like CPU, PCIe, timers, IOMMU, UART, watchdog, and interrupts are described in enough detail that it should be possible to take a compliant OS image and boot to the stage where you can load drivers for all other components that are not standardized, while booting and any software interfaces are not touched at all, that is a separate spec.

Other parts that you'd find in a server however are mentioned barely (AHCI, USB, ...) or not at all (BMC, machine check, GPIO, ...), so in practice we'll likely still need some SoC specific drivers even for basic functionality on compliant machines, or an additional specification to cover those.

The things that are mandated all seem extremely reasonable and will indeed help porting Linux (even more so other OSs) to compliant SoCs. If a system is limited to what's in the spec, plus additional devices attached to PCIe, it's trivial to support it with either DT or ACPI. Now that the spec is out, I would however question any ACPI code submission that is intended for non-compliant systems. As far as I'm concerned, we should not be doing those, since there is no hope in running another ACPI+SBSA based OS on those, and supporting random out-of-spec parts in ACPI has the danger of complicating the Linux ACPI code substantially.
+Arnd Bergmann I haven't read it (and probably won't without avoiding the click-through license) but from what you mention, since the hardware is standardized enough, why is there a need for the ACPI mandate. A single DT blob for the base spec is enough to boot and then you can use some kind of DT overlay feature to tack on any non-compliant H/W.

Am I misinterpreting things?
+Pantelis Antoniou SBSA specifies what Hardware components you can have and what features they must support if present, but not how you find out how many of each there are and what resources (mmio, IRQ, etc) they use.
+Arnd Bergmann As long as you know what kind of hardware the base platform contains it is trivial to have a light-weight method of defining what the resources are. The problem with ARM on Linux is the bewildering variance of sub architectures and different ways of accomplishing the same thing over and over again.

Plus I bet that if the hardware is strictly defined, the resources that said hardware are going to be mostly the same for 90% of the cases.
I guess most devices in an SBSA system end up on PCIe, so they don't have to be described. To find the PCIe devices, you basically need (for each PCI domain) the config space address, the MMIO aperture and the four legacy IRQ numbers that are required to be routed to the root GIC. I would expect the addresses to be different on each SoC, but there could be a single compatible string indicating that the PCIe core is compliant to the SBSA definition.
There are a handful of other devices in a similar category, but there is some allowance for non-essential "peripheral subsystems which do not conform to the above". One interpretation is that this can only be standalone devices such as ethernet or scsi, and those would be easy enough to handle. I suspect SoC vendors will however try to argue their way into describing things like pin controllers, secondary irq chips, i2c buses etc under this clause and make it mandatory to actually have drivers for these in order to boot the system. That would not be much different from what we have without SBSA of course.
+Arnd Bergmann of course Intel is busy doing ACPI for more embedded looking devices so we're going to have to cope with them to at least some extent in generic code, arch/ might be a different story.
Add a comment...