From Fedora Project Wiki
No edit summary
 
(30 intermediate revisions by 5 users not shown)
Line 24: Line 24:
== Summary ==
== Summary ==
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. -->
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. -->
Make ARM a primary architecture. add armv7hl to the i686 and x86_64 as arches that we build every package for. This will mean that all packages must build for ARM to be released. As of Fedora 19 we have dropped support for software floating support so we are only talking about adding hardware floating point 32 bit support.
Make ARM a primary architecture. Add armv7hl to the i686 and x86_64 as arches that we build and support. This will mean that all packages supported by the ARM architecture must build for ARM to be released. With the release of Fedora 19 we have deprecated support for software floating support (ARMv5tel sfp) so the only proposed addition to primary architectures is currently ARMv7 hardware floating point 32 bit support (ARMv7 hfp 32bit).


== Owner ==
== Owner ==
Line 31: Line 31:
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]]
* Name: [[User:Ausil| Dennis Gilmore]], [[User:Pbrobinson| Peter Robinson]]
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. -->
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. -->
* Email: dennis@ausil.us
* Email: dennis@ausil.us pbrobinson@gmail.com
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> -->
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> -->
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)
Line 41: Line 41:
== Current status ==
== Current status ==
* Targeted release: [[Releases/20 | Fedora 20 ]]  
* Targeted release: [[Releases/20 | Fedora 20 ]]  
* Last updated: 2013-07-02
* Last updated: 2013-07-08
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page  
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page  
Bugzilla states meaning as usual:
Bugzilla states meaning as usual:
Line 50: Line 50:
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
-->
-->
* Tracker bug: <will be assigned by the Wrangler>
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=998560 #998560]
 
FESCo resolution: Build ARM on primary infrastructure. Whether it is released as a primary Fedora 20 or as 'Fedora 20 for ARM' depends on how well it fulfills release criteria and functionality criteria closer to release time (+5).
 
Followup: Fedora for ARM32 was promoted to a primary architecture in Fedora 20.


== 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. -->
The Changing IT landscape has started to focus on greener technologies. One thing thats changing due to this is that ARM cpu's traditionally the domain of embedded and mobile applications are finding themselves moving into the desktop, notebook and server markets. Fedora ARM works on many different devices.
The Changing IT landscape has started to focus on greener technologies as well as cheaper mass produced devices that allow for fully functional cheap devices for lower socio-economic areas and other markets like education and "makers". ARM SoCs have traditionally been the domain of embedded and mobile applications but are now finding their way into more traditional computing devices like desktop, notebook and server markets. Fedora ARM currently works on many different devices with wider support coming with each new mainline kernel release.
 
For this change we will enable armv7hl builds on primary koji, and compose arm trees alongside of x86 ones.  Fedora has in the Phoenix data centre 96 quad core calxeda server nodes each had a quad core 1.4ghz soc, 4gb ram and 250gb hdd.  Some of these nodes will remain in the arm koji for building updates for fedora 18 and 19 though when support for Fedora 18 drops some of the nodes will be able to be reallocated. Infrastructure has expressed an interest in trying some of its workloads on ARM, some are for QA, some for releng, there is currently 24 nodes configured in primary koji ready to go as builders, we can add 24 more when ARM becomes primary if desired.


we have moved the kernel to a unified kernel we now build a LPAE and base variant, the same as i686. There is a ARM specific kernel maintainer working in the fedora Kernel team. Release's are composed using the exact same tooling as primary. Disk images for development boards are generated by appliance-creator and the kickstarts live in spin-kickstarts, they take the same shape as livecds on primary but are shipped as a oem disk image, where initial-setup is used to do final user configuration. pungi generates a install tree the same as it does for primary, we are creating pxe install trees only as u-boot does not understand isofs.
For this change we will enable armv7hl builds on primary koji, and compose arm trees as with the other primary architectures. Fedora has in the Phoenix data centre 96 quad core Calxeda EnergyCore server nodes. Some of these nodes will remain allocated to the arm secondary architecture koji instance for building updates for the current Fedora 18 and 19 releases. When Fedora 18 goes end of life the ARMv5 softfp nodes will able to be be reallocated to other tasks. Infrastructure has expressed an interest in testing and experimenting with some of its workloads on ARM, some are allocated to QA and some for releng. There is currently 24 nodes configured in primary koji ready to go as builders, there is the capacity to add up to 24 more when ARM becomes primary if desired.


The kernel is now a multi platform unified ARMv7 kernel supporting a number of SoCs with support expanding with each new upstream release. We build a base and LPAE variant similar to i686. There is an ARM specific (ARMv7 and aarch64) kernel maintainer working in collaboration with the Fedora kernel team. The releases are composed using the exact same tooling as used for the primary architectures. Disk images for development boards are generated by appliance-creator and the kickstarts live in spin-kickstarts, they take a similar format as the livecds on primary but are shipped as an OEM disk image, and like primary initial-setup is used to do final user configuration. Like primary pungi is used to generate an install tree, PXE install trees are created but current bootloaders don't support isofs so ISO images aren't currently created.


== 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 functionality, what capabilities does it bring? Why will Fedora become a better distribution or project because of this proposal?-->
<!-- What is the benefit to the platform?  If this is a major capability update, what has changed?  If this is a new functionality, what capabilities does it bring? Why will Fedora become a better distribution or project because of this proposal?-->
Enables fedora to embrace the emerging arm world. There is currently servers and desktop like systems that can be used to run Fedora on. ARM systems use very little power, the OLPC XO 1.75 and newer devices are all arm based. Calxeda based servers are shipping today. We could look at having tablet spins in the future but that is currently outside the scope of this Change. we will be adopting and embracing the the future.  
Enables Fedora to embrace the emerging world of ARM devices. There are currently servers and desktop like systems that can be used to run Fedora on. ARM systems use very little power, the OLPC XO 1.75 and XO-4 are all arm based. Calxeda and Marvell based servers are shipping today with a number of other ARM server platforms announced from other SoC vendors such as Texas Instruments. In the desktop sphere there's devices being announced or available like that HP Slate 21 AIO, the Samsung Google Chromebook, the ASUS transformer devices, the Trimslice, all of which either work or in time will work. There are also dozens of different dev boards, HDMI dongles and set top boxes that will be supportable in the Fedora 20 release cycle. There could be investigation at having tablet spins in the future but that is currently outside the scope of this change. We are enabling new devices in the Fedora kernel as support lands upstream, allowing us to have a large number of ARM systems that are affordable and can run Fedora. By adopting ARMv7 as a primary architecture we will be embracing the future like other distributions are doing.


== Scope ==
== Scope ==
<!-- What work do the developers have to accomplish to complete the change 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 change 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?-->
Add armv7hl to list of arches for f20-build and future build tags in koji
Add armv7hl to list of arches for f20-build and future build tags in koji compose armhfp trees with i386 and x86_64.  Requisite build hardware already exists in phx2 and is configured to work with mainline koji.
compose armhfp trees with i386 and x86_64
Build hardware already exists in phx2 and is configured to talk to koji.
 
* Proposal owners: change the arches in koji, import the matching rawhide builds into koji. update release Engineering scripts to automatically build armhfp trees along with i386 and x86_64
<!-- What work do the feature owners 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?-->


* Other developers: submit builds as normal, in the event of unexpected build failures talk to the arm team to help debug and fix issues
* Proposal owners: change the arches in koji, import the matching ARMv7 rawhide builds into koji. Update Release Engineering scripts to automatically build armhfp trees along with i686 and x86_64.
<!-- What work do other 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?-->
* Other developers: submit builds as normal, in the event of unexpected build failures liaise with the ARM Team to help debug and fix issues.
 
* Release engineering: Will need to add armhfp to the release processes and make arm install trees and disk images with each milestone compose. Release Engineering are part of the team of people proposing the Change.
* Release engineering: Will need to add armhfp to the release processes and make arm install trees and disk images with each milestone compose. Release Engineering are the people proposing the Change.
* Policies and guidelines: armv7hl builds will be required to complete for builds to be successful in koji
 
 
* Policies and guidelines: armv7hl builds will be required to complete for builds to be successful in koji  
 
<!-- Do the packaging guidelines or other documents need to be updated for this feature?  If so, does it need to happen before or after the implementation is done?  If a FPC ticket exists, add a link here. -->


== Upgrade/compatibility impact ==
== Upgrade/compatibility impact ==
<!-- What happens to systems that have had a previous versions of Fedora installed and are updated to the version containing this change? Will anything require manual configuration or data migration? Will any existing functionality be no longer supported? -->
<!-- What happens to systems that have had a previous versions of Fedora installed and are updated to the version containing this change? Will anything require manual configuration or data migration? Will any existing functionality be no longer supported? -->
systems running Fedora 18 or 19 should be upgradeable in the same way as x86 systems are.
Systems running Fedora 18 or 19 should be upgradeable in the same way that x86 systems are.
 


== How To Test ==
== How To Test ==
Line 103: Line 95:
3. What are the expected results of those actions?
3. What are the expected results of those actions?
-->
-->
there are many different test vectors, most visible to developers will be that when they submit a build a armv7hl build happens also. Any supported arm system should work as it does today for ARM as a secondary arch.
There are many different test vectors, most visible to developers will be that when they submit a build a armv7hl build happens also. Any supported ARM system should work as it does today for ARM as a secondary arch.


== User Experience ==
== User Experience ==
Line 111: Line 103:
== Dependencies ==
== Dependencies ==
<!-- What other packages (RPMs) depend on this package?  Are there changes outside the developers' control on which completion of this change depends?  In other words, completion of another change 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 change)? -->
<!-- What other packages (RPMs) depend on this package?  Are there changes outside the developers' control on which completion of this change depends?  In other words, completion of another change 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 change)? -->
There are no special depeendencies.
There are no special dependencies.
Hardware in Phoenix is already installed, there is release engineering boxes for doing composing on, there is hardware available for QA use.
Hardware in Phoenix is already installed, there are release engineering boxes for doing composing on, there is hardware available for QA use.
 


== Contingency Plan ==
== Contingency Plan ==
Line 125: Line 116:
== Documentation ==
== Documentation ==
<!-- Is there upstream documentation on this change, or notes you have written yourself?  Link to that material here so other interested developers can get involved. -->
<!-- Is there upstream documentation on this change, or notes you have written yourself?  Link to that material here so other interested developers can get involved. -->
 
No documentation.


== Release Notes ==
== Release Notes ==
Line 134: Line 125:
-->
-->


[[Category:ChangePageIncomplete]]
[[Category:ChangeAcceptedF20]]
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->

Latest revision as of 22:51, 7 May 2014


ARM as primary Architecture

Summary

Make ARM a primary architecture. Add armv7hl to the i686 and x86_64 as arches that we build and support. This will mean that all packages supported by the ARM architecture must build for ARM to be released. With the release of Fedora 19 we have deprecated support for software floating support (ARMv5tel sfp) so the only proposed addition to primary architectures is currently ARMv7 hardware floating point 32 bit support (ARMv7 hfp 32bit).

Owner

Current status

FESCo resolution: Build ARM on primary infrastructure. Whether it is released as a primary Fedora 20 or as 'Fedora 20 for ARM' depends on how well it fulfills release criteria and functionality criteria closer to release time (+5).

Followup: Fedora for ARM32 was promoted to a primary architecture in Fedora 20.

Detailed Description

The Changing IT landscape has started to focus on greener technologies as well as cheaper mass produced devices that allow for fully functional cheap devices for lower socio-economic areas and other markets like education and "makers". ARM SoCs have traditionally been the domain of embedded and mobile applications but are now finding their way into more traditional computing devices like desktop, notebook and server markets. Fedora ARM currently works on many different devices with wider support coming with each new mainline kernel release.

For this change we will enable armv7hl builds on primary koji, and compose arm trees as with the other primary architectures. Fedora has in the Phoenix data centre 96 quad core Calxeda EnergyCore server nodes. Some of these nodes will remain allocated to the arm secondary architecture koji instance for building updates for the current Fedora 18 and 19 releases. When Fedora 18 goes end of life the ARMv5 softfp nodes will able to be be reallocated to other tasks. Infrastructure has expressed an interest in testing and experimenting with some of its workloads on ARM, some are allocated to QA and some for releng. There is currently 24 nodes configured in primary koji ready to go as builders, there is the capacity to add up to 24 more when ARM becomes primary if desired.

The kernel is now a multi platform unified ARMv7 kernel supporting a number of SoCs with support expanding with each new upstream release. We build a base and LPAE variant similar to i686. There is an ARM specific (ARMv7 and aarch64) kernel maintainer working in collaboration with the Fedora kernel team. The releases are composed using the exact same tooling as used for the primary architectures. Disk images for development boards are generated by appliance-creator and the kickstarts live in spin-kickstarts, they take a similar format as the livecds on primary but are shipped as an OEM disk image, and like primary initial-setup is used to do final user configuration. Like primary pungi is used to generate an install tree, PXE install trees are created but current bootloaders don't support isofs so ISO images aren't currently created.

Benefit to Fedora

Enables Fedora to embrace the emerging world of ARM devices. There are currently servers and desktop like systems that can be used to run Fedora on. ARM systems use very little power, the OLPC XO 1.75 and XO-4 are all arm based. Calxeda and Marvell based servers are shipping today with a number of other ARM server platforms announced from other SoC vendors such as Texas Instruments. In the desktop sphere there's devices being announced or available like that HP Slate 21 AIO, the Samsung Google Chromebook, the ASUS transformer devices, the Trimslice, all of which either work or in time will work. There are also dozens of different dev boards, HDMI dongles and set top boxes that will be supportable in the Fedora 20 release cycle. There could be investigation at having tablet spins in the future but that is currently outside the scope of this change. We are enabling new devices in the Fedora kernel as support lands upstream, allowing us to have a large number of ARM systems that are affordable and can run Fedora. By adopting ARMv7 as a primary architecture we will be embracing the future like other distributions are doing.

Scope

Add armv7hl to list of arches for f20-build and future build tags in koji compose armhfp trees with i386 and x86_64. Requisite build hardware already exists in phx2 and is configured to work with mainline koji.

  • Proposal owners: change the arches in koji, import the matching ARMv7 rawhide builds into koji. Update Release Engineering scripts to automatically build armhfp trees along with i686 and x86_64.
  • Other developers: submit builds as normal, in the event of unexpected build failures liaise with the ARM Team to help debug and fix issues.
  • Release engineering: Will need to add armhfp to the release processes and make arm install trees and disk images with each milestone compose. Release Engineering are part of the team of people proposing the Change.
  • Policies and guidelines: armv7hl builds will be required to complete for builds to be successful in koji

Upgrade/compatibility impact

Systems running Fedora 18 or 19 should be upgradeable in the same way that x86 systems are.

How To Test

There are many different test vectors, most visible to developers will be that when they submit a build a armv7hl build happens also. Any supported ARM system should work as it does today for ARM as a secondary arch.

User Experience

User experience does not change. The only difference will be the path in which they use to download files from on the mirrors.

Dependencies

There are no special dependencies. Hardware in Phoenix is already installed, there are release engineering boxes for doing composing on, there is hardware available for QA use.

Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) if for some reason we fail horribly at migrating into primary we would go back to secondary, the fix would be removing armv7hl from the build arches by Release Engineering
  • Contingency deadline: Alpha
  • Blocks release? Yes

Documentation

No documentation.

Release Notes