Fedora ARM Secondary Architecture/Research Plan/Summer 2010

This is a draft only!
It is still under construction and content may change. Do not rely on this information.

Specific Objectives

Fedora ARM Koji Farm

• Evaluate and select hardware options for a Koji farm for the Fedora ARM Secondary Architecture
  • Current candidate: 15-20 GuruPlug Server systems, with one quad-core PC for storage and Koji Hub/Koji Web
• Set up the Koji build farm in collaboration with the Fedora ARM community

Factors to Consider

• Network layout
  • Koji-Hub, Koji-Server, and resulting software repository must be accessible both inside and outside Seneca
  • ARM builders must be able to communicate with the Koji-Hub
  • ARM builders must be able to communicate with shared file storage
  • ARM builders must have local storage or a SAN (e.g., iSCSI) or shared, high-performance file storage

Current Candidate Configuration

• 15-25 GuruPlug Servers
• iSCSI SAN for storage
• Quad-core PC to run Koji-Hub, Koji-Web, and master repository

Koji-Shadow

• Configure Koji-Shadow so that packages built for the Fedora primary architectures are also built for Fedora ARM
• Sync up with F13 and Rawhide builds

Package Set Maintenance

• Update packages as necessary with ExcludeArch tags where those packages are not suitable or cannot be built on ARM architecture

Bugzilla

• Get the bugzilla admins to rationalize the ARM processor options in the platform list (right now there are a number of ARM options, none of which accurately reflect the ARM build: arm7, arm9, xscale, strongarm).
• Actively monitor bugzilla for platform-related problems

Testing

• Acquire a number of ARM hardware devices and test the ARM build on those devices:
  • SheevaPlug
  • OpenRD-Client
  • GuruPlug
  • Beagleboard
  • Hawkboard
  • TouchBook
  • OLPC XO 1.75

Optimization

• Optimize the Fedora ARM Build
  1. Identify optimization opportunities
  2. Create and test optimized builds
  3. Make decisions on which optimizations should be default
  4. Create additional subarchs are appropriate (e.g., armv5, armv7 or with/without FPU)

Compose

• Create root filesystems
• Write tools to load popular products (e.g., tool that would be run on a PC to connect to a SheevaPlug and load NAND)
• Write a tool to compose a custom root filesystem formatted for a specific device (e.g., SD card image, tftp file set)

Kernel

• Investigate creating a single kernel or a small set of kernels that would work on a variety of devices, rather than a custom kernel-per-device
• Use initrd (dracut) and modules to handle the differences between devices