Ubuntu Wiki

• Launchpad Entry: mobile-karmic-armel-toolchain

• Created: 2009/06/24

• Contributors: Loïc Minier

• Packages affected: qemu, gcc-4.4, binutils

Summary

Discussion of karmic toolchain changes and associated dependencies.

Release Note

The 9.10 armel port requires for 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 rip the most benefits of this hardware.

User stories

TBD

Assumptions

TBD

Design

The toolchain need 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.

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.

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.

UI Changes

N/A

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

Include:

• data migration, if any
• redirects from old URLs to new ones, if any
• how users will be pointed to the new way of doing things, if necessary.

Test/Demo Plan

It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release. Please add an entry to http://testcases.qa.ubuntu.com/Coverage/NewFeatures for tracking test coverage.

This need not be added or completed until the specification is nearing beta.

Unresolved issues

This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.

BoF agenda and discussion

Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.

CategorySpec