From Fedora Project Wiki
(initial page setup)
 
(Moved back to FeaturePageIncomplete; fesco ticket for this is vague, waiting on more definition.)
 
(35 intermediate revisions by 6 users not shown)
Line 4: Line 4:
<!-- The actual name of your feature page should look something like: Features/YourFeatureName.  This keeps all features in the same namespace -->
<!-- The actual name of your feature page should look something like: Features/YourFeatureName.  This keeps all features in the same namespace -->


= Feature Name <!-- The name of your feature --> =
== Feature Name <!-- The name of your feature --> ==
ARM architecture as a primary architecture.
 
ARM Primary Architecture


== Summary ==
== Summary ==
<!-- A sentence or two summarizing what this feature is and what it will do.  This information is used for the overall feature summary page for each release. -->
<!-- A sentence or two summarizing what this feature is and what it will do.  This information is used for the overall feature summary page for each release. -->
Move ARM from "Secondary Arch" status to "Primary Arch" fully supporting software and hardware floating point architectures.
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 ==
== Owner ==
<!--This should link to your home wiki page so we know who you are-->
<!--This should link to your home wiki page so we know who you are-->
* Name: [[User:Ausil| Dennis Gilmore]]


<!-- Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or  technical issues need to be resolved-->
<!-- Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or  technical issues need to be resolved-->
* Name: [[User:Ausil| Dennis Gilmore]]
* Email: dennis@ausil.us
* Email: dennis@ausil.us
* Name: [[User:blc| Brendan Conoboy]]
* Email: blc@redhat.com


== Current status ==
== Current status ==
* Targeted release: [[Releases/18 | Fedora 18 ]]  
* Targeted release: [[Releases/18 | Fedora 18 ]]  
* Last updated: 2012-02-29
* Last updated: 2012-03-16
* Percentage of completion: 00%
* Percentage of completion: 00%


<!-- CHANGE THE "FedoraVersion" TEMPLATES ABOVE TO PLAIN NUMBERS WHEN YOU COMPLETE YOUR PAGE. -->
<!-- CHANGE THE "FedoraVersion" TEMPLATES ABOVE TO PLAIN NUMBERS WHEN YOU COMPLETE YOUR PAGE. -->
== Detailed Description ==
== Detailed Description ==
<!-- Expand on the summary, if appropriate.  A couple sentences suffices to explain the goal, but the more details you can provide the better. -->
<!-- Expand on the summary, if appropriate.  A couple sentences suffices to explain the goal, but the more details you can provide the better. -->
Fedora ARM supports arm and armhfp base arches, arm is for software floating point ABI, we compile all packages for armv5tel, and armhfp is for hardware floating pint ABI. Both sets of arches are 32 bit. There are no plans to support multilib or multiarch. Users will choose either hfp (Hardware Floating Point) or sfp (Software Floating Point)When the [http://www.arm.com/about/newsroom/arm-discloses-technical-details-of-the-next-version-of-the-arm-architecture.php announced 64 bit] harware and port shows up we will then bootstrap it from scratch and add it in a future fedora release. 64 bit support will be added without any multiarch or multilib support.  
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 usersAs such, general purpose ARM systems are the main interest.  While there are no commercially available enterprise ARM servers today, both [http://www.calxeda.com/ Calxeda] and [http://www.marvell.com/ 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 [http://www.apm.com/ 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 build packages for ARM as it would the other primary architectures, and then to generate system images based on the resulting builds.


== Benefit to Fedora ==
== Benefit to Fedora ==
<!-- What is the benefit to the platform?  If this is a major capability update, what has changed?  If this is a new feature, what capabilities does it bring? Why will Fedora become a better distribution or project because of this feature?-->
<!-- What is the benefit to the platform?  If this is a major capability update, what has changed?  If this is a new feature, what capabilities does it bring? Why will Fedora become a better distribution or project because of this feature?-->
While traditionally ARM has been shipped in the millions of units for use in phones, tv's, tablets and a multitude of embedded tasks. its is currently moving into more mainstream computing tasksThere is devices like [http://www.genesi-usa.com/products Genesi EfikaMX offerings ], [http://trimslice.com/web/ compulab trimslice ] that could be used for every day computing tasks, [http://pandaboard.org/ Panda Board ], [http://beagleboard.org/ Beagle Board], and [http://www.origenboard.org/ Origen Board ] that are development focused devices but can serve in many purposes, and of course there is higher profile arm developments [http://wiki.laptop.org/go/XO-1.75 OLPC XO- 1.75 ] and [http://raspberrypi.org/ RasperryPI], along with many announced projects like the [http://wiki.laptop.org/go/XO-3 OLPC XO-3 tablet ], [http://h17007.www1.hp.com/us/en/iss/110111.aspx HP Moonlight server project ], [http://www.theregister.co.uk/2010/11/02/dell_dcs_arm_risc_server/ Dell has indicated working on ARM] add to that all the android based tablets and the work going on to make touch interfaces work in KDE and gnome there is a large number of readily available devices that that developers and users can use. In the OLPC and RasperrbyPI cases they both will be shipping with Fedora, while the PI will have other options available and there is nothing stopping anyone putting any other distro on there, both projects will result in millions of fedora users.
Supporting Fedora ARM will bring tens of thousands of new Fedora users into the communityWith inexpensive systems such as the [http://wiki.laptop.org/go/XO-1.75 OLPC XO] and [http://raspberrypi.org/ 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 beforePeople from around the world who cannot afford a general purpose computer can afford an ARM system, a Fedora ARM system.


This is fully in line with Fedora goal of First, this is a upcoming and developing market, there are a lot of  interesting things happening here and it is a challenge to us not only in terms of adding new architectures which really is the easy bitbut in what we ship and how we deliver things to people. different types of devices have different needs. development devices all boot from sd card so we would like ship a raw disk image that is dd'ed onto a sdcard inserted and booted, just like a livecd.
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 [http://www.genesi-usa.com/products Genesi EfikaMX Smarttop and Smartbook], [http://trimslice.com/web/ Compulab Trimslice ], [http://pandaboard.org/ Panda Board ], [http://beagleboard.org/ 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 [http://wiki.laptop.org/go/XO-1.75 OLPC XO- 1.75 ] and [http://raspberrypi.org/ RasperryPI], along with many announced projects like the [http://wiki.laptop.org/go/XO-3 OLPC XO-3 tablet ], [http://h17007.www1.hp.com/us/en/iss/110111.aspx HP Moonlight server project ]. Also, [http://www.theregister.co.uk/2010/11/02/dell_dcs_arm_risc_server/ Dell has indicated working on ARM] and [http://www.arm.com/about/newsroom/arm-discloses-technical-details-of-the-next-version-of-the-arm-architecture.php 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 ==
== Scope ==
<!-- What work do the developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
<!-- What work do the developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
* We need to add enterprise class build hardware to the buildsystem. the systems we expect to soon be available are quad core with 4gb ram and local storage. we will likely be adding at least 50 systems as builders.
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.
* we will also look at upgrading the storage for /mnt/koji to ensure room for growth
 
* We need to discuss with mirrors and let them know of our plans to add more arches
# Fedora 17 GA is complete.  Nothing happens during the critical part of the release cycle.
* 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
# 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 that the kernel team has the man power to support ARM
#* 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.
* 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.
* Provide an initially limited set of fully supported systems. increasing over time as documentation can be written and testing provided.
** initial platforms would be the
* 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.
*** Hardware floating point capable devices
**** OLPC XO-1.75
**** enterprise hardware that we will use as build servers.
**** Panda, Beagle, and Origen Development boards.
**** Trimslice and EfikaMX hardware.
*** Software floating point capable only devices.
**** raspberry pi
**** most marvell kirkwood plug type devices ( eg [http://www.globalscaletechnologies.com/t-guruplugdetails.aspx guruplug], [http://www.globalscaletechnologies.com/p-46-sheevaplug-dev-kit.aspx sheevaplug])
** The arm team has no intention to support phones 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 [http://aseigo.blogspot.com/2012/01/reveal.html the plasma based spark tablet] shipping soon that will be a good target for fedora.


* set a cutover date from secondary to primary.
Initially supported ARM platforms will include:
** import all binaries from secondary?
* Devices with VFP3 or later FPU and v7 or higher instruction sets such as
** use secondary tree as external repo and do a mass rebuild of primary.
** 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 sets such as
** QEMU Simulator
** [http://raspberrypi.org/ Raspberry Pi]
** Most Marvell Kirkwood plug type devices ( eg [http://www.globalscaletechnologies.com/t-guruplugdetails.aspx Guruplug], [http://www.globalscaletechnologies.com/p-46-sheevaplug-dev-kit.aspx Sheevaplug], and [https://www.globalscaletechnologies.comt-dreamplugdetails.aspx Dreamplug])
 
Unsupported ARM platforms are (but not limited to):
* 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 [http://aseigo.blogspot.com/2012/01/reveal.html 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 ==
== How To Test ==
Line 74: Line 102:
3. What are the expected results of those actions?
3. What are the expected results of those actions?
-->
-->
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 [https://fedorahosted.org/fedora-qa/ticket/277 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 ==
== User Experience ==
<!-- If this feature is noticeable by its target audience, how will their experiences change as a result?  Describe what they will see or notice. -->
<!-- If this feature is noticeable by its target audience, how will their experiences change as a result?  Describe what they will see or notice. -->
Running a fedora ARM system should give the same user experience as on x86 based arches.  while installation will be different. qemu-system-arm is a viable option for those who do not have real hardware. See [[Architectures/ARM/Using| Documentation on using Fedora on ARM]] to get started.
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 mirrorsIn 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 systemsSuch images are already being distributed, for example with the [http://zenit.senecac.on.ca/wiki/index.php/Raspberry_Pi_Fedora_Remix 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 [[Architectures/ARM/Using| Documentation on using Fedora on ARM]] for how installation works today.


== Developer Experience ==
== Developer Experience ==
Developer should submit a build and have it build for i686, x86_64, armv5tel, armv7hl with the process being transparent.
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 ==
== Dependencies ==
<!-- What other packages (RPMs) depend on this package?  Are there changes outside the developers' control on which completion of this feature depends?  In other words, completion of another feature owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate?  Other upstream projects like the kernel (if this is not a kernel feature)? -->
<!-- What other packages (RPMs) depend on this package?  Are there changes outside the developers' control on which completion of this feature depends?  In other words, completion of another feature owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate?  Other upstream projects like the kernel (if this is not a kernel feature)? -->
* The biggest dependency is getting Enterpise class hardware
* 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
* Infrastructure support for hardware, including additional space on mirrors.
* Releng work on redoing the release engineering processes
* Release engineering processes must be revised to accommodate ARM.
* Determining exactly what to ship, setting a multi release timeline for adding additional support.  
* 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 ==
== Contingency Plan ==
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "None necessary, revert to previous release behaviour."  Or it might not.  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "None necessary, revert to previous release behaviour."  Or it might not.  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
Move support for arm as a primary arch to Fedora 19
While this Feature proposal is slated for Fedora 18, it is not a solid requirement that it be implemented and complete in the Fedora 18 timeframe.  Rather, we believe the server hardware required will be available in time for Fedora 18, allowing the complete transition to take place during its development cycle.  As we do not propose to make serious changes to packages, this could just as easily be Fedora 17 or 19 were the hardware available in the former, or late in the latter case.  The hard and important facts are as follows:
* 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 ==
== Documentation ==
<!-- Is there upstream documentation on this feature, or notes you have written yourself?  Link to that material here so other interested developers can get involved. -->
<!-- Is there upstream documentation on this feature, or notes you have written yourself?  Link to that material here so other interested developers can get involved. -->
* [[Architectures/ARM/Planning/Primary| Arm Team planning Document]]
* More complete discussion of this feature is available in the form of the  [[Architectures/ARM/Planning/Primary| 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.
*[[Architectures/ARM/Using| Documentation on using Fedora on ARM]]


== Release Notes ==
== Release Notes ==
<!-- The Fedora Release Notes inform end-users about what is new in the release.  Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ -->
<!-- The Fedora Release Notes inform end-users about what is new in the release.  Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ -->
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns.  If there are any such changes involved in this feature, indicate them here.  You can also link to upstream documentation if it satisfies this need.  This information forms the basis of the release notes edited by the documentation team and shipped with the release. -->
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns.  If there are any such changes involved in this feature, indicate them here.  You can also link to upstream documentation if it satisfies this need.  This information forms the basis of the release notes edited by the documentation team and shipped with the release. -->
* Fedora 18 has added wide support for running on the ARM architecture.
* 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.  
* Suported ARM hardware includes (Please see Documentation section):
*** Trimslice, and EfikaMX smarttop and smartbook.  
** Panda, Beagle, and Origen Development boards.  
*** RaspberryPI
** Marvell *plugs
*** OLPC XO-1.75
** Trimslice, and EfikaMX smarttop and smartbook.  
* [[Architectures/ARM/Using| Documentation on using Fedora on ARM]]
** Raspberry Pi
** OLPC XO-1.75
** QEMU Simulator


== Comments and Discussion ==
== Comments and Discussion ==
* See [[Talk:Features/FedoraARM]]  <!-- This adds a link to the "discussion" tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page -->
* See [[Talk:Features/FedoraARM]]  <!-- This adds a link to the "discussion" tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page -->


[[Category:FeaturePageIncomplete]]
[[Category:FeaturePageIncomplete]]

Latest revision as of 09:49, 19 June 2012


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

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 build packages for ARM as it would the other primary architectures, and then to generate 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 Smarttop and Smartbook, 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 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.

  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 introduced into 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 proven packager.
  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 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.
  9. 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 sets such as

Unsupported ARM platforms are (but not limited to):

  • 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

While this Feature proposal is slated for Fedora 18, it is not a solid requirement that it be implemented and complete in the Fedora 18 timeframe. Rather, we believe the server hardware required will be available in time for Fedora 18, allowing the complete transition to take place during its development cycle. As we do not propose to make serious changes to packages, this could just as easily be Fedora 17 or 19 were the hardware available in the former, or late in the latter case. The hard and important facts are as follows:

  • 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

Release Notes

  • Fedora 17 as a secondary architecture already provides support for running on a wide range of ARM devices.
  • Suported ARM hardware includes (Please see Documentation section):
    • Panda, Beagle, and Origen Development boards.
    • Marvell *plugs
    • Trimslice, and EfikaMX smarttop and smartbook.
    • Raspberry Pi
    • OLPC XO-1.75
    • QEMU Simulator

Comments and Discussion