From Fedora Project Wiki

[ARM] Fedora15 HardFP Bootstrap Virtual FAD - 2011/06/10

We wish to accelerate the bringup of Fedora 15 on ARMv7 systems running with hardware floating point (hardfp). To that end, it is proposed to have semi-regular bootstrap days, during which we will meet in a virtual capacity (on IRC, and over the phone) to build up through cross-compilation (and other means) the core packages required for Fedora 15 to become self-hosting on ARMv7 with hardware floating point.

When and Where

14:00 UTC, Friday June 10th 2011

IRC: #fedora-arm on

Phone: We used a temporary bridge

Etherpad: (including full list of international dialin numbers)

Event owners



NOTE: Procedure for joining in with this post-activity day is documented on Architectures/ARM/Fedora15 HardFP Bootstrap

  • We kicked off with a discussion around build flags and confirmed the current plans
    • Building with a Cortex-A8 optimized, hardfp target (aapcs, vfpv3-d16), no NEON, no Thumb2
    • We may rebuild with different core optimizations in the future, may enable Thumb2
    • Probably will not worry about NEON initially
  • We reviewed various build dependencies we had available
    • Determined that tools for graphing and obtaining this stuff need improving
    • DJ provided an updated depsolving tool later in the day that was helpful
    • An initial attempt at a list of dependencies for RPM is in Etherpad
    • Determined we want to bring up rpm (rpm-build) at this stage
  • We determined a workflow based around a rootfs image in git
    • (ssh:// - see the "armv7hl" branch on that repo
    • Based on DJ's git:// (output from a run of stage1/stage used as seed)
    • Individual people/groups to create branches named armv7hl-NAME and request merge on list (Jon Masters maintaining)
    • Each person/group picks a package at a time to bootstrap (edit the Etherpad to add your package status before/during/after - including changing the list of remaining packages/done packages)
    • Collaboratively edit stage2/stage2 (copy of version in bootstrap, to be synced back later)
    • Explode out new package rpmbuild bits into stage2/rpmbuild before/after adding rule to stage2/stage2
    • Packages build in stage2/builds and are installed to the git repo rootfs under a chroot
    • Mount this rootfs git repo and chroot on target, run /stage2/stage2 TARGET (where TARGET is e.g. "db4", "readline", etc.)
    • Ensure general rules are present in stage2 script in the "go" sections to call targets in order
    • Later will verify the bootstrap scripts still run, but use this rootfs git approach to speed up bootstrap
    • Contribution will continue to this repo - post pull requests/push to armv7hl-NAME branch
  • We added more than a dozen bootstrap packages but more importantly worked out a workflow/model going forward
  • Continue this effort and repeat the activity day.
  • PROPOSAL: Next activity day on Wednesday June 22.


  • Summarize requirements/sync up on build flags
    • Build for Cortex A-8, with AAPCS, and hard float (vfpv3-d16, not -d32)
    • Do not enable NEON (can add later)
    • Do not enable Thumb2 (confirmed can non-disruptively enable per-package later)
  • Current status of works in progress (DJ/Dennis/Seneca(?)?)
    • Plan will be to use DJ's bootstrap.git as a starting point
    • Extend stage2 script to on-target build up dependencies for rpm-build
    • Stash archives of populated build directories/bits on
  • Minimal dependency discussion for F15
  • Plan for building/co-ordinating builds
    • Follow instructions for setting up DJ's bootstrap script and minimal rootfs (target chroot)
    • Grab a few package dependencies and work on them (add support to stage2 script)
    • Tar up the resulting build tree and make them available to others
    • Others install build tree ("make install") on their rootfs
    • Once sufficient deps are done for rpm, rebuild things as RPMs
    • host bits on
    • Stage a Koji F15 instance with the working RPMs
  • Status before end of day
  • Plan for followup


  • Internet connection to log into IRC, and phone if possible (phone not essential)
  • A supported ARMv7 target board
  • Lots of coffee


  • A pre-requisite is a working ARMv7-compatible supported target board, such as a BeagleBoard or a PandaBoard.
    • You can find out more from the main Fedora ARM pages about obtaining a pre-built rootfs (no installer yet)
    • We now have some Fedora ARM kernel packages for OMAP-based boards
  • Bootstrap will involve using a partially completed rootfs image that will be used inside a chroot
    • Since the new "arch" (armv7hl) is supported by ARMv7 kernels we can use a chroot trick
    • A complete from-scratch new arch port would need an also bootable rootfs (but it's not quite that)
    • Your normal target rootfs will be the stock F-13 rootfs in this case (so boot target as normal, then use chroot)
  • Fetch DJ's bootstrap.git repository
    • You will be making changes to the stage2 script (a copy of it in your rootfs)
    • Post patches and pull requests during the day for new packages
  • Fetch the partially bootstrapped rootfs (progress to date, built using bootstrap scripts)
  • Extract the root filesystem into a new directory and copy over to your board
    • Or mount over NFS from a server system (e.g. export /data/work/arm/bootstrap/f15/20110610/rootfs from a server to your board)
    • Optionally bind mount a directory within the rootfs (e.g. on an NFS server mount -o bind /data/work /data/work/arm/bootstrap/f15/20110610/rootfs/data/work) to allow you to get at data outside the chroot if you want to stash builds somewhere
  • Chroot into the new target rootfs
    • chroot /data/work/arm/bootstrap/f15/20110610/rootfs (or wherever you extracted it)
  • Take a look at the /stage2/stage2 script
    • Run it with a "module" name to build a particular package
    • /stage2/stage2 nspr
  • Modify the stage2 script to support building additional packages in the target rootfs
  • Post patches and git pull requests to the Fedora ARM mailing list ( (the stage2 script is kept in the bootstrap.git and a copy is in the rootfs)
  • Once sufficient packages are bootstrapped to support rpm, rebuild packages using RPM
  • Further dialog on package build deps and next steps