From Fedora Project Wiki

< Features
Revision as of 19:52, 16 March 2012 by Blc (talk | contribs) (update dependencies)


Feature Name

Promote ARM to primary architecture status.

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 ARM equivalent to x86_64 and i686 in the build system.

Owner

  • Email: dennis@ausil.us

Current status

  • Targeted release: Fedora 18
  • Last updated: 2012-02-29
  • 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 omputation 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 a primary architecture. We include suggested criteria for evaluating this feature as well as the technical and administrative steps that might 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 which 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.

Note this proposal is principally about the Fedora build system configuration and does not include any requirement or consideration for multiarch or multilib in any way.

Benefit to Fedora

The primary benefit to Fedora for promoting ARM is to 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 its primary distribution, there is merit enough to seriously consider promotion. Moving ARM to primary means providing a first rate avenue for future participation for students, teachers and engineers to contribute back to the Fedora project.

Beyond XO and Pi, ARM systems are of ascending importance in the computer industry. While there is already inexpensive hardware readily available, high quality server-grade hardware just around the corner. By the time the transition proposed in this feature has been completed, there will be so many ARM servers available that ARM will be able to complete a mass-rebuild before x86_64.

The way ARM provides a low barrier to entry means more people than ever, around the world, can afford to be part of the Fedora Project. The importance of 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. A small selection of current supported Fedora ARM hardware includes the Genesi EfikaMX Smartbox, Compulab Trimslice , Panda Board , Beagle Board, and 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 market.

Scope

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.
    • Ensure /mnt/koji has sufficient available storage.
  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.
    • Use secondary tree as external repo for F18/rawhide binaries.
  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.

The second half of the promotion relates to defining how the resulting packages are consumed by Fedora end users. From mirroring to installing to supporting odd architectures, this is the most flexible, long term, and somewhat independent aspect of the endeavor.

  • We need to discuss with mirrors and let them know of our plans to add more arches
  • Work with anaconda to start to support arm, especially on the appliance side since a large number of arm devices will not initially be viable traditional install targets
  • Ensure that the kernel team has the man power to support ARM
  • Work with QA to ensure ARM is integrated into the test matrices appropriately, provide additional manpower and hardware to ensure things are working.
  • limited set of initially fully supported systems. increasing over time.
    • The basic kernel package would only build a Qemu-compatible image to minimize rebuild time. Additional per-board kernels can be configured with koji flags to prevent heavily impacting rebuild times.
    • initial platforms would be the
      • Devices with vfp3 or Higher FPU and v7 or Higher Instruction Set
        • QEMU Simulator
        • OLPC XO-1.75
        • Enterprise hardware that we will use as build servers.
        • Panda, Beagle, and Origen Development boards.
        • Trimslice and EfikaMX hardware.
      • Devices with FPU below vfp3 (or no FPU), and v5 or Higher Instruction Set
    • The arm team has no intention to support smartphones. While it would be possible with a suitable UI its not at all envisioned as a target today.
    • Tablet hardware would be the next phase as both KDE and Gnome make tablet touch based UI's and the XO-3 development ramps up. there is also the plasma based spark tablet shipping soon that will be a good target for fedora.

How To Test

The main feature being propsed is the mechanics of ARM moving to the primary build system. Testing ARM on Koji via the secondary build system is already well tested. The same packages building in primary are being used on secondary now, so we anticipate a smooth transition. In the event that any of the outlined steps causes 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. 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. 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

End users will have greater access to Fedora-based ARM packages than is currently provided by the secondary mirrors. A wider package set will ultimately be available as more packages failing under ARM will get attention. Because ARM systems boot differently than x86 systems, the initial distribution of bits and user installation experience will vary from x86. Once installed, running a Fedora ARM system will provide a similar user experience to that of x86 based arches. While installation will be different, qemu-system-arm is a viable option for those who do not have real hardware.

The initial distribution strategy is to provide root filesystems in both tarball (cd /mnt; tar xf /tmp/tarball) and image (dd if=/tmp/rootimage of=/dev/bootdevice) formats for the supported platforms. Such images are already being distributed, for example with the Raspberry Pi remix. 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.

See Documentation on using Fedora on ARM for how things work today.

Developer Experience

The initial burden on developers is very low. Most packages already work unmodified on ARM. Packages which do not build on ARM initially will be marked with an excludearch. The ARM team will slowly work with packagers to bring their packages online in ARM, where applicable (Non-ARM arch specific packages will also be excluded). The ultimate expectation is that developers will submit a build and have it build for i686, x86_64, armv5tel, armv7hl with the process being transparent. Enterprise-grade ARM systems should provide a build time that does not greatly hinder developers relative to x86_64 build times. Once data on this point is available it will be provided.

Dependencies

  • The biggest dependency is getting Enterprise class hardware. This is only required mid-way through the transition.
  • Infrastructure support for hardware, including additional space on mirrors.
  • Releng work on redoing the release engineering processes
  • Critical path packages for x86 must all build or be exclude arch on ARM (This is already true).
  • Determine what to ship in initial images, setting a multi release timeline for adding additional support.
  • At least one supported ARM target that demonstrates desktop functionality (Pi, Trimslice, etc).

Contingency Plan

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.

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 Releng policy, ensuring confidence in the result.

Release Notes

  • Fedora 18 has added wide support for running on the ARM architecture.
    • Suported arm hardware includes:
      • Panda, Beagle, and Origen Development boards.
      • Trimslice, and EfikaMX smarttop and smartbook.
      • RaspberryPI
      • OLPC XO-1.75
  • Documentation on using Fedora on ARM

Comments and Discussion

Retrieved from "https://fedoraproject.org/w/index.php?title=Features/FedoraARM&oldid=277973"