On Wed, Mar 7, 2012 at 3:39 AM, Wookey
<wookey@wookware.org> wrote:
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).
I've been using the armel (and earlier ABI) on my NSLU2 (slug) for several years now. I actually never really understood much about the Debian port to ARM, other than it just worked well for me. My interest in the RPi has got more involved in understanding the differences between different versions of the ARM and why different ports are needed. Recently I've been poking around the Debian armel distribution provided recently by the RPi foundation with QEMU to understand it further.
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.
Thanks for clarifying the terminology. I really don't want to do a 'port', but rather as you describe, a set of optimizations under the existing armhf port. Is there a standard way to describe or name such an effort so as to avoid confusion? Such as 'armhf-v6' or 'armhf-rpi'?
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.
It's looking like it will be another month or two before I get actual RPi hardware in my hands to make any benchmarks, but I assume if I got my hands on a Freescale i.MX535 Quick Start board I could make the same measurements there. My personal motivation for this is threefold: I'm looking at creating gaming environments to teach kids programming that would potentially be FPU intensive, I have an interest in using the RPi in robotics where physics libraries would benefit from the FPU and finally as a learning experience and to contribute back to the Debian community. Looking at the RPi forums, it seems a Linux distribution optimized to the RPi hardware would gain a lot of traction in what could be a significant new group of Linux users. Making Debian that distribution would be nice.
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.
Understood. How would one make the cost/effort vs benefit analysis on this? Seems simply recompiling all armhf supported packages for ARMv6+VPF2, while still a lot of work, is a relatively straightforward process of just learning the build tools and getting it done. Creating a HWCaps-aware dpkg would require a lot more judgment and experience with Debian that a newcomer such as myself lacks.
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).
I hate the ugly package-namespace mechanisms as it is very unfriendly to less experienced users who would be confused by what they need to install and use. For new Debian users, such as I expect many RPi users to be, I would very much like to simply supply a SD card image with the essential parts of Debian, the sources.list pre-populated with repositories with RPi optimized packages, and let the user use 'apt-get' to their hearts content knowing that whatever they pull over is RPi optimized.
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.
I'm a little confused by some of the terminology above, but I think I get what you are saying.
Ideally, for an RPi user, I would like to supply an RPi SD card image with Debian (or Debian installer) and whenever they use apt-get all packages are pulled from a custom repository. In that repository, all packages would the compiled to the ARMv6+VPF specifics of the RPi hardware. It seems to me that would be most user friendly approach rather than mucking about with package-namespace stuff.
To make this happen, I would need to choose either armel or armhf with the appropriate optimizations, and then use Debian autobuilders to build the repository the user above would use to pull all their packages from. Whether the repository might be hosted by the Debian archive would be an open question.
Am I describing this in a way that makes sense? I presume that Reprepro+rebuildd+sbuild is what would make the build of the RPi tuned respository possible.
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.
I'm very happy you've done this as it makes my NSLU2 still relevant and useful as a low power utility device.
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.
With actual RPi hardware still being 6 to 8 weeks out, would a Freescale i.MX535 Quick Start board allow such benchmarking? I presume an armel install of Debian and compiling certain packages with VFP2 optimizations would be pretty straight forward. Is armhf in such a state that it would be easy to bring up on the board as well?
Thanks again for the detailed response. Sorry if it just lead to more questions on my part. I'll start using Google on some of the terms such as autobuilders, buildd, reprepro, rebuildd, and sbuild to understand what those tools do in the scheme of things.
Mike