From Fedora Project Wiki
(initial page setup)
 
(Integrate arm team planning document language)
Line 5: Line 5:


= Feature Name <!-- The name of your feature --> =
= Feature Name <!-- The name of your feature --> =
ARM architecture as a primary architecture.
Promote ARM to primary architecture status.


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


== Owner ==
== Owner ==
Line 27: Line 27:
== 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  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 beyond the scope of this proposal.  The goal herein is to mainstream the building of Fedora packages on ARM, then make those packages readily available for end users.  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 [http://www.calxeda.com/ Calxeda] and [http://www.marvell.com/ Marvell] will enable OEMs to provide Enterprise grade ARM servers in the near future.  Other ARM semiconductors 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 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 ==
== 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.
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 projectConsider 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 $35There 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 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.
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.  A small selection of current supported Fedora ARM hardware includes
the [http://www.genesi-usa.com/products Genesi EfikaMX Smartbox], [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 market.


== 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 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.
* we will also look at upgrading the storage for /mnt/koji to ensure room for growth
 
* 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
* 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
* 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
Line 53: Line 75:
**** raspberry pi
**** 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])
**** 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
** 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 [http://aseigo.blogspot.com/2012/01/reveal.html the plasma based spark tablet] shipping soon that will be a good target for fedora.
** 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.
 
** import all binaries from secondary?
** use secondary tree as external repo and do a mass rebuild of primary.


== How To Test ==
== How To Test ==
Line 80: Line 100:


== 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 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 ==
== 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
* The biggest dependency is getting Enterprise class hardware
* Infrastructure support for hardware
* Infrastructure support for hardware
* Releng work on redoing the release engineering processes
* Releng work on redoing the release engineering processes
Line 91: Line 111:
== 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
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 ==
== 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 Releng policy, ensuring confidence in the result.


== Release Notes ==
== Release Notes ==
Line 110: Line 131:
== 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]]

Revision as of 06:53, 7 March 2012


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 beyond the scope of this proposal. The goal herein is to mainstream the building of Fedora packages on ARM, then make those packages readily available for end users. 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.

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

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. 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.
    • initial platforms would be the
      • 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.
    • 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

User Experience

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 Documentation on using Fedora on ARM to get started.

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
  • Infrastructure support for hardware
  • Releng work on redoing the release engineering processes
  • Determining exactly what to ship, setting a multi release timeline for adding additional support.

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