Feature Name
ARM Primary Architecture
Summary
Promote ARM from the secondary architecture group to the primary architecture group for both software floating point ("softfp" or "armv5tel") and hardware floating point ("hardfp" or "armv7hl") ABIs. This will ultimately make the treatment of ARM equivalent to that of x86_64 and i686 in the koji build system.
Owner
- Name: Dennis Gilmore
- Email: dennis@ausil.us
- Name: Brendan Conoboy
- Email: blc@redhat.com
Current status
- Targeted release: Fedora 18
- Last updated: 2012-03-16
- Percentage of completion: 00%
Detailed Description
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 proposal contains the rationale and scope for promoting ARM to the primary group. We include suggested criteria for evaluating this feature as well as the technical and administrative steps that will be taken to ensure a smooth transition.
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 initially beyond the scope of this proposal. The philosophical goal herein is to bring the complete Fedora package set to emerging ARM general-purpose computers. The technical goal of this proposal is to mainstream the building of Fedora packages on ARM, then make those packages readily available to end users. As such, general purpose ARM systems are the main interest. While there are no commercially available enterprise ARM servers today, both Calxeda and Marvell will enable OEMs to provide Enterprise grade ARM servers in time to meet the needs of this feature page. Other ARM semiconductor manufacturers 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 ARM developer boards, but includes and requires the use of Enterprise class hardware as one of the steps to a complete transition to primary.
Note this feature page is not in any way about multiarch or multilib. Rather, the feature being proposed is to make changes to the Koji build system to builds packages for ARM as it would the other primary architectures, and then to build system images based on the resulting builds.
Benefit to Fedora
Supporting Fedora ARM will bring tens of thousands of new Fedora users into the community. With inexpensive systems such as the OLPC XO and Raspberry Pi using Fedora for their primary distribution, there is merit enough to seriously consider promotion. ARM as a primary architecture provides a first rate avenue to future participation of new students, educators, and engineers to contribute back to the Fedora project. What's more, the low cost of ARM systems enables global participation like never before. People from around the world who cannot afford a general purpose computer can afford an ARM system, a Fedora ARM system.
Beyond XO and Pi, ARM is of increasing importance in the computer industry. While inexpensive developer hardware is available today, high quality server-grade hardware is just around the corner. By the time the transition proposed in this feature is complete, there will be so many ARM servers available that ARM may be able to complete a mass-rebuild faster than x86_64.
The importance of ARM bringing more developers into the Fedora Project cannot be overstated, but neither can the ascending position of ARM systems in our daily lives. 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. A small selection of current supported Fedora ARM hardware includes the Genesi EfikaMX Smartbox, Compulab Trimslice , Panda Board , Beagle Board, and http://www.origenboard.org/ Origen Board ]. Further, Fedora ARM is or will be the underlying OS for high profile devices such as OLPC XO- 1.75 and RasperryPI, along with many announced projects like the OLPC XO-3 tablet , HP Moonlight server project . Also, Dell has indicated working on ARM and ARM have announced 64 bit processors are coming. To the extent that the future can be predicted, ARM devices are set to become a fixture in the Linux space, so Fedora must increase its support of ARM to support this developing shift in computing.
Scope
Moving from a processor from secondary to a primary 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.
- Fedora 17 GA is complete. Nothing happens during the critical part of the release cycle.
- 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.
- Ensure /mnt/koji has sufficient available storage.
- 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.
- Reliable server-grade ARM hardware is introduced into the PHX Colo facility, communicates on local network with the official koji-hub.
- Any packages that fail to build on ARM are marked with excludearch by a proven packager.
- Fedora 18 Branches
- Proxy builders at Seneca and Red Hat are disabled, leaving only PHX ARM systems active.
- A mass rebuild of F18 demonstrates stability and capacity of Colo ARM servers to handle a complete rebuild in acceptable time period.
- Use secondary tree as external repo for F18/rawhide binaries.
- If builder capacity proves insufficient, add more systems and repeat.
- ARM is added to primary arch list for F18 GA (Or F19, etc if delayed).
The second half of the promotion relates to defining how the resulting packages are consumed by Fedora end users and is included as a nod to the overall releng-specific nature of the transition. From mirroring to installing to supporting odd architectures, this is the most flexible, long term, and somewhat independent aspect of the proposal. These are long-term ARM team goals rather than staged transitional steps.
- Discuss with mirrors and let them know of our plans to add more arches including network and drive space requirements. We do not expect all primary mirrors to carry ARM initially.
- Work with anaconda team to develop ARM support. Hyperscale ARM appliances are an exciting avenue of development as they are not immediately viable as traditional install targets.
- Ensure that the kernel team has the man power to support ARM (ARM team to help). Guidelines for the kernel package are outlined herein.
- Work with QA to ensure ARM is integrated into the test matrices appropriately, provide additional manpower and hardware to ensure things are working.
- Provide an initially limited set of fully supported systems. increasing over time as documentation can be written and testing provided.
- The basic kernel RPM will only provide a QEMU-compatible image to minimize rebuild time. Additional per-board kernels can be configured with koji flags to prevent heavily impacting rebuild times.
Initially supported ARM platforms will include...
- ... devices with VFP3 or later FPU and v7 or higher instruction sets such as
- QEMU Simulator
- OLPC XO-1.75
- Enterprise hardware that we will use as build servers (Marvell Armada-XP, Calxeda Highbank).
- Panda, Beagle, and Origen Development boards.
- Trimslice (Tegra) and EfikaMX (iMX) hardware.
- ... devices with VFP2, older (or no FPU), and v5 or higher instruction set
- QEMU Simulator
- Raspberry Pi
- Most Marvell Kirkwood plug type devices ( eg guruplug, http://www.globalscaletechnologies.com/p-46-sheevaplug-dev-kit.aspx sheevaplug], and dreamplug)
Initial unsupported ARM platforms include...
- Smart phones.
- While it would be possible with a suitable UI its not at all envisioned as a target today.
- Tablet hardware.
- While desirable, we're not quite there yet. Look for another feature request after this one is over and done. Hypothetically, it in a later phase there could be support for both KDE and Gnome make tablet touch based UI's after XO-3 development ramps up. There is also the plasma based spark tablet shipping soon that will be a good target for fedora, Asus EEE Transformers, and other fun devices.
How To Test
The main feature proposal is to update Koji's mechanics and releng's procedures to move ARM builds to the primary build system. The viability of handling ARM builds on Koji via the secondary build system is already well established. The same packages building in primary are being used on secondary now, so we anticipate a fairly smooth transition. In the event that any of the outlined steps cause a problem with primary, the changes outlined above can be reverted, the problem diagnosed, and resolved, before any serious problem is experienced in the build system as a whole.
The long term ARM test strategy, while not fully formed, is partially in scope of this proposal. A discussion on testing is available as a Fedora Hosted Ticket. As part of moving to primary we will endeavor to bring ARM under the realm of Auto-QA and integrate installation/provisioning mechanisms such as Anaconda and Beaker as their support for ARM matures. A complete test strategy for ARM, though important interesting, is not required for moving Koji services, so this aspect is included to establish a mindset of the ARM team, rather than a concrete set of actions.
User Experience
Because ARM systems boot differently than x86 systems, the end user installation experience will vary from x86. That said, once installed, running a Fedora ARM system will provide a similar user experience to that of x86 based arches, particularly if the system is being accessed over the network. For users who are already accustomed to using ARM as a secondary architecture, the move to primary architecture may result in faster access to Fedora-based ARM packages than is currently provided by the secondary mirrors. In addition, a wider package set will eventually be available as more packages failing under ARM are repaired by the ARM team and other interested maintainers
Regarding installation, the initial distribution strategy is to provide root filesystems in both tarball (EG "cd /mnt; tar xf /tmp/tarball") and image (EG "dd if=/tmp/rootimage of=/dev/bootdevice") formats for the supported ARM systems. Such images are already being distributed, for example with the Raspberry Pi remix, so this is really formalizing the existing end user experience, then making it better. As Anaconda and UEFI support matures, a full featured installer image will be provided instead. These features are not necessary for the move to primary, but on the ARM team's roadmap as an important future goal.
See Documentation on using Fedora on ARM for how installation works today.
Developer Experience
The initial burden on developers is small and we endeavor to make it minimal. Most packages already work unmodified on ARM and more than 90% of the F17 package set is already built (Most packages which are not built on ARM are of the FTBFS variety and don't build on primary either). Packages which do not build on ARM during the execution of this proposal will be fixed by the ARM team if required or marked excludearch if optional. During and after the transition to primary, the ARM team will slowly work with packagers to fix their packages to work with ARM (Packages specific to other architectures will naturally be left alone). The ultimate expectation is that developers will submit a build and have it build for i686, x86_64, armv5tel, armv7hl, without having needed to do any extra steps to cause an ARM build to take place.
Enterprise-grade ARM systems should provide a build time that does not greatly hinder developers relative to x86_64 build times. While ARM builds will individually take longer than x86_64 builds, mass rebuilds on ARM will complete faster than x86_64. Once data on server-grade ARM build performance is available it will be provided for reference.
Special handling is recommended for the kernel package but all other packages can be handled as they are today.
Dependencies
- Enterprise class hardware is necessary to complete the transition to primary. This is only required mid-way through the transition and numerous concrete steps can be taken prior to the availability of this hardware.
- Infrastructure support for hardware, including additional space on mirrors.
- Release engineering processes must be revised to accommodate ARM.
- Critical path packages for x86 must all build or be exclude arch on ARM (This is currently true and the ARM team will maintain this condition throughout the transition).
- Determine what packages to include in initial images, setting a multi release timeline for adding additional support.
- At least one supported ARM target should demonstrate functionality of desktop packages.
Contingency Plan
- All steps are incremental and reversible. In the event a delay or reversal is necessary, it will not be difficult to stop and/or reverse.
- In the event that this feature cannot be completed in the Fedora 18 timeframe, remaining steps can be completed during the Fedora 19 development cycle. This is a transition without a hard deadline.
Documentation
- More complete discussion of this feature is available in the form of the Arm Team planning Document.
- The current ARM builds are being handled via Koji + Koji-Shadow, and strictly follow Fedora release engineering policy, ensuring confidence in the result.
Release Notes
- Fedora 17 as a secondary architecture already provides support for running on a wide range of ARM devices.
- Suported ARM hardware includes:
- Panda, Beagle, and Origen Development boards.
- Marvell *plugs
- Trimslice, and EfikaMX smarttop and smartbook.
- Raspberry Pi
- OLPC XO-1.75
- QEMU Simulator