Architectures/ARM/Planning/Primary

This page is a draft only
It is still under construction and content may change. Do not rely on the information on this page.

Introduction

ARM processors are the most popular CPUs in the world. While historically found in embedded devices, ARM systems suitable for general purpose computation are becoming increasingly common. As ARM based laptops and desktops become people's everyday devices it is important that Fedora be available and well supported. This page contains the rationale and scope for promoting ARM to a primary architecture. We include suggested criteria for evalauting this proposal as well as the technical and administrative steps that might be taken to ensure a smooth transition.

Scope of ARM support propsal

While there are many ARM devices in the world, only a small subset of those devices are immediately suitable for use with Fedora. Fedora on consumer electronic devices, though interesting, is beyond the scope of this proposal. The goal herein is to mainstream the building of Fedora packages. As such, ARM systems which are suitable for building packages are of primary interest. There are no commercially available enterprise ARM servers at this time, but both Calxeda and Marvell will enable OEMs to provide Enterprise grade ARM servers in the near future. Other ARM semiconductors such as Applied Micro have announced the upcoming availability of 64-bit ARM Server CPUs as well. This proposal begins the transition from Secondary to Primary with hobbyist boards, but includes and requires the use of Enterprise class hardware as one of the steps to a complete transition to Primary.

Fedora ARM Today

Fedora ARM is currently a secondary architecture maintained by The Seneca Centre for Development of Open Technology. Seneca hosts its own koji-hub and dozens of ARM builders. A second set of builders is provided by Red Hat, also using the Seneca koji hub. Koji-shadow is being used to closely follow rawhide development. Most packages build for ARM with little to no modification.

Current ARM hardware is 32 bit, contains 512-1024MB of RAM, featuring single or dual core 1GHz processors. Currently employed builder hardware is currently a combination of Pandaboards, Guruplugs, Trimslices, and a few other miscellaneous host-types. Server grade ARM hardware is not available commercially, but will be in the near future. The Enterprise grade server hardware to replace these systems will be quad core, have 4-8GB of RAM and run between 1.0-1.6GHz. Later generation hardware will go even further, rivaling x86_64 in many ways.

Why leave secondary?

One might wonder, since ARM is not yet at full feature parity of x86_64, why should it be promoted? The answer is that the primary vs secondary distinction isn’t simply about competing architectures, it’s about a smooth running project. Consider the reason PowerPC was demoted to a secondary architecture:

PowerPC was dropped by Apple, removing the primary supplier of commodity PPC hardware from the market. With each passing month fewer developers had PowerPC hardware, decreasing the ability to support it. Even with interest in the platform, hardware for building and using Fedora PPC was harder to come by due to the high cost of purchasing Enterprise class POWER machines. Expensive hardware led to slight interest and there was no clear indicator that the situation would be corrected in the future. This made the architecture a drag on the Fedora project as a whole given there was very little benefit to keeping it a primary architecture.

In contrast, ARM systems are ascending in the market place. There is inexpensive hardware readily available, soon for as little as $35. There will be an excess of package builders by the time the final step in the primary push is complete, dwarfing even x86_64 in machine count and possibly in mass rebuild time. This low barrier to entry means more people than ever, around the world, can afford to be part of the Fedora Project.

This latter point, ARM bringing more developers into the Fedora Project cannot be overstated. The success of mobile computing via smart phones and tablets is an ARM success story and an x86 warning; As more people have ARM systems and fewer have PCs, Fedora's status as a developer distribution requires supporting emerging mainstream hardware. To the extent that the future can be predicted, this means supporting ARM.

The Plan

Moving from a secondary to a primary architecture in Fedora is unprecedented. We propose a multi-step process where each step is small, reversible, and well timed to minimize impact on schedules, systems, and packagers.

• 1. Fedora 17 GA is complete. Nothing happens during the critical part of the release cycle.
• 2. ARM Koji-hub service moves from Seneca to primary PHX Colo facility. ARM builds are not yet tied * to any primary architecture, they are simply hosted by the same hub. Builders at Seneca and Red Hat * communicate with the hub via proven proxy server.
• 3. Server-grade ARM hardware is introduced at Seneca or Red Hat, also communicates with PHX koji-hub via squid proxy. Administrative obstacles are identified and resolved with vendors.
• 4. Reliable server-grade ARM hardware is moved to the PHX Colo facility, communicates on local network with the official koji-hub.
• 5. Any packages that fail to build on ARM are marked with excludearch by a provenpackager.
• 6. Fedora 18 Branches
• 7. Proxy builders at Seneca and Red Hat are disabled, leaving only PHX ARM systems active.
• 8. A mass rebuild of F18 demonstrates capacity of Colo ARM servers to handle a complete rebuild in acceptable time period.
• 9. ARM is added to primary arch list for F18 GA. If point 8 does not succeed more systems are added and this item pushes back to F19/rawhide.

Hypothetical Q&A

• Q. Does Fedora ARM have a proven track record?
  • A. Fedora ARM has attained a significant degree of functionality in recent years using standard Fedora releng mechanisms such as mock and koji. The OLPC project using Fedora ARM is just one example of its success under Seneca's stewardship.

• Q. Do we have to support every ARM device on the planet?
  • A. No, only the subset of packages needed for builders needs to be supported at the outset. Special graphics drivers, custom mobile devices, etc, are beyond the scope of this proposal.

• Q. Will making ARM a primary architecture cause a sudden burden on packagers?
  • A. No- Packages which do not work on ARM will initially be excused with excludedarch. Members of the ARM team will work with packagers to get their packages working on ARM. Most packages already work with ARM so the actual effort to get to this point is relatively minor.

• Q. Will making ARM a primary architecture slow down builds significantly?
  • A. No- Part of the proposal is to bring up as many ARM servers as it takes to provide the processing capacity needed to complete a mass rebuild in a similar period of time. At present we believe 3 server-grade ARM systems for 1 x86_64 system will provide comparable build power. Should this number be insufficient we will add builders until the required build power is reached.

• Q. Do all packages need to work on ARM?
  • A. No- they only need to build or be excludearched. For primary purposes it is imperative that we minimize the impact on other architectures. After build system integrity has been assured, individual packages can be tested and fixed as needed.

• Q. Are there any benefits to Fedora users and developers who don’t care about ARM?
  • A. Yes- Bugs are sometimes exposed by ARM before they are observed on other architectures. Adding ARM to primary will enable us to spot bugs sooner, not just on ARM, but for many classes of architecture-neutral bugs.

Differences & Similarities between ARM and x86

In one sense, Fedora is a collection of Linux packages, managed by RPM with a selection of very specific features provided by NetworkManager, SELinux, Pulse Audio, Systemd, gnome-desktop, etc. These are all packages which Fedora ARM supports today. There are some differences, however, when one approaches the installation of new systems.

• There is not a unified kernel for all ARM systems as there is for all x86 systems. This is slowly changing as more ARM systems move to Flattened Device Tree. Nonetheless, the initial kernel package for ARM will only support a small subset of available ARM systems. While we want to be as inclusive as possible, for the Primary push, only certain devices will be supported via the official kernel package. It is possible and likely that additional kernels will be built along-side to provide additional support.
• Most ARM systems today use UBoot rather than Grub/Grub2. While this may change in the future, the ARM team has already added support in grubby to allow for the installation and updating of ARM kernels on supported platforms (OMAP and Tegra, specifically).
• Installation via CD-ROM is not available as no ARM systems come with optical drives. Installation via USB stick, though possible, is a bit trickier due to the non-unified kernel. PXE and full Anaconda ARM support are both possible, though in their infancy.

• There is no LSB for ARM, yet, but it’s entirely functional without LSB.

• The critical path package set btweeen ARM and x86 is almost identical.