F30 System-Wide Change proposal: uEFI for ARMv7

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



(This change was originally proposed for Fedora 29, but was pulled
from that release. The Change proposal is unchanged, but I am
re-circulating it for visibility.)

https://fedoraproject.org/wiki/Changes/uEFIforARMv7

== Summary ==

Move to uEFI as the default boot mechanism for ARMv7 devices.

== Owner ==
* Name: [[User:pbrobinson| Peter Robinson]]
* Email: pbrobinson at fedoraproject dot org

== Detailed Description ==
Currently ARMv7 uses extlinux to boot the kernel on ARMv7. This has
served us very well and has allowed us to standardise the ARMv7 boot
process with the vast majority of devices booting this way OOTB due to
the support being in a wide variety of u-boot releases. Over recent
years there have been a number of improvement to uEFI including robust
support in u-boot. We've supported uEFI on aarch64 as the only way of
booting Fedora supporting both Tianocore, proprietary uEFI
implementations and since Fedora 27 we've supported uEFI via u-boot
too. The uEFI provided by u-boot is now stable enough that we can now
move ARMv7 to this method too allowing us to move ARMv7 to grub2-efi
and have a single standard booth path/stack for both ARMv7 and
aarch64.

== Benefit to Fedora ==
This allows ARMv7 to move to grub2 providing the same experience to
ARMv7 users as all other architectures across the distribution. It
simplifies a number of software stacks across the distribution due to
being able to use a single install/support/upgrade path as well as
providing a single set of docs.

== Scope ==
* Proposal owners: Patches, updates to the process, testing
* Other developers: System component owners will need to review and
merge patches for certain components.
* Release engineering: [https://pagure.io/releng/issue/7606 #7606] (a
check of an impact with Release Engineering is needed)
** List of deliverables: N/A
* Policies and guidelines: N/A I don't believe this changes any
policies or guidelines
* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
Upgrades from prior versions of Fedora will continue to work as they
do currently. Devices booting with extlinux will continue to upgrade
and work as planned. For recent (F-25 and later) clean installs there
will be a documented migration process for those that wish to migrate
to grub2 boot process. For older installs (those without a VFAT
partition for firmware) will need to do a clean install. Devices with
non Fedora built u-boot will need to ensure they have a recent enough
u-boot to support the required uEFI functionality.

== How To Test ==
The process for testing will be the same as aarch64. This process will
be further updated and expanded once all the components are in place
and the final process is known.

== User Experience ==
The user experience will be the same as uEFI on aarch64 and x86_64
with the grub2 menu and features. This will provide a consistent
experience across all Fedora architectures and resolves a number of
issues seen with the basic extlinux menu system on ARMv7.

== Dependencies ==
There's patches need for the following software in Fedora:
* anaconda stack - anaconda/blivet/lorax
* build dependencies - oz/imagefactory
* grub2-efi build for ARMv7
* support in virt stack - virt-manager/virt-install

== Contingency Plan ==
* Contingency mechanism: Revert back to current extlinux boot process.
The support for this process will remain and these images will
continue to be built along side the new images until we're certain the
new boot process is robust.
* Contingency deadline: Beta Freeze
* Blocks release? Yes
* Blocks product? IoT

== Documentation ==
Yes. There will need to be a review of the documentation pertaining to
ARMv7, in a lot of cases this will be deleting the old process so the
universal distribution defaults are the only docs.

== Release Notes ==
To be written once process is complete

-- 
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux