Difference between revisions of "Fedora ARM Secondary Architecture/Research Plan/Summer 2010"

From CDOT Wiki
Jump to: navigation, search
(Current Candidate Configuration)
(Goals)
Line 2: Line 2:
  
 
= Goals =
 
= Goals =
 +
 +
In collaboration with the Fedora project and other open source projects:
 +
# To build the Fedora Linux distribution for computers based on the ARM processor.
 +
# To keep current with the software builds taking place on the Fedora primary architectures.
 +
# To provide input into the Fedora packaging process and to the design of specific packages with respect to building on ARM.
 +
# To develop tools for using Fedora on ARM devices (e.g., compose and loading tools).
 +
# To advance the state of the art of software on low-power devices.
 +
# To support new ARM devices well, with specific emphasis on the upcoming OLPC XO 1.75.
  
 
= Specific Objectives =
 
= Specific Objectives =

Revision as of 17:34, 8 April 2010

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

Goals

In collaboration with the Fedora project and other open source projects:

  1. To build the Fedora Linux distribution for computers based on the ARM processor.
  2. To keep current with the software builds taking place on the Fedora primary architectures.
  3. To provide input into the Fedora packaging process and to the design of specific packages with respect to building on ARM.
  4. To develop tools for using Fedora on ARM devices (e.g., compose and loading tools).
  5. To advance the state of the art of software on low-power devices.
  6. To support new ARM devices well, with specific emphasis on the upcoming OLPC XO 1.75.

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