Distributions

Making distributions Just Work on ARM servers

The personal computer market has benefited from a set of reasonably well established standards from nearly its beginning. Those standards have encouraged a high level of interoperability; they have also made it relatively easy to build Linux distributions that will run on a wide range of machines. The embedded world, which is where ARM processors are most often found, has not been so fortunate. As ARM moves into the server market, though, interest in system standards is on the rise. At the 2017 Linaro Connect event in Budapest, Jon Masters of Red Hat and Dong Wei of ARM described the work that has been done to bring order to the ARM server market.

Masters started by noting that the server and embedded markets are, in many ways, stark opposites of each other. In the embedded area, products are developed under tight deadlines, and the operating-system software is typically modified to suit the hardware. In the server market, instead, the operating system that will be installed on next year's systems was made last year. In this realm, he said, changing the hardware is seen as being easier than changing the software. Thus, there is a strong desire for a set of standards that will allow vendors to make servers that can run last year's enterprise distribution releases.

To that end, two documents have been written. The first of these, the Server Base System Architecture (SBSA) [PDF], describes the minimal features that a compliant system must provide. These include architectural specifications (a minimum of the ARM v8.0 architecture, for example) and the system-on-chip (SoC) features (interrupts, clocks, watchdogs, etc.) that must be provided. The other document, the Server Base Boot Requirements (SBBR) [PDF], provides the requirements to be able to boot a compliant distribution. It represents, Masters said, the "ACPI takeover of the world". Along with ACPI, it mandates the UEFI firmware standard and the set of expected boot protocols.

The result is a minimal specification for a set of standard hardware that can boot into a standard bootloader and discover the hardware that is available. There is, at this point, a lot that is not covered. The operation of caches is not discussed, for example, and there is no standard memory map. Emerging technologies are necessarily not a part of this document.

At this point, SUSE developer Alexander Graf noted that the goals behind these standards are good, but there is a missing piece: a way to inject drivers into the system during the installation process. New servers will certainly include hardware that was unknown at the time that a given distribution release was made, so there needs to be a way to add drivers at a later date. Masters agreed that this was a problem that should be worked on, but questioned whether it is appropriate to address it in the SBSA standard; Grant Likely added that it might be better handled at the UEFI level.

Another question had to do with how the standard had been defined; it was acknowledge that, so far, it has been a "who you know" process. Red Hat wanted to have something in place and there wasn't much time to get it done, so things just went forward with as much input from distributors and hardware vendors as could be arranged. There is a desire to open up and formalize the process in the near future, though. Masters noted that many of the core x86 standards were created in a closed manner early on; that is just how things have to be done at that stage, he suggested. An effort will be made to make the process more democratic going forward.

Dong Wei then took over, noting that, while ACPI started as an x86-dominated standard, most of the contributions to ACPI are coming from the ARM community now. The ACPI process has been opened up as this happened, and the actual specifications can now be found online and downloaded without even a click-through license step.

Work is being done on a set of compliance tests, he said. The SBSA test suite checks for the necessary system components and looks at the integration of PCIe peripherals. There have been a lot of "very creative" PCIe implementations shipped, he said, requiring thorough testing. The SBBR test suite tests the firmware interfaces provided by the subject system. The UEFI tests are based on the UEFI self-certification tests (SCT), while the ACPI tests use the Firmware Test Suite from Canonical. The intent is to provide all of these tests under open-source licenses. Unfortunately, at the moment, the UEFI SCT is only available to members. The development of this suite has been moved to a private GitHub repository as a preparatory step toward opening it entirely. There is a unified test suite release coming together in this GitHub repository.

An audience member asked why these tests are being done in the ARM community, rather than existing as a set of cross-architecture tests. Users want their systems to look the same, after all, regardless of their underlying architecture. The answer was that these are low-level tests that are aimed at just that goal, but that getting there requires this layer of architecture-specific test suites.

There was some discussion of a certification process for hardware. Users want their distributions to just work, and a certification sticker would give them confidence that a given product would, indeed, work properly. Masters answered that the tests being discussed here are an input to the certification process, rather than the certification itself. Once the hardware passes the compliance tests, distributors will start doing their own certification testing. There is, though, interest in adding distribution boot testing to the test suites as a way of improving the testing overall.

The final question had to do with cross-platform drivers. There is an interpreted executable format known as EFI Byte Code (EBC); drivers compiled to that format can run on multiple architectures. There is an EBC interpreter for ARM in the Tianocore UEFI reference implementation now. Shipping EBC drivers would allow vendors to support multiple architectures with a single binary, simplifying their lives.

It was noted, though, that this benefit vanishes if x86 drivers continue to be shipped as native executables. Adding ARM drivers requires supporting a second binary format; whether it's EBC or ARM native doesn't make a whole lot of difference. Only if a third major architecture arises will there be value in using EBC. There are also problems with EBC compilers being proprietary, a lack of support for the existing x86 EBC interpreter, and the fact that Microsoft, the only company doing secure-boot signing for drivers, will not sign EBC drivers.

Graf asked whether drivers could, instead, be shipped as a multiple-architecture binary. Progress is being made in this direction, and EFI supports multiple binary formats. Regardless of what form the solution might take, it was asserted that this is a critical blocker for the ARM server market. Without a way to simplify the driver-support problem, it is going to be hard to get card vendors to support ARM servers in general. As the session wound down, this situation was described as the highest-priority problem needing solution for distributors wanting to support ARM servers.

[Thanks to Linaro and the Linux Foundation for funding your editor's travel to Connect.]

Comments (6 posted)

Distribution quote of the week

— Owen Taylor

Comments (none posted)

Tails 2.11 is out

Tails 2.11 has been released. This version adds notifications that Tails 3.0 will not work on 32-bit processors and that I2P will be dropped in Tails 2.12. "Maintaining software like I2P well-integrated in Tails takes time and effort and our team is too busy with other priorities. Unfortunately, we failed to find a developer outside of our team to maintain I2P in Tails. As a consequence, the last version of I2P being shipped in Tails is 0.9.25, which is nearly one year old now at this moment."

Comments (none posted)

Debian Project Leader Elections 2017: Call for nominations

Nominations are open until March 11 for the 2017 Debian Project Leader election. "Prospective leaders should be familiar with the constitution, but just to review: there's a one week period when interested developers can nominate themselves and announce their platform, followed by a three week period intended for campaigning, followed by two weeks for the election itself."

Full Story (comments: none)

Announcing the BSP in Paris

There will be a Bug Squashing Party in Paris, France May 13-14. "We attempt to create an event which is a bit more broader than "just" a BSP, we are looking forward to have a more diverse event for people with different skillsets they already bring, e.g. design and graphics, testing of the upcoming release etc." Register by the end of March.

Full Story (comments: none)

Distribution newsletters

• DistroWatch Weekly (March 6)
• Last week in LineageOS (March 6)
• Lunar Linux weekly news (March 3)
• Mageia Weekly roundup (March 3)
• openSUSE news (March 2)
• This Week in Solus (March 5)
• Ubuntu Kernel Team newsletter (February 28)
• Ubuntu Weekly Newsletter (March 5)

Comments (none posted)

Francis: The story of Firefox OS

Ben Francis has posted a detailed history of the Firefox OS project. "For me it was never about Firefox OS being the third mobile platform. It was always about pushing the limits of web technologies to make the web a more competitive platform for app development. I think we certainly achieved that, and I would argue our work contributed considerably to the trends we now see around Progressive Web Apps. I still believe the web will win in the end. "

Comments (15 posted)