Jeremy Linton
Software Engineer at Arm, on the opensource communities and distro's team. Our mandate is to assure that our partners machines, new architectural features, and software products, are enabled on Linux. The goal is to make the ecosystem "just work".
Making the RaspberryPi SystemReady: A study in applying firmware standards to nonstandard hardware.
Modern Arm machines have management processors, security states, and EL3 (which is conceptually somewhat similar to SMM on x86). They also have a wild west of power, clock, and nonstandard hardware devices which need to be supported before general purpose operating systems can be utilized. In the server space, Arm has hardware (SBSA) and firmware (SBBR) standards for assuring long term support, as well as providing a "just works" experience for end users. The Arm SystemReady program is designed to bring many of these advantages to the Edge and Iot markets as well. It is born out of the fact that much of the what makes x86 or SBSA/SBBR work are standardized firmware abstractions that create a common platform out of diverse hardware, and questioning what the minimal HW platform that is required for those software standards to work.
A couple years ago, the RPi was identified as an easily available platform that could be used to demonstrate that it was possible to boot a wide range of OS's without a lot of custom driver/etc work by focusing on the firmware. Earlier this year the resulting community first, opensource project (https://github.com/pftf/), was successfully one of the first platforms to be SystemReady ES certified and boots a who's who of OSs and hypervisors, both opensource and commercial.
This talk will focus on explaining some of what modern Arm machines look like, their failings, how much code we avoided putting in the Linux kernel, as well as some concrete examples of platform abstraction in ACPI/AML in the context of the RPi. It will also cover some of the critical HW/SW problems that can stop a project like this from succeeding.