Quite a few things happened recently around Debian/ARM; some random news follow
Thanks to the efforts of Riku Voipio, ARM and Canonical have
generously provided us with bunch of fast “armel” machines and
hosting at ARM Holdings Ltd, the hardware specifications are in
db.debian.org . Four of these are now buildds, bringing the total
of armel buildds to seven. In other words, “armel” should no longer
lag behind other architectures when building unstable packages.
One of the machines (abel.debian.org) has been setup as a porter box.
It is faster (around 3x) than the older porterbox (agricola). All
Debian Developers have access to the porter boxes.
The new buildds have allowed us to enable more suites. Thanks to
Philipp Kern’s work, “armel” builds now “experimental”,
“lenny-volatile”, “lenny-backports” as well as
“unstable/non-free”. Especially if you are “stable” Debian user,
access to backports and volatile should make life easier.
Hardfloat ARM port
The next big thing is the hard-float ARM port  (aka “armhf”) effort
being lead by emeritus Debian Developer, Konstantinos Margaritis,
hired by Genesi (markos). First do note that the “armel” port is NOT
going away! The majority of ARM CPUs sold today still don’t have a
floating point unit (FPU), so the soft-float port (“armel”) will
still have a long life ahead. Meanwhile, the “armhf” port will
provide a more optimised platform for people with the latest ARM cores
(ARMv7 + VFP) shipping on mobile phones and netbooks, with powerful
multimedia and graphics support. There has been some debate about the
relative merits of an ABI-incompatible new port that maximises speed
gains over a slower armel-compatible port/build optimised for ARMv7 +
VFP + Thumb2, and various alternative courses have been proposed to
keep compatibility and improve performance. However, “armhf” is
currently the only solution being actively worked on.
Konstantinos announced on debian-arm  a temporary “armhf”
repository  available from his site. “armhf” porting work is
slowly migrating to debian-ports.org which received a hardware
donation for additional storage from Genesi-USA.
If you have capable hardware and would like to try out the “armhf”
port, we are currently evaluating and trying to benchmark “armhf”
against “armel” (both in Debian and Ubuntu), we would be happy to
hear about your results on the debian-arm mailing list . So far
“armhf” shows a clear gain over “armel”.
Linaro is a not for profit organisation sponsored by manufacturers
with interest in ARM and with engineers from a variety of companies
(ARM, Freescale, IBM, Samsung, ST-Ericsson, Texas Instruments,
CodeSourcery and Canonical) to accelerate and improve ARM development.
 It does both upstream work notably on the toolchain and on the
kernel, and distro-like integration work.
The “armhf” port currently uses the Linaro toolchain instead of the
FSF one because of missing support for hard-float in FSF GCC 4.4. The
Linaro toolchain is based on the FSF toolchain and features ARM
patches from Sourcery G++ as well as new developments, backports, and
bug fixes. This toolchain is currently used in Ubuntu x86 and ARM
architectures, and the packaging is done by Matthias Klose, just like
for the FSF toolchain; it would be painless to opt to use it for the
“armel” port, the toolchain maintainer simply expects the Debian ARM
porters to request this change if that’s their wish, but has no
opinion on using Linaro GCC on Debian “armel”. Almost all patches
are going into FSF GCC upstream and the “armhf” port could switch to
GCC 4.5 when it’s ready, but that could take some time. However,
Matthias would not like to use Linaro GCC on other architectures than
ARM (except perhaps SH4); x86 in particular should not use a different
toolchain branch, since x86 is generally the reference platform.
Another option is to put Linaro patches into Debian GCC source, but
not actually enabled by default to make it easy to use for those that
Linaro works on many other ARM topics relevant to Debian: multiarch,
cross-compilers (in partnership with the Debian Embedded team), root
file systems for ARM devices based on Debian/Ubuntu; find out more on
their website .
It is possible to provide optimised libraries for specific hardware,
but questions still remain on which approach is the best and most
scalable one. How could Debian integrate optimised libraries for ARM
“debian-installer” should gain support for installation onto MTD
NOR/NAND Flash in the partitioner. Support for custom kernels would
also be nice.
Outside of the buildds and debian-ports storage mentioned earlier,
Debian received donations in the form of developer boards.
* ARM hardware donations:
* 2 Nvidia Tegra2 dev boards (jeremiah, spyro)
* Genesi hardware donations:
* 14 EfikaMX TO3 (fixes NEON hardware bug)
* 6 EfikaMX TO2 (has a NEON hardware bug, suitable for buildds)
* 2 x 2TB Hard-disk for debian-ports.org (aurel32)
* EfikaMX (TO3) to Debian project:
* Debian-Edu (vagrant, jonas, h01ger)
* Debian-Embedded (codehelp, zumbi)
* Debian-Live (dba)
* Debian-Kernel (maks, tbm)
* Debian Qt/KDE (svuorela)
* Debian Installer (otavio)
* Debian ARM hf port (Clint, lool, markos)
* EfikaMX (TO2)
* Buildd network cluster: 15xTO2 (markos, zumbi)
Genesi for hardware and manpower support and ARM for hardware donations.
Many other individuals involved in Debian/ARM (you know who you are)
and many other companies related to Debian/ARM effort.
 One random machine’s specifications
 http://www.linaro.org/ http://wiki.linaro.org/
– Héctor Orón “Our Sun unleashes tremendous flares expelling hot gas into the Solar System, which one day will disconnect us.” — Day DVB-T stop working nicely Video flare: http://antwrp.gsfc.nasa.gov/apod/ap100510.html