Re: Questions regarding armhf port for Raspberry Pi
+++ Mike Thompson [2012-03-06 18:22 -0800]:
> I am potentially interested in creating/maintaining a Debian port that would
> mirror the work being done in armhf, but with the port tuned to the specifics
> of the Raspberry Pi hardware which I believe is ARMv6+VFPv2. The goal would be
> a Debian distribution on the Raspberry Pi which would squeeze the most
> performance possible from the CPU/MPU on the $25 to $35 device. It seems that
> such an effort could piggyback off the efforts of those working on armhf so it
> could be managed by a small group of volunteers.
As you presumably know we already have 2 arm parts. The armhf arm
v7+VFP3 (using FP registers in calling convention and thumb2
instructions) and the armel v4t (using softfp FP emulation and only
non-FP registers in calling convention).
Only armel will work unchanged on the RPi, and that is the Debian
distro currently used on these device, and what we expect people with
v6 chips to use. The armhf ABI will work onthe RPi, but the packages
would need to be rebuilt to not use the extra v7 or VFP v3
instructions. That is a CPU optimisation, like rebuilding for i486
instead of i586, not a new ABI, and thus not a new Debian
architecture/port.
The first thing you need to decide is whether there is enough speedup
from rebuilding/optimising for armv6 to make it worth doing. For
FP-intensive work there could be significant speedups. For everything
else it probably makes no odds.
Just rebuilding a few packages that matter to use VFP instead of
FP-emulation and sticking to armel would get you almost the same
speedups for a whole heap less work. It would be good if Debian had
HWCaps-aware dpkg to make this transparent (automatically picks
packages optimised for your hardware), but that work has not been done
- only vaguely specced. Your platform might be a good reason to work
on it.
> First, is there an existing group of volunteers already looking to support the
> Raspberry Pi hardware in this manner? If so, I could look to lend a helping
> hand rather than trying to duplicate working being done by others that
> potentially have much more experience/knowledge of what would be involved.
I don't know. Debian is expecting Pi users, like all pre-v7 hardware
owners, such as all the *plug devices, to use the armel port, in the
same way that the 'offical' fedora distro is v5, softfp. If there is
enough enthusiasm for producing optimised packages then that could
happen within the port if the HWCaps infrastructure is sorted, or just
using the current fairly ugly package-namespace mechanisms (like
mplayer-i686 - you can have libogg-vfp2).
> Second, where would I start to understand what is involved with creating a
> Debain port that supports a specific set of hardware such as the Raspberry Pi.
> Obviously the archive management and autobuilding tools will have to learned.
> Hopefully this path has been followed enough that it s fairly well documented
> and not tribal knowledge.
Actually making a whole new port is a big deal, and in this case
probably unnecessary. Your rebuild will not be a new port whatever
happens - it might be a rebuild of one of the two existing ports with
different optimisations. This is technically an easier job. In fact in
theory it is very straightforward, but it's not something well-tested
so there will be some breakage to fix.
If you did do it as a whole new repo then reproducing the actual
Debian build infrastructure is currently unecessarily hard work. In
practice people use the 'ports' infrastrucutre for unofficial ports,
and that would be the easiest way to get it done:
http://www.debian-ports.org/
It is not clear at this point that such a rebuild has any prospect of
inclusion in the archive at this stage so you'd have to ask if the
ports people would host it. It might make sense in order to do the
rebuild and test whether it really makes any odds.
It shouldn't actually be hard to make your own debian autobuilders and
work is ongoing to make it easy to set up local builders. I can
discuss that with you at greater length if you wanted to do that.
Reprepro+rebuildd+sbuild can make a simple rebuilder fairly
straightforward to do.
> Third, beyond time to learn everything involved and organize whatever other
> volunteers might help, what would be required in terms of hardware, network
> bandwidth, etc A person I ve communicated with on the Raspberry Pi forums
> indicated that cluster of six Freescale i.MX535 Quick Start boards with SATA
> hard disks may be enough to get started with. If figure this could probably be
> had for about $2000 or perhaps less.
Yep That makes a pretty good current buildd setup. The limited RAM
means they struggle with a few really big packages like firefox and
chromium, but in general they work well. The just-coming now imx6s are
much better (2G RAM) but hard to get hold of at this moment.
> Finally, what high-level things should be thought through before starting such
> a project. I m certain many projects like this get started all the time just
> to whither on the vine for various reasons. I would like to avoid that
> scenario if possible.
I've covered the basic questions about the pointfulness and some of
the techical aspects of this above.
We do always try to accomodate all popular hardware at Debian, which
is why our armel port is still being built for v4t rather than v5,
until v4t machines really are no longer significant. v6+VFP2 hardware
is a slightly awkward spot between the new basline and the old one.
The first thing you need to do is some benchmarking to work out
whether you should be using
* plain armel (trivial, but some performance loss on some specific tasks - how much?)
* armel + some VFP2 optimised packages (quite easy, but room for
improvement in how debian handles this sort of thing)
* v6+vfp2 rebuild of armhf (a lot of work - does it make enough odds
to be worthwile?). This should be easier than it is, and I'd like to
see tools improvements that make it so. Easy buildd set-up plus
dpkg-buldflags ought to 'just work' for most packages, but in practice
I expect we are not quite there. Work in this area is welcome.
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
Reply to: