ARM Server Base, and what it might mean for RISC OS

So, I was taking a quick look at the ARM Server Base Boot Requirements doc, and noticed that it’s basically just UEFI and ACPI. (The ARM Server Base System Architecture doc is restricted to registered ARM customers, so I can’t look at that, but I believe ARM Server Base doesn’t actually require that, and that UEFI and ACPI can describe a system well enough for an arbitrary Server Base kernel to boot on an arbitrary system.)

There’s also claims out there that this compatibility extends at least to Windows – so if that means one HAL… that makes me wonder if this might actually make sense for RISC OS. I’m actually suspecting that Windows may well be calling for Server Base Boot, then it’d just need graphics drivers for optimum performance, really.

The biggest problem I see is that this is all AArch64, and RISC OS is AArch32. Not insurmountable, though – an AArch64 stub could handle UEFI services for the rest of the OS, much like Linux’s support for cross-architecture UEFI loading. In addition, UEFI gives you a (32 bpp although no alpha so effectively 24 bpp RGB, it looks like) framebuffer that you can use until you have your own graphics drivers running.

Thoughts?

They don’t include EFI_GRAPHICS_OUTPUT_PROTOCOL in the UEFI requirements, so I don’t think there’s any requirement for the UEFI framebuffer to be supported (after all, this is intended to be a server spec). So the UEFI component will get you networking and some kind of TTY, but that’s about it. The rest needs to be handled by ACPI, which will solve the problem of hardware discoverability, but won’t do anything to solve the problem of us needing drivers for the many different chips/macrocells.

Microsoft’s DBG2 specification, which covers the different UART types that ACPI can expose, defines 7 different UART types. Two of those types are 16550 or compatible, the other five are all ARM specific (including an explicit entry for the BCM 2835). OK, so maybe this is a public version of the document and the full list actually has a few other UARTs used by different systems (There are some gaps in the numbering which are listed as “reserved”), but it still goes to show that the components in an ARM system are nowhere near as standardised as those in an x86 system.

It’s also worth bearing in mind the device tree system that Linux introduced a few years ago (and is a requirement for Linux support of any new ARM SoCs). A generic HAL which is built around device trees might offer us the same benefits as an ARM server HAL, except with the added bonus that we don’t have to wait for the fabled ARM server hardware to materialise.

but it still goes to show that the components in an ARM system are nowhere near as standardised as those in an x86 system. […] the device tree system that Linux introduced a few years ago (and is a requirement for Linux support of any new ARM SoCs).

I believe Linus had a rather spectacular sweary rant about exactly this. Pretty much every ARM SoC is different. There’s roughly zero standardisation in anything at all. This can be seen quite clearly on the downloads page, with a RISC OS build specific to each board. As opposed to a “RISC OS image” that just starts up. Hell, the boards don’t even start up in the same way…

I’m pleased to see the bit I’ve highlighted in italics. Withholding Linux must have put the frighteners on SoC bakers, but it was a good tactic. A lot of hardware on “a PC” (any PC) can be determined just by looking at it. An ARM board doesn’t even have a common device boot methodology yet. So, device tree. At least we’re slowly getting somewhere. Maybe in another two decades, ARM boards will be about where x86 boards were two decades ago…

Do note that UEFI+ACPI-based ARM desktop experience machines are going to be shipping, potentially in volume, next year.

Microsoft’s calling them “Cellular PCs”.

Microsoft’s calling them “Cellular PCs”.

Looks like they’ve arrived or are arriving? link