Architectures/ARM/AArch64/zh-cn

In other languages: English (en) 中文（中国大陆） (zh-cn) [edit]

想要提问? 欢迎加入 Fedora ARM 团队的 IRC 频道 #fedora-arm on Freenode

介绍

ARM 芯片在嵌入式应用、手机和平板设备中已经取得了广泛的成功，但是直到最近 ARM 构架仅有 32 位的物理内存地址总线。作为推动 ARM 服务器（超大规模）（以及更加复杂的传统嵌入式应用）市场的初期， ARM 已经在 Cortex-A15 处理器中对 32 位构架进行了扩展以支持 40 位物理地址。这是个很大的进步，且一些厂商已经发布了成功的基于 40 位 LPAE（大物理地址扩展） 技术（包含在 Cortex-A15、更早的 Cortex-A9 处理器和符合 32 位构架的定制设计中）的 32 位 ARM 服务器平台。

译者注
根据 ARM 官网，包含 LPAE 技术的 Cortex-A 系列处理器有 Cortex-A15 和 Cortex-A7，但是未见到 Cortex-A9。

为了更广泛地向企业领域推进，需要引入 64 位构架。同时也需要在 ARMv8 架构中引入新的 AArch64 执行状态。AArch64 不是一个单纯的 32 位 ARM 构架扩展，而是 ARMv8 内全新的构架，完全使用全新的 A64 指令集。这些都源自于多年对现代构架设计的深入研究。更重要的是， AArch64 作为一个分离出的执行状态，意味着一些未来的处理器可能不支持旧的 AArch32 执行状态。 虽然最初的 64 位 ARM 处理器将会完全向后兼容，但我们大胆且前瞻性地将 AArch64 作为在 ARMv8 处理器中唯一的执行状态。我们在这些系统中将不支持 32 位执行状态， 这将使许多有益的实现得到权衡，如默认情况下，使用一个较大的 64K 大小的页面，并会使得纯净的 64 位 ARM 服务器系统不受遗留代码的影响。立即进行这种划分是很重要的，因为有可能在未来几年内将出现仅支持 64 位的服务器系统。没有必要在新的 64 位架构中去实现一个完整的 32 位流水线，这将会提高未来 ARM 服务器系统的能效。这样回想起来， AArch64 作为在 Fedora ARM 项目中被支持的 ARM 构架是一个很自然的过程： armv5tel、armv7hl、aarch64。新的架构被命名为：aarch64，这同 ARM 自己选择的主线命名方式保持一致，同时也考虑到了 ARM 架构名与 ARM 商标分开的期望。

你可以在 ARM 官网中找到更多关于 | ARMv8 Architecture 的资讯。

本文档记录了让 Fedora 支持 ARMv8 架构内的 AArch64 执行状态的初步工作， 始于 Fedora 17 的 bootstrapping。 未来发布的 Fedora 将同时支持 ARM 实现的 64-bit 处理器核心 - 如新的 Cortex-A57 - 以及向第三方（如 Applied Micro）定制的 64 位核心。 A demonstration of the initial bootstrap has already been given on the latter hardware, expected to be available in 2013. The goal is to support an initial Fedora 19 remix on real ARMv8 silicon, with a more complete Fedora 20 release. As soon as we are able to acquire production servers for PHX, we will also establish a formal ARMv8 build system in Phoenix. Until that time, Red Hat will internally host the initial ARMv8 build hardware, once it becomes available. In the initial bootstrap, the software Foundation Models are used, as described below. We will also collaborate with both Linaro and the Linaro Enterprise Group, as part of a broader Linux community effort to support the new 64-bit architecture.

Bootstrap 过程

从本质上讲, AArch64 bootstrap 遵循与 ARM HardFP Bootstrap（用于 ARM Fedora 15 ）相同的流程。早期 F15 的流程本身就是为了 AArch64 而设计的，所以这种相似也是有意而为之。

一切努力的目的就是使 Fedora 在 ARMv8 上运行，并使用 ARM 定义的标准 64 位 ABI。值得庆幸的是，不同于 ARMv7 以及之前的构架， 对于 ARMv8 仅有一个 ABI (详情请见 AAPCS for 64-bit)。

所有东西都存放在一个地方
请注意：所有 ARMv8 bootstrap 工作的资料和文件都存放在 http://fedorapeople.org/groups/armv8. 如果你需要写权限，请联系维护者 Al Stone 。

目标

我们的目标是完成 bootstrap "阶段" (1,2,3,4,5,6) ，这些阶段意味着根文件系统达到我们预计的一定功能水平，开始于非常基本的交叉编译、然后进行本地编译，并最终是完成一个可以工作的 mock 和 Koji 配置，以使其能够编译软件包。

当前阶段: 我们已经完成了阶段 1-3，并正在处理第 4 阶段.

Bootstrap 工具

再次利用之前完成的在 HardFP 上的移植工作， 我们再次使用并修改了先前 DJ Delorie 所写的几个必要的脚本。这些脚本存储在一个 Git 仓库中，并可按照如下步骤检索：

$ git clone http://fedorapeople.org/groups/armv8/bootstrap.git

当然，我们欢迎您提交补丁。

短暂的 git 问题
如果上面的 URI 不起作用，请尝试:

$ git clone git://fedorapeople.org/~ahs3/bootstrap.git

第 1 阶段 - make

状态: 基本完成

第 1 阶段是一个在 x86_64 宿主机上使用源码（并非SRPM）交叉编译的初始阶段，制作最小的 aarch64 软件包集。目标是创建最小的 chroot 环境， 使其足以构建更复杂的第 2 阶段软件包。这意味着提供原生版本的 GCC、binutils、glibc，加上一些基本的工具，如 gzip、patch 和 awk，以及其他一些软件。 第 1 阶段的成果包含这些工具和一个 BusyBox 环境（以取代 chroot 的使用需求，还有另一种可能性，例如使用 OpenEmbedded Linaro 的镜像，并在其中运行 rootfs），这些工具提供了大部分正常开发所需的 Linux 命令。它不包含超出本地编译阶段所需的最小软件集合（仍然不包含RPM）的软件。

如果你已经可以通过 PATH 访问 ARMv8 的交叉编译器，并且那些交叉编译器被命名为 aarch64-redhat-linux-gnu-*，你就应该可以通过以下步骤再次创建所有第 1 阶段软件：

$ git clone http://fedorapeople.org/groups/armv8/bootstrap.git
$ cd bootstrap
$ mkdir f17-local
$ scp username@fedorapeople.org:/project/armv8/SRPMs/f17/changed/* f17-local
$ ln -s f17-local SRPMlocal
$ mkdir f17-sources
$ scp username@fedorapeople.org:/project/armv8/SRPMs/f17/unchanged/* f17-sources
$ ln -s f17-sources SRPMs
$ ./stage1

如果你没有以上交叉编译器，你将需要修改第 1 阶段的脚本，以指向正确的编译器。

更多信息:

• 第 1 阶段笔记
• 任务列表:
  • [ahs3] Package and make available the Linaro aarch64 cross-toolchain [处理中]
  • Kernel needs to be brought up to date -- either upstream 3.7 with patches, Linaro AArch64, or something similar [TODO]
  • Binutils has had several aarch64 patches added in the last few weeks [TODO]
  • GCC patches should be re-examined for possible updates [TODO]
  • Glibc patches probably need to be updated to latest upstream [TODO]
  • Investigate and resolve additional rpath info needed for cloog. Why? [TODO]
  • Investigate and resolve additional rpath info needed for libselinux. Why? [TODO]
  • Investigate and resolve additional rpath info needed for sed. Why? [TODO]
  • [ahs3] Make sure any changes made go back into upstream, where appropriate [INPROGRESS]
  • [jcm, ahs3] Resolve cross-distribution compatibility issues, switch fully to /lib64; now rebuilding with updated toolchain [DONE]
  • [jcm] Resolve issues with architecture features in binutils/toolchain

第 2 阶段 - rpmbuild

状态: 完成

第 2 阶段 has the goal of getting a working native build of RPM (rpmbuild) running within the rootfs. This includes enough packages built from source (not from SRPMs, but on the target) to get a working "rpmbuild" binary sufficient to rebuild RPM and other packages. The output from this is the ability to build native RPM packages.

更多信息:

• 第 2 阶段笔记
• How To Use the ARM Foundation Model -- instructions for using what is currently the only publicly available platform simulator for ARMv8 with the rootfs built in stage1 (which is how one builds stage2 results)
• 任务列表 (these all need to be built in dependency order):
  • [ahs3] publish patchify scripts [DONE] -- see git://fedorapeople.org/~ahs3/patchify.git
  • [ahs3] Gdb FTBFS -- newer upstream patches available? NB: latest rebuild worked fine for no obvious reason [DONE]
  • [ahs3] Upstream patches? Perl, nspr, to date [INPROGRESS]
  • [ahs3] Gettext FTBFS [DONE]
  • [ahs3] Build chkconfig [DONE]
  • [ahs3] Build sqlite [DONE]
  • [ahs3] Build pth [DONE]
  • [ahs3] Build openssl [DONE]
  • [ahs3] Build popt [DONE]
  • [ahs3] Build libffi [DONE]
  • [ahs3] Build pkgconfig [DONE]
  • [ahs3] Build glib2 [DONE]
  • [ahs3] Build nss-util [DONE]
  • [ahs3] Build nss-softokn [DONE]
  • [ahs3] Build nss [DONE]
  • [msalter] Build elfutils [DONE]
  • [msalter] Build rsync [DONE]
  • [msalter] Build fakechroot [DONE]
  • [msalter] Build file [DONE]
  • [msalter] Build ustr [DONE]
  • [msalter] Build libusb1 [DONE]
  • [msalter] Build libusb [DONE]
  • [msalter] Build tzdata [DONE]
  • [msalter] Build redhat-rpm-config DONE]
  • [msalter] Build rpm [DONE]
  • [msalter] Build cracklib [DONE]
  • [msalter] Build libsepol [DONE]
  • [msalter] Build attr [DONE]
  • [msalter] Build acl [DONE]
  • [msalter] Build libsemanage [DONE]
  • [msalter] Build pam [DONE]
  • [msalter] Build shadow-utils [DONE]
  • [msalter] Build strace [DONE]
  • [msalter] Build filesystem [DONE]
  • [msalter] Build iso-codes [DONE]

第 3 阶段 - mock

状态: 完成. 并不是所有软件包都被编译，但是足以开始使用 mock 编译。

Stage 3 is the effort to get a minimal set of useful buildroot RPMs sufficient to rebuild the buildroot and have a working yum, mock configuration. RPMs will be manually built with rpmbuild and uploaded to a shared central rootfs repository.

At stage3, it may be necessary to intentionally disable certain unnecessary features of RPMs, and GNU autotools (and so on) will automatically exclude certain features dependent on non-present functionality. Consequently, these RPMs will not be final and must be rebuilt in the following stages.

更多信息:

• 第 3 阶段笔记

Stage3 rootfs currently contains dependencies needed to run mock. Current effort is focused on adding packages needed in the mock chroot. Complicating this is a desire to update to glibc 2.17 and gcc 4.8 which are the first upstream releases with AArch64 support. See glibc notes in Stage3 Notes for details. Because of switch to glibc 2.17, all previously built stage3 packages need to be rebuilt. Also, packages built without rpmbuild will need to be rebuilt as RPMs so they can be part of the stage4 repo used by mock. In parallel with building packages needed for base mock chroot, some packages are being built in an effort to be able to build documentation. This generally needs a number of X packages, etc. These packages are not strictly necessary but will allow more packages to be built without patches to avoid docs.

The current rootfs still uses busybox for /sbin/init and is a general mess because of the nature of the bootstrap. Packages have been installed with --nodeps and --force and in non-standard order. The rootfs does include a build of systemd but /sbin/init is still linked to busybox. Using the systemd /sbin/init does boot to a login prompt but the login fails for some reason. This could be something simple or something more complicated due to missing packages or other issues with the rootfs. It may not be worth fixing in the current rootfs because we have, or almost have, enough packages to replace the current root with one created by a yum install of aarch64 RPMs.

• 所需软件包列表:
  • [msalter] kernel-headers [DONE]
  • [msalter] glibc-2.17 [DONE]
  • [msalter] gcc-4.8 [DONE]
  • [msalter] filesystem [DONE]
  • [msalter] bzip2 [DONE]
  • [msalter] coreutils [DONE]
  • [msalter] bash [DONE]
  • [msalter] cpio [DONE]
  • [msalter] swig [DONE]
  • [msalter] libcap-ng [DONE]
  • [msalter] audit [DONE]
  • [msalter] shadow-utils [DONE]
  • [msalter] diffutil [DONE]
  • [msalter] dbus [DONE]
  • [msalter] libxslt [DONE]
  • [msalter] libutempter [DONE]
  • [msalter] util-linux [DONE]
  • [msalter] opensp [DONE]
  • [msalter] openjade [DONE]
  • [msalter] glib2 [DONE]
  • [msalter] ncurses [DONE]
  • [msalter] acl [DONE]
  • [msalter] attr [DONE]
  • [msalter] byacc [DONE]
  • [msalter] bison [DONE]
  • [msalter] zlib [DONE]
  • [msalter] chrpath [DONE]
  • [msalter] check [DONE]
  • [msalter] cracklib [DONE]
  • [msalter] curl [DONE]
  • [msalter] deltarpm [DONE]
  • [msalter] e2fsprogs [DONE]
  • [msalter] binutils [DONE]
  • [msalter] elfutils [DONE]
  • [msalter] expat [DONE]
  • [msalter] fipscheck [DONE]
  • [msalter] gawk [DONE]
  • [msalter] procps-ng [DONE]
  • [msalter] make [DONE]
  • [msalter] libICE [DONE]
  • [msalter] libSM [DONE]
  • [msalter] libXau [DONE]
  • [msalter] gettext [DONE]
  • [msalter] gnupg2 [DONE]
  • [msalter] libxcb [DONE]
  • [msalter] libXdmcp [DONE]
  • [msalter] gpgme [DONE]
  • [msalter] texinfo [DONE]
  • [msalter] keyutils [DONE]
  • [msalter] libX11 [DONE]
  • [msalter] freetype [DONE]
  • [msalter] libXt [DONE]
  • [msalter] krb5 with ldap [DONE]
  • [msalter] libarchive [DONE]
  • [msalter] libassuan [DONE]
  • [msalter] libcap [DONE]
  • [msalter] libcroco [DONE]
  • [msalter] fontconfig [DONE]
  • [msalter] libXrender [DONE]
  • [msalter] libXft [DONE]
  • [msalter] libXext [DONE]
  • [msalter] libXfixes [DONE]
  • [msalter] libXdamage [DONE]
  • [msalter] libdb [DONE]
  • [msalter] libXmu [DONE]
  • [msalter] libgcrypt [DONE]
  • [msalter] libgpg-error [DONE]
  • [msalter] tk [DONE]
  • [msalter] libksba [DONE]
  • [msalter] gdbm [DONE]
  • [msalter] libpng [DONE]
  • [msalter] libsepol [DONE]
  • [msalter] readline [DONE]
  • [msalter] libtool [DONE]
  • [msalter] libffi [DONE]
  • [msalter] libunistring [DONE]
  • [msalter] libuser [DONE]
  • [msalter] libxml2 [DONE]
  • [msalter] lua [DONE]
  • [msalter] lzo [DONE]
  • [msalter] m4 [DONE]
  • [msalter] nss-util [DONE]
  • [msalter] nss-softokn [DONE]
  • [msalter] ruby [DONE]
  • [msalter] nss [DONE]
  • [msalter] libselinux [DONE]
  • [msalter] popt [DONE]
  • [msalter] qrencode [DONE]
  • [msalter] pciutils [DONE]
  • [msalter] pth [DONE]
  • [msalter] usbutils [DONE]
  • [msalter] sed [DONE]
  • [msalter] gperf [DONE]
  • [msalter] sharutils [DONE]
  • [msalter] pigz [DONE]
  • [msalter] pkgconfig [DONE]
  • [msalter] systemd [DONE]
  • [msalter] pcre [DONE]
  • [msalter] libidn [DONE]
  • [msalter] imake [DONE]
  • [msalter] gc [DONE]
  • [msalter] cmake [DONE]
  • [msalter] wayland [DONE]
  • [msalter] libpciaccess [DONE]
  • [msalter] openssl [DONE]
  • [msalter] cyrus-sasl [DONE]
  • [msalter] openldap [DONE]
  • [msalter] libXpm [DONE]
  • [msalter] libjpeg-turbo [DONE]
  • [msalter] gd [DONE]
  • [msalter] xz [DONE]
  • [msalter] patch [DONE]
  • [msalter] tar [DONE]
  • which
  • [msalter] chkconfig [DONE]
  • cloog
  • [msalter] llvm [DONE]
  • [msalter] dwz [DONE]
  • [msalter] file [DONE]
  • gdb
  • [msalter] gnutls [DONE]
  • kmod
  • [msalter] libssh2 [DONE]
  • p11-kit
  • [msalter] pam [DONE]
  • [msalter] perl [DONE]
  • pinentry
  • policycoreutils
  • [msalter] python [DONE]
  • [msalter] shared-mime-info [DONE]
  • [msalter] sqlite [DONE]
  • [msalter] tcp_wrappers [DONE]
  • [msalter] ustr [DONE]
  • ? others ?

第 4 阶段 - 发行版 bootstrap

状态: 处理中.

At Stage 4 we will run a complete mock rebuild of the distribution, identifying and solving dependency and platform build issues. With those out of the way, we will switch over to koji while waiting for the koji and yum changes needed to correctly support the new architecture type. This stage will absolutely require the presence of real ARMv8 hardware for completion.

The result of stage4 is threefold:

1. The set of packages needed for running Koji
2. A set of SRPMs which actually can build some form of F15, or sufficiently large part of it.
3. A set of binary RPMs that can be used initially by koji while doing the first koji rebuild of the distribution

更多信息:

• Stage4 Notes

第 5 阶段

状态: TODO

Complete rebuild of the distribution using koji

第 6 阶段

状态: TODO

At this point we should have koji-shadow running automatically shadowing the main koji.

加入我们

有许多不同的方式加入我们. 如有疑问，请访问 Fedora 的 ARM IRC 频道(#fedora-arm on irc.freenode.net) 并咨询我们其中的一员.

参与者

• Al Stone
• Jon Masters
• Chris Tyler
• DJ Delorie
• David Marlin
• Dennis Gilmore
• Brendan Conoboy
• Peter Robinson
• Chen Baozi
• Mark Salter
• Jaromír Cápík
• Paul Whalen
• 你的名字可以在这里!

任务列表

In the sections above are task lists for the various stages. These are the ones we currently know about. If you have further suggestions, let us know on IRC or the fedora-arm mailing list where we can discuss them and figure out how they fit into the overall scheme of things. As part of that discussion, we'll decide if and how it gets added to the lists. As you'll notice, there is a marker in front of each task (well, sometimes) and a marker at the end of each task (always). The marker at the end should be one of TODO (meaning the task has not been started by anyone), INPROGRESS (implying someone is actively working on it), or DONE (um, well, the task is done :). If the task is INPROGRESS or DONE, there should be a marker at the front indicating who is doing the work (e.g., ahs3 is Al Stone's nick on IRC).

If you're looking for something to do, find a task that is marked TODO, and edit this page to show that you're working on it. If someone has put their nick on the task, please ask them first and share nicely like grown-ups. For example, change the line:

   * grizzle the fingo [TODO]

to this:

   * [myNick] grizzle the fingo [INPROGRESS]

And when you've completed the task, change it to:

   * [myNick] grizzle the fingo [DONE]

基于 Git 的 Rootfs 工作流程

For stages 1 through 3, we are coordinating work using the git repository at http://fedorapeople.org/groups/armv8/rootfs.git.

IMPORTANT: Please do work using only the ARM Foundation model. While cross-compilers are possible, we are trying to stay as close as possible to doing a target-based (i.e., real hardware) bring up at this time. We use cross-compilation in stage1, but we are trying to be very close to the "Fedora way" of operating, which is build on target. For the time being, the ARM Foundation model is as good as it gets. As soon as hardware becomes available, we will make this more stringent and insist all stage2 and later work being done on real hardware.

IMPORTANT: Build flags, and similar options are defined in the stage1 and stage2 scripts. In stage1/stage2, please do not enable or alter architecture features that are not required for minimal bootstrap, and especially DO NOT do not change build flags and such as those that are defined globally in the RPM packages (rpm, redhat-rpm-config, fedora-release...).

• http://fedorapeople.org/groups/armv8/rootfs.git -- just pull the master branch

Our workflow is centered around the above git repository -- a copy of the current state of the rootfs. You will need to clone this git repository and then build a disk image from it; instructions can be found in How To Use the ARM Foundation Model. If you can do so and make your git clone publicly visible, you can then send pull requests to the fedora-arm list for review and incorporation. If you cannot make your clone publicly visible, please send a git diff of the SRPM changes made to the fedora-arm list; after review and incorporation, we will build from the source changes and incorporate the binaries back into the rootfs also (sending the binaries to the list would just be painful).

使用 ARMv8 模型

ARM provides two different platform simulators that can be used to run AArch64 binaries; the FAST model is under strict license and not generally available. The Foundation model is binary only, but still accessible to anyone who wishes to use it (see http://www.arm.com/fvp). Instructions for using the models are here:

• Using the ARMv8 Model with an NFS Root
• Using the ARMv8 Model with a Disk Image

Getting one or the other of these working is a prerequisite for assisting in this effort.

Kernel command lines are hard-coded
In both of the cases above, the models use a '.axf' file. This file provides a basic boot environment for the model. However, the kernel parameters in the .axf file are hard-coded when it is created. If you need to change them, you can either ask on #fedora-arm and if someone has time, they can build you a custom one. Or, the more straightforward (and likely quicker) way is to create your own custom .axf using the patch tool found at git://fedorapeople.org/~ahs3/patch-axf.git. Do a git clone of that repository and follow the instructions in the README.

协助完成第 1 阶段

The results of the first three stages of the bootstrap are being kept in a rapidly growing and quite large git repository that can retrieved via:

$ git clone http://fedorapeople.org/groups/armv8/rootfs.git

This was seeded with stage1 results and the current stage2 results that were built using the scripts found here:

$ git clone http://fedorapeople.org/groups/armv8/bootstrap.git

All of the source that was used can be found at http://fedorapeople.org/groups/armv8/SRPMs/f17. The directory unchanged contains the SRPMs that are unchanged from the source one can get from the Fedora 17 sources. The directory changed contains all the Fedora 17 (or in some cases, 18) SRPMs that had to change to build.

If you have access to cross-compilers for ARMv8 in your PATH, and those cross-compilers are named aarch64-redhat-linux-gnu-*, you should be able to recreate all of stage1 with the following:

$ git clone http://fedorapeople.org/groups/armv8/bootstrap.git
$ cd bootstrap
$ mkdir f17-local
$ scp username@fedorapeople.org:/project/armv8/SRPMs/f17/changed/* f17-local
$ ln -s f17-local SRPMlocal
$ mkdir f17-sources
$ scp username@fedorapeople.org:/project/armv8/SRPMs/f17/unchanged/* f17-sources
$ ln -s f17-sources SRPMs
$ ./stage1

If you do not have cross-compilers with names of the form given above, you will need to edit the stage1 script to point at the right places.

If you wish to contribute changes to the stage1 SRPMs or the bootstrap scripts, please submit either a git diff for the package needing to be changed, or a git pull request from your clone of the repository, to the fedora-arm mailing list for review and ultimately incorporation into the proper git repository by the maintainer (ahs3).

NB: better access to RPMs for the x86_64 cross-toolchain for aarch64 is being worked on. In the meantime, tools can be found at Linaro.

协助完成第 2 阶段

Stage2 builds upon the rootfs originally created in stage1 and found here:

$ git clone http://fedorapeople.org/groups/armv8/rootfs.git

Short term git problem
If for some reason the URI above does not work, please try:

$ git clone git://fedorapeople.org/~ahs3/rootfs.git

To use this rootfs as a native build environment, we have to use the platform simulator provided by ARM -- the ARM Foundation model. Instructions on using the model with the rootfs are found here: How To Use the ARM Foundation Model. Once you have booted the model with the rootfs, you'll be presented with a console running BusyBox. From there, running stage2 is very straightforward:

$ cd /stage2
$ ./stage2

The stage2 script uses makefile snippets defined /stage2/recipe.d and stage2/recipe.mk to order which packages get built in what order. You can modify that order by either (a) cheating and marking something as done by creating the proper file in /stage2/done (e.g., 'touch /stage2/done/gdb' lets stage2 continue past the build for gdb even though it currently fails), or (b) the more difficult route of modifying the makefile snippets directly.

If you wish to contribute changes to the stage2 SRPMs or the bootstrap scripts, please submit a git diff for the package needing to be changed, or a git pull request from your clone of the repository, to the fedora-arm mailing list for review and ultimately incorporation into the proper git repository by the maintainer (ahs3).

后续阶段

Stage3 will look a lot like a larger stage2, and hopefully have more hands involved. And while it is okay at this point to disable sub-packages like "docs", or to turn off functionality like selinux, or audit requirements, do not disable features that will be required by other packages directly in order to get a minimally working mock buildroot established. If in doubt, ask on #fedora-arm for advice.

Starting in stage4, we will be able to drop the use of the rootfs from git and work from real images. Stages 4-6 will start to look more like a normal Fedora release, hopefully.

目标标志

No special flags are required at this time.

硬件浮点运算

Hardware floating point in ARMv8 processors is considered standard and not optional. Hence, no special options are required.