Architectures/ARM/Fedora15 HardFP Bootstrap
NOTE: This is a draft page in progress. I put it up so we have something, but it's not finalized yet (jcm).
We are currently engaged in early bootstrap of support for an ARMv7 "hardfp" (hardware floating point) version of Fedora 15. In addition to adding support for hardware floating point, this port makes a transition to newer variant of the ARM ABI (sometimes referred to as a new variant of the "EABI" informally, though the name "EABI" does not exist any more in official terms for ARM systems), and in particular to a newer variant of the Procedure Calling Standard for ARM Architecture AAPCS. The newer ABI (as defined in section 6 of the AAPCS) uses floating point registers as part of the procedure calling interface. We will treat "armv7hl" (hardfp, little endian) as a new target architecture. As such, it is not supported to install both armv5tel (ARMv5) and armv7hl (ARMv7) packages on the same Fedora 15 system.
- Bootstrap a minimal build-from-source of F15 packages (with Fedora patches), using the absolute minimal (not typical Fedora) configuration, such that RPM can later be used to rebuild the bootstrap package set
- Get mock, and koji up and running with the rebuilt RPM package set
- Rebuild everything with full Fedora configuration from SRPMs
The focus at this time is on getting the dependencies for a minimal rebuild up and running, with a later goal of having full mock support in place with an appropriate target in the Fedora ARM Koji.
There are various ways you can get involved. If in doubt, visit the Fedora ARM IRC (#fedora-arm on irc.freenode.net) and ask one of us for advice. You can also read more about our initial efforts to create a bootstrapped root filesystem in the git based workflow section here - please do help us by checking out the repo and following along on your board. We welcome your contribution(s), no matter how big or small to helping us get to a root filesystem sufficient for building with RPM.
- Jon Masters
- Chris Tyler
- Anthony Boccia
- Jon Chiappetta
- Paul Whalen
- Dennis Gilmore
- Brendan Conoboy
- Peter Robinson
Git based rootfs workflow
IMPORTANT: Please only perform these steps on real hardware. While emulators and cross-compilers are possible, we are doing a target-based bring up at this time. If you would like to make suggestions, please contact us. We have discussed the topic of emulation and cross-compilation many times before. We use cross-compilation to a certain extent in stage1, but we are trying to be very close to the "Fedora way" of operating, which is build on target. Therefore, please refrain from performing these steps from within a QEMU emulator, for example.
GOAL: Get the bare minimum set of packages (in a minimal build configuration - less than typical in Fedora) such that we can build rpm-build from source and get to a stage of being able to use RPM to rebuild all of the sources directly.
We have developed a workflow around a git based root filesystem. This filesystem has been created as output from running DJ's git://fedorapeople.org/~djdelorie/bootstrap.git scripts. To obtain the filesystem, run the following:
$ git clone --branch armv7hl ssh://git.fedorahosted.org/git/arm.git fedora_armv7hl_rootfs $ cd fedora_armv7hl_rootfs $ git branch armv7hl-YOUR_FAS_USERNAME
- NOTE: Make sure that you have requested access to the Fedora ARM git repository in FAS, or just replace "ssh" with "git", and send patches/pull requests rather than committing directly to your own named branch of the repository - the use of "YOUR_FAS_USERNAME" is a convenience, it is not a technical requirement, we just do not want commits on master directly please, as it helps us track things more easily.
This will create a (your) named working branch of "armv7hl", which is a root filesystem. You should export this repository directly to your ARMv7 target board using NFS, or clone it again a second time remotely onto the target. A second clone can be beneficial because you will be running various commands inside this root filesystem under the root user account on the target and probably want to avoid permission problems with running commits as a regular user (otherwise, you will need to use "chown -R username" periodically to avoid problems managing the repo as a regular user). In the case of a second clone:
$ git clone --branch armv7hl-YOUR_FAS_USERNAME fedora_armv7hl_rootfs_target
- You can do stuff as root within this and "git push" back to your main repo without permission problems (ignore the lock warning during commit unless you are sharing this repository locally, in which case you need a sudo solution or similar)
IMPORTANT: Regardless of how you provide the target with the root filesystem, it does not contain a populated /dev directory due to needing to avoid having git need to house special files. You will need to perform these steps:
mkdir dev pushd dev sudo mknod null c 1 3 sudo mknod zero c 1 5 sudo mknod tty c 5 0 sudo mknod console c 5 1 sudo mknod sda b 8 0 sudo mknod sda1 b 8 1 sudo mknod sda2 b 8 2 sudo mknod sda3 b 8 3 sudo mknod sda4 b 8 4 sudo mknod mmcblk0 b 179 0 sudo mknod mmcblk0p1 b 179 1 sudo mknod mmcblk0p2 b 179 2 sudo mknod mmcblk0p3 b 179 3 sudo mknod mmcblk0p4 b 179 4 sudo mknod ttyO0 c 253 0 sudo mknod ttyO1 c 253 1 sudo mknod ttyO2 c 253 2 sudo mknod ttyO3 c 253 3 popd
Now that you have a working copy of the armv7hl root filesystem, and have exported it to your target either over NFS (probably from a second copy as in the above scenario) or by making a remote clone using git on/onto the target you should "chroot" into this on your target (you may need to leave the chroot and re-enter if you use git commands that change the repository files remotely):
$ chroot /path/to/exported/fedora_armv7hl_rootfs_target/
On the host, edit the "stage2/stage2" script, which is a copy of the one in the bootstrap repo. In there, you will find various target "modules" (packages). Choose a package (refer to and update the real time list of work items at Etherpad) and add entries for it both to the latter part of the file, and a "go" command at the top to call it at the appropriate point during bootstrap (unless ordering matters, just as the last item in the current list). For example, there is a set of commands for db4 already in the current stage2 script:
NOTE: Make sure you updated the Etherpad with what you are working on
db4 ) mcd $BUILDDIR/db4 $SRC/db-*/dist/configure $TCONFIGARGS make $J make $J install ;;
There is a need to add a "go db4" higher in the file, in the correct position relative to the other "go" commands. In most cases, adding to the end of the list will be fine, unless ordering matters due to build dependencies - in that case, try to add a comment to this effect so that it is easier to understand why you have needed certain ordering.
On the host, you will need to download the most recent successfully built SRPM from primary arch Fedora 15 (refer to Koji to find the F15 SRPM for the package in question) to use as a seed. Extract and apply the patches required for Fedora through the use of the following commands (we don't currently keep a copy of the SRPM in the rootfs repo, since it is not really required - but we do keep the extracted sources, and so forth):
$ HOME=stage2/rpmbuild rpm -ivh /path/to/downloaded/srpm $ HOME=stage2/rpmbuild -bp stage2/rpmbuild/SPECS/package_name.spec
Ensure that, in any case (especially if you have overridden your RPM macros and the use of a HOME environment variable doesn't work for you) the extracted RPM sources, spec, and directory of fully applied bits are in place in stage2/rpmbuild (in SOURCES, SPECS, and BUILD, respectively). We will NOT change these from Fedora 15, nor make changes to them during build. All builds take place in a separate directory (stage2/builds), typically exploiting the fact that GNU Autoconf handles having sources in a separate directory from the build directory. If a particular build cannot operate in this fashion, use cp or rsync (see stage1 in the bootstrap repo for examples) to copy the bits into place in the builds/package_name directory.
After making changes to the stage2/stage2 script, you should be able to run the following from the target chroot:
$ /stage2/stage2 package_name
If you did things correctly, then the result should be a stage2/builds/package_name directory containing the build tree, and the bits should have been installed into the rootfs. If this works, please commit the changes onto your branch:
$ git commit -as new_paths_here
Then push these to any higher level repository you might have if you are working in a second copy (e.g. fedora_armv7hl_rootfs_target push to fedora_armv7hl_rootfs). Finally, with your changes on your armv7hl-YOUR_FAS_USERNAME branch, you can push this to an identically named branch on the Fedora ARM git repo, and request a merge by mailing the list (copy email@example.com with merge requests), or simply post a pull request from your externally hosted repo. You could try sending patches to the list directly, but they will likely be pretty large, so as a fallback, post a link to a patch file you are hosting elsewhere (such as fedorapeople) if you are unable to use git for this part.
Changes will be merged from various branches into the top-level armv7hl periodically. This ensures some ability to track who is making what changes, and when, and allows us to revert problematic builds. We will aim to keep this rootfs around only as long as we need it to get to the point where we have a working RPM.
We will be supporting the vfpv3-d16 architecture level as required of the optional AAPCS section 6 hardware floating point calling convention ABI. We will not be requiring vfpv3-d32 since not all ARMv7 parts implement all 32 double floating point registers and they are not required for base hardfp ABI compatibility. We will build for a Cortex-A8 optimized target, not requiring NEON, and with Thumb2 instructions disabled. Due to the way in which AAELF (ELF bindings for ARM Architecture) and AAPCS, as well as Thumb interworking are implemented, we can safely assume that Thumb2 can be enabled at the individual package level later without breaking any compatibility, or requiring other packages to be rebuilt.
Hardware floating point
Hardware floating point in ARMv7 processors takes the form of the VFPv3 (Vector Floating Point version 3) co-processor, which is a modern vector processing unit unrelated to the original ARM FPU present or emulated in earlier ARM systems.