Not UME flavor, full Desktop.

To be discussed

  • Build infrastructure
    • Native.
      • - Native is safer than cross, but cross works in some cases, we will use native.
  • hardware:
    • - data center, count TDB depends on compile spees. Need to test. Developer:
      • UME Team - 5 machines. Kernel Team 2 machine Bryce for X 1 machine
  • Launchpad setup (trivial)
  • Nokia port ? Looked at but not going to work for a maintainable Debian based distro.
  • Toolchain
    • Java
  • Kernel
  • Bootstrapping
  • Bootloader: uboot?
  • Security updates
  • Which ARM flavour(s)? 11, 9, Cortex? Endianness? (little)
    • ARM V4T (ARM9) and V6 (11) would be interesting. V4 to help gather community as it's widespread.
    • EABI-only (no-brainer)
    • floating point support? VFP?

    • if multiple ARM flavours are to be supported, the userspace implementation should still be written to a least-common-denominator ABI/instruction set, with optimization limited to kernel/glibc builds. Building multiple armel ports is largely untenable - spreading resources too thin
  • What machine/boards?
    • Who provides drivers for full SoC support?
    • Is JTAG required for initial bringup, or is bringup completed by vendor?

Build infrastructure

  • Number of machines not really an issue, as many as is required to build in same time as X86 based distro.
  • Requirement from IS to have at least 512 MB RAM (more is nicer)
  • No PPA unless we have some form of replacement for Xen
  • New Marvell motherboards go up to 1 GHz / 1.2GHz dual core, should be enough; support
    • DDR-2 800 MHz, so likely
    • Available in dual-core varieties as well, assuming kernel support
    • not on market yet, still just sampling
    • we could try getting some dev boards
    • As a reference point, these would be faster by far than our HPPA buildds, which keep up fine Want as much RAM as machine can handle.

      - -

  • Will need additional porting machine(s) for developers, given lower performance
  • TODO: build a package on a target ARM machine, compare build time with the
    • same package on i386 and estimate the number of buildds needed
  • We should be OK if the hardware can compare to our HPPA build systems

Developer hardware

  • Who needs hardware? (Doko and lool have some hardware, may not be correct type.)
  • We can consider using qemu; Riku said it gives sensible results
  • distcc seems to work, if that would help improve throughput
  • We could host some qemu for developers on fast hardware (Fedora is also doing this)
  • No cross-compiling; not there yet. Cross compiling might bring some problems to packages like Python, during its "configure" phase.
  • Does it need video output? OpenGL support?
  • Might need to be careful about the smaller subset of OpenGL (OpenGL ES)

Launchpad setup

  • Need someone from LP

Nokia port

  • Built using the Debian "arm" architecture; built in multiple flavors
  • Identified that the Debian way of handling architectures makes it hard to support many ARM subarches / toolchains
  • Targetted the smallest number of modified packages
  • Could perhaps be a candidate chroot base to start bootstrapping Ubuntu armel, but the Debian armel port looks like a better candidate
  • Nokia is doing native compilation:

    • - Feisty Fawn - Gutsy Gibbon - Hardy Heron (in progress)
  • CELF presentation (22MB):


  • Mike mentioned floating point issues in the toolchain, pre-eabi
  • We need to decide on softfloat, we don't want to build packages twice; vfp gives quite better floating point performance, but is rare and not available on all chips
  • Current Debian toolchain builds for ARMv4t
  • Nokia has added logic in debian/rules for vfp and thumb, but it's easier for us to just set these via our default LDFLAGS/CFLAGS infrastructure


  • Need some... Will require on-going support for this. Requires on-going support in the rest of the ports.

Kernel / ARM flavours

  • Depends on which SoC we are going to support
  • Interest for new and fast ARM hardware, less in older enthusiast hardware
  • Likely to only support a single SoC
  • ARM11 port is mainline upstream
  • Amit suggested tracking Russell's tree and sub-arch tree (e.g. omap, orion)
  • Debian has flavors for versatile, orion (orion5x), thecus (iop32x), and slug (ixp4xx)
  • As we'll be using qemu, we should have a versatile flavor
  • Probably still value in having userspace support for older/obtainable hardware, even if we
    • never bother to provide kernel support (This would be of special interest in the LTSP community).



  • Need to check Ubuntu bits in d-i of the partitioner and the bootloader


  • We don't really want to update the bootloader which usually has hardware specific bits by the manufacturer
  • If you break the bootloader, you usually break the hardware except on some rare devices

Security updates

  • Need hardware, if officially suported no real issue, if not other steps may be required.


  • If we want to grab community attention, we can't focus only on the newest boards available.

MobileAndEmbedded/ARM-EL-port (last edited 2008-08-06 16:28:27 by localhost)