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? http://tuomas.kulve.fi/blog/2008/05/17/gcc-options-and-floating-point/

  • 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.

    - http://linuxdevices.com/news/NS6658204257.html - http://www.marvell.com/

• 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: http://mojo.handhelds.org/

  • - Feisty Fawn - Gutsy Gibbon - Hardy Heron (in progress)
• ARMv5EL, ARMv6EL-VFP

• CELF presentation (22MB): http://mojo.handhelds.org/files/HandheldsMojo_ELC2008.pdf

Toolchain

• 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

Java

• 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
  • Qemu nowadays supports also pxa and Nokia n8x0 boards

  • http://qemu-arm-eabi.wiki.sourceforge.net/ works with new eabi

• 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).

Bootstrapping

Installer

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

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.

Community

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