4 ms·

Does ARMv9 SystemReady mean the decoupling of OSes from drivers?

With Intel based systems, the OS and the hardware are independent from each other. You can boot into you OS then install drivers to match your hardware. Updating hardware means installing new drivers. Right now with ARM devices, engineers must build OS images with the drivers embedded. Updates to the OS invole re-building that image. I assume this is why it's so hard to simply "install" ARM Linux or Windows on any ARM based device. OEMs must create Windows/Linux ARM images with those drivers embedded. I also assume it's the reason mobile phone vendors provide such short OS update support for Android devices. It must be intensive to continuously rebuild complete Android images for old devices. Listening to the presentation given by Arm, it sounds like SystemReady in ARMv9 aims to add hardware discovery to their platform, allowing the OS to be shipped separately to the drivers. Am I interpreting this correctly? If that's the case, isn't that a massive deal with game changing implications?

johndoe0815 6y ago
The problem with ARM platforms is that there is no hardware or firmware standard - something x86 machines have due to everyone cloning the IBM PC and then painstakingly ensuring compatibility to the original system built in 1981... so an OS for x86 can, in the worst case, rely on BIOS drivers to boot and then install its own drivers. There were similar approaches in the workstation world, e.g. OpenFirmware (IEEE1275) for Sun SPARC and several PowerPC systems (including Macs, but most people didn't know this, I think). In OpenFirmware systems, firmware-level drivers were implemented in FORTH and could be used by any OS (the SunOS text console driver did this IIRC and was horribly slow...). Some ARM systems used OpenFirmware (e.g. several StrongARM systems by DEC 20 years ago), but it was never widely used in ARM systems. ARM missed the opportunity to define standards on levels above the CPU core - on ARM7 systems, there was not even a standard for interrupt controllers, on Cortex-M microcontrollers, there is a proliferation of incompatible peripherals. Sun (by design) and IBM compatibles (by accident) managed this vertical integration better.
floatingatoll 6y ago
I encourage reading the 'Background' and 'Introduction' sections of each of the PDFs linked below. I quote below some relevant paragraphs that may help you and others discuss this. Note that on these webpages, the 'Download' link is above-and-left of the instructions. — "Arm SystemReady Requirements Specification" v1.0(A) defines SystemReady as: For hardware, the Arm SystemReady Program defines a common BSA (Base System Architecture) specification and a set of market specific supplements. For example, SBSA (Server Base System Architecture) supplement specification is for the server segment. The common BSA contains only the bare minimum requirement to deploy an operating system. The BSA is a baseline and, as such, there is no limit on differentiation and special features that can be built atop the base platform, per the market need. For firmware, the program has added additional boot recipes to accommodate the different standards and implementations that are used in a broader ecosystem. These recipes are described in the BBR (Base Boot Requirements) specification. https://developer.arm.com/documentation/den0109/latest https://developer.arm.com/documentation/den0109/latest — "Arm Base Boot Requirements" v1.0(F) states: Variability in boot models and certain key aspects of the system has a direct impact on the cost of software system development and the associated quality risks. The Base Boot Requirements (BBR) specification is part of the Arm strategy of addressing this variability. The primary goal of this document is to ensure sufficient standard system architecture to enable a suitably built single OS image to run on all hardware that is compliant with this specification and the Arm Base System Architecture specification[10]. A driver-based model for advanced platform capabilities beyond basic system configuration and boot is required. However, this model is beyond the scope of this document. This document identifies the Arm and industry standard firmware interfaces applicable to the Arm 64-bit architecture. They include the PSCI, SMCCC, UEFI, ACPI, SMBIOS, and DT interfaces. Arm does not require compliance to this specification. Arm anticipates that Cloud Service Providers (CSPs), OEMs, ODMs, and software providers will require compliance to maximize out of box software compatibility and reliability. https://developer.arm.com/documentation/den0044/latest https://developer.arm.com/documentation/den0044/latest — "Arm Base System Architecture" v1.0(A) states: Implementations that are consistent with Base System Architecture can include additional features that are not included in the definition of BSA. However, software that is written for a specific version of BSA, must run, unaltered, on implementations that include this type of additional functionality. https://developer.arm.com/documentation/den0094/latest https://developer.arm.com/documentation/den0094/latest
wmf 6y ago
You can boot into you OS then install drivers to match your hardware. This only works because the OS includes a base set of drivers and the hardware is (1) discoverable using PCI configuration space and (2) specifically designed to be compatible with those drivers (sometimes using gross emulation kludges). For example, basically every OS includes an AHCI driver and basically all SATA controllers speak AHCI so SATA works well enough to boot. For ARM to be equally usable the SoC vendors need to agree on both discoverability (using PCI or device tree) and common hardware interfaces for stuff like the console and storage so the installer can work. Just discovering devices isn't enough if those devices are nonstandard. AFAIK SystemReady does not mandate this or at least older versions did not. It's kind of political because if they make the spec stricter then almost all existing SoCs will not be compatible which can create a death spiral of "no hardware supports SystemReady so why should OSes bother using it, so why should future hardware bother implementing it".

johndoe0815 6y ago

The problem with ARM platforms is that there is no hardware or firmware standard - something x86 machines have due to everyone cloning the IBM PC and then painstakingly ensuring compatibility to the original system built in 1981... so an OS for x86 can, in the worst case, rely on BIOS drivers to boot and then install its own drivers. There were similar approaches in the workstation world, e.g. OpenFirmware (IEEE1275) for Sun SPARC and several PowerPC systems (including Macs, but most people didn't know this, I think). In OpenFirmware systems, firmware-level drivers were implemented in FORTH and could be used by any OS (the SunOS text console driver did this IIRC and was horribly slow...). Some ARM systems used OpenFirmware (e.g. several StrongARM systems by DEC 20 years ago), but it was never widely used in ARM systems. ARM missed the opportunity to define standards on levels above the CPU core - on ARM7 systems, there was not even a standard for interrupt controllers, on Cortex-M microcontrollers, there is a proliferation of incompatible peripherals. Sun (by design) and IBM compatibles (by accident) managed this vertical integration better.

floatingatoll 6y ago

I encourage reading the 'Background' and 'Introduction' sections of each of the PDFs linked below. I quote below some relevant paragraphs that may help you and others discuss this. Note that on these webpages, the 'Download' link is above-and-left of the instructions. — "Arm SystemReady Requirements Specification" v1.0(A) defines SystemReady as: For hardware, the Arm SystemReady Program defines a common BSA (Base System Architecture) specification and a set of market specific supplements. For example, SBSA (Server Base System Architecture) supplement specification is for the server segment. The common BSA contains only the bare minimum requirement to deploy an operating system. The BSA is a baseline and, as such, there is no limit on differentiation and special features that can be built atop the base platform, per the market need. For firmware, the program has added additional boot recipes to accommodate the different standards and implementations that are used in a broader ecosystem. These recipes are described in the BBR (Base Boot Requirements) specification. https://developer.arm.com/documentation/den0109/latest https://developer.arm.com/documentation/den0109/latest — "Arm Base Boot Requirements" v1.0(F) states: Variability in boot models and certain key aspects of the system has a direct impact on the cost of software system development and the associated quality risks. The Base Boot Requirements (BBR) specification is part of the Arm strategy of addressing this variability. The primary goal of this document is to ensure sufficient standard system architecture to enable a suitably built single OS image to run on all hardware that is compliant with this specification and the Arm Base System Architecture specification[10]. A driver-based model for advanced platform capabilities beyond basic system configuration and boot is required. However, this model is beyond the scope of this document. This document identifies the Arm and industry standard firmware interfaces applicable to the Arm 64-bit architecture. They include the PSCI, SMCCC, UEFI, ACPI, SMBIOS, and DT interfaces. Arm does not require compliance to this specification. Arm anticipates that Cloud Service Providers (CSPs), OEMs, ODMs, and software providers will require compliance to maximize out of box software compatibility and reliability. https://developer.arm.com/documentation/den0044/latest https://developer.arm.com/documentation/den0044/latest — "Arm Base System Architecture" v1.0(A) states: Implementations that are consistent with Base System Architecture can include additional features that are not included in the definition of BSA. However, software that is written for a specific version of BSA, must run, unaltered, on implementations that include this type of additional functionality. https://developer.arm.com/documentation/den0094/latest https://developer.arm.com/documentation/den0094/latest

wmf 6y ago

You can boot into you OS then install drivers to match your hardware. This only works because the OS includes a base set of drivers and the hardware is (1) discoverable using PCI configuration space and (2) specifically designed to be compatible with those drivers (sometimes using gross emulation kludges). For example, basically every OS includes an AHCI driver and basically all SATA controllers speak AHCI so SATA works well enough to boot. For ARM to be equally usable the SoC vendors need to agree on both discoverability (using PCI or device tree) and common hardware interfaces for stuff like the console and storage so the installer can work. Just discovering devices isn't enough if those devices are nonstandard. AFAIK SystemReady does not mandate this or at least older versions did not. It's kind of political because if they make the spec stricter then almost all existing SoCs will not be compatible which can create a death spiral of "no hardware supports SystemReady so why should OSes bother using it, so why should future hardware bother implementing it".