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.