MobileKarmicArmelToolchain

Summary

Discussion of karmic toolchain changes and associated dependencies.

Release Note

The 9.10 armel port requires ARMv6 and VFP and is optimized for Cortex A8.

Rationale

The Ubuntu armel port targets use cases such as netbook for upcoming ARMv7 hardware. The toolchain needs to be setup for the highest family as possible to reap the most benefits of this hardware.

Design

The toolchain needs to be setup to output code for the oldest ARM CPU we want to support, while still tuning for the most common we want to support.

buildds (including livefs builders) need to be able to run the generated code (as is often the case across package builds or when building images).

The consensus is to support down to ARMv6 and to tune for ARMv7 (Cortex A8 by lack of anything more generic), and to require a VFP unit (hardware FPU).

Implementation

First, setup buildd network supporting the ABI, then switch the toolchain to output the new ABI, finally rebuild key packages which would benefit from the optimizations.

The rationale for v6 and not v7 is to support N8x0 CPUs and other devices from that era.

Buildd network

ARMv7 buildd-class hardware is hard to find. The current Marvell ARMv5 buildds are exactly what we want on the long term but aren't available for ARMv7 just now.

ARMv7 hardware considered:

  • TI EVM: no official Ubuntu kernel, only 256 MB of RAM, didn't test mini-USB attached storage, SD storage, slow CPU
  • TI Beagleboard: no official Ubuntu kernel, only 256 MB of RAM, USB storage should work, delays to get enough boards, to prepare kernels, and to install them in the DC
  • Babbage "1": larger set is available but needs time for shipping, 512 MB of RAM, USB underpowered (affects SATA as well), SD storage
  • Babbage 2: not enough boards, 512 MB of RAM, USB storage should work, no Ubuntu kernel
  • Babbage 2.5, 3.0: similar as Babbage 2, too late in the cycle
  • Snapdragon: no Ubuntu kernel, RAM amount and availability unclear

General issues with storage implementation:

  • SD storage is slow and available cards might be too small for a buildd rootfs (16 GB currently)
  • network storage doesn't work too well for buildds; IS had bad experience with using NFS; NBD might be more stable but relatively slow

Another option is Qemu; it's probably the best option even if it's slower and has drawbacks as the Qemu buildd setup can also serve PPAs (Qemu with Xen) while using real hardware doesn't help with supporting PPA builds (no Xen on armel).

So for the interim, Qemu; as soon as new v7 hardware suitable to act as a buildd comes up we can reconsider to move to that.

Qemu setup

IS would ideally run Qemu 0.9 as DC machines usually run hardy.

Qemu 0.9 is much faster by default than 0.10 which is faster than current Qemu tip. One possible explanation is the use of O_DIRECT in qemu by default which should be disabled for buildds (we can requeue a build). The TCG switch might be another explanation.

Qemu >= 0.10 causes SATA errors in the guest on some hosts, but not on all which makes it hard to reproduce and hence debug + fix. AdamConrad should provide LoicMinier with access to a machine with the issue for research. This renders >= 0.10 unsuitable for buildd usage.

Only some Qemu boards support v6 or v7 CPUs.

Qemu claims to support Realview, but the real ARM Realview have no PCI bus and neither does the Linux kernel, so Qemu Realview is useless as the Qemu network and SCSI adapters are on the PCI bus.

Qemu tip supports SMP which would tremendously help for large packages, but Qemu and the Linux kernel only supports that on Realview, with a v6 MP CPU.

Qemu Versatile is probably the best target along a cortex-a8 CPU for a buildd setup but only supports 256 MB of RAM. LoicMinier worked on various sets of patches to support more RAM; 768 MB is done, up to 1024 MB probably achievable.

When using Qemu >= 0.10, it should be setup with a suitable cache= parameter.

Qemu >= 0.10 can be used as soon as it's ready for production.

Toolchain

gcc-4.4 and binutils should be configured for -march=armv6 and optimized for -mtune=cortex-a8; the FPU configure flag should be -mfpu=vfp.

Package rebuilds

Key packages will be reuploaded multiple times as part of their development anyway, so no need for reuploading just for the toolchain changes (Linux, GNOME, Firefox, Openoffice.org, toolchain...) other keu packages which have an impact on overall speed should be re-uploaded manually after the toolchain changes.

Some attention should be paid to the number of rebuilds of the toolchain: at least a couple would be good to make sure it's fully self-buildable, and optimized.

Code Changes

  • Qemu / Linux SCSI driver should be fixed.
  • Qemu should be changed to allow using up to 1024 MB of RAM with Versatile.
  • (optional) Qemu Realview could gain a PCI bus.
  • (optional) Qemu Versatile could gain SMP support.

Migration

  • Setup and test new buildds with hardy's qemu 0.9
  • Replace ARMv5 buildds in the pool with qemu ones
  • Rebuild some key packages which don't get uploaded frequently

Test/Demo Plan

Run the port on v7 hardware, verify it works, compare how it performs with Jaunty.

Unresolved issues

  • real hardware for v7 buildds
  • Qemu SMP support

CategorySpec

Specs/MobileKarmicArmelToolchain (last edited 2009-06-25 11:17:45 by serris)