[ Please note the cross-post and Reply-To ] Hi folks,
Here's a summary of what we discussed in the ARM ports BoF [1] last week (10th July). Thanks to the awesome efforts of the DebConf video team, the video of the session is already online [2] in case you missed it. I've also attached the Gobby notes that were taken during the session. Again, thanks to the people who took part - we had a very useful discussion. Slides are up on my website [3]. armel ===== First released with Lenny. Soft-float EABI, Software floating point assumed by default. v4t which also runs smaller-size thumb instruction set. Targeting old hardware like openmoko. Discussed (again!) moving forwards from v4. Declared that v5 is no faster than v4t, but there are doubts elsewhere in the community. Later discussion suggests moving to v5te would be worth it. Some good benchmarks would help - volunteers welcome! armhf ===== First release will be Wheezy. Targets ARMv7 (latest released version of the ARM family), VFPv3-D16, hard-float version of EABI, assumes hardware floating point unit. Benchmarks show that you get anything from 0 to 20% improvement in real-life code, depending on workload. In any case, you should lose nothing. New agreed standard for ARM Linux, in use across all the distros supporting ARM. Mono does not do useful floating point (yet!), still looking for somebody to help here. libffi issues with variadic functions using floating point. buildds ======= Both armel and armhf are doing well, covering ~96% of the archive. We don't have any ARM server hardware yet, so we're stuck using development boards as build machines. They work, but they're a PITA for hosting and they're not designed for 24x7 usage like we're doing so they're not that reliable. armel currently using a load of Marvell Feroceon dev boards (v5), armhf on Freescale imx53 dev boards. Both sets of machines are limited in terms of memory, meaning the common large C++ apps are painful to build - linking in swap! elsewhere (starting close, moving further out) ============================================== Raspbian -------- Unofficial Debian port for the Raspberry Pi. Built (mostly) using Debian source packages, but targeting ARMv6 hard-float. Works well and forwards-compatible with official (v7) armhf. Not being considered for inclusion into the main Debian archive - we already have two ARM ports. Great work from the folks involved, and we'd love to work with them and help wherever possible. Pi is problematic for kernel and non-free graphics drivers... Ubuntu ------ Ubuntu has 2 ARM ports released with 12.04 (LTS): armhf for v7 hard-float and armel for v7 soft-float. armel is slowly being re-targeted / rebuilt for v5 instead (no point in having both ports on v7 only). OpenSUSE -------- OpenSUSE developers are doing 2 ARM ports. Concentrating on v7 hard-float, with a lower priority v5 soft-float port. Hoping for a release with 12.2. Fedora ------ Fedora developers are doing 2 ARM ports. Concentrating on v7 hard-float, with a lower priority v5 soft-float port. Did a release of F17 with ARM, but beware of linker path issues. Ongoing discussions in Fedora about whether or not ARM will end up becoming a "primary architecture". As/when/if it does, expect a RedHat release for ARM. Mageia, Gentoo, ChromeOS, Android also doing ARM Linux work with varying amounts of overlap with what we're doing in Debian. New stuff ========= Newer versions of ARM hardware and software are coming, with new features and requirements that will be useful and we should look into supporting: * virtualisation extensions * LPAE (large physical address extensions) - allows for a 32-bit system but with larger amounts of memory available on the system. Each process still limited to 4GiB address space, but along with virtualisation could be very useful for large servers * UEFI: standard boot architecture and boot loaders. Device tree and ACPI coming too. Should be able to use a single kernel image to support most new hardware once this work filters down. Very useful as commodity ARM-powered machines become more readily available instead of application-specific setups like phones. * ARMv8 - 64-bit capable. More information in the next talk! [1] http://penta.debconf.org/dc12_schedule/events/870.en.html [2] http://meetings-archive.debian.net/pub/debian-meetings/2012/debconf12/high/870_ARM_ports_update.ogv [3] http://www.einval.com/~steve/talks/Debconf12-arm-ports/ -- Steve McIntyre, Cambridge, UK. st...@einval.com "Every time you use Tcl, God kills a kitten." -- Malcolm Ray
Please take notes here (not an official ARM talk) armel ===== First released with Lenny. soft-float EABI. v4t which also runs smaller-size thumb instruction set. Targetting old hardware like openmoko. v5 is no faster than v4t. Software floating point assumed. armhf ===== First release will be Wheezy. v7 (latest released version of the ARM family) VFPv3-D16. Hardware floating point. Benchmarks show that you get anything from 0 to 20% improvement in real-life code. In any case, you lose nothing. New agreed standard for ARM Linux. Mono does not do useful floating point. libffi issues variadic functions using floating point. buildds ======= Around 96% coverage, similar to armel. Lack of arm servers, so far. Use development boards. Marvell Feroceon for armel, Freescale im53 for armhf. 1Gb of RAM, which is an issue for huge C++ apps that have to the linking in swap. Elsewhere ========= Raspbian: unofficial ports for Raspberry pie. v6 hard float, forward compatible with armhf. Ubuntu port was v7 soft float, downgraded to v5 soft float armel. Added armhf 12.04 LTS release. OpenSUSE: focus on v7 hard float. Low priority v5. Possible 12.2 release. Fedora: F17 release but problems with linker path. RedHat: likely to wait for Fedora to decide on a primary architecture. Mageia, Gentoo, ChromeOS, Android. New stuff! Virtualisation: servers. LPAE: still 32bit with support for large physical address extension (bigmem) UEFI: standard boot architecture / bootloaders. Use UEFI with device tree & ACPI. More new stuff: ARMv8, 64 bit capable. Next talk. Graphics acceleration: free drivers? most x86 vendors are starting to open up. For ARM: no good reason why but most players will not share. Some reverse engineering happening but binary blobs will remain for now. Common amongst distros to have multiple ARM ports - need to support FreedomBox, GuruPlug, SheevaPlug etc. v7 is needed for the performance advance. 64bit ARMv8 should be durable.