Re: Questions regarding armhf port for Raspberry Pi

[Mike Thompson <mpthompson@gmail.com>]

On Wed, Mar 7, 2012 at 2:28 PM, Steve Langasek <vorlon@debian.org> wrote:

For all intents and purposes, this *is* a new port.  This can't just be done
as a set of optimized libraries on top of armhf, because the baseline for
the armhf port is ARMv7 so none of these packages are guaranteed to run on
RPi, *including ld.so*.  Likewise, you could build it on top of armel as a
set of v6-optimized add-ons to the v4t port, but then you wouldn't be able
to use the hard-float ABI - you could still use all the VFP you want, but
you'd pay the marshalling penalty on function calls.

So if you really care about getting the most out of the hardware, you're
looking at an entirely new port.

You could probably reuse the armhf name (and ld.so path), though that
carries some risk that a user will break their system if they ever point to
a Debian (or Ubuntu) armhf repository.  However, this is no different than
if someone wanted to recompile the Debian i386 port to support i486 CPUs
again; it wouldn't be wrong to reuse the 'i386' port name for that.

I wanted to follow up on my query two weeks ago about creating a port of Debian armhf with adjustments to work well on the Raspberry Pi CPU/VFP hardware.  I still can't claim to be very knowledgeable about what the process might involve, but I certainly do know more than I did two weeks ago.  Since then, I've acquired an iMX53 Quick Start Board and now have a basic install of Debian Wheezy armhf running on it.  I'm also now familiar with how to rebuild Debian packages individually in chroot environments or using tools such as pbuilder.  

My goal is that by time RPi hardware is shipping I hope to have enough RPi compatible hard float packages built to create a minimal install using debootstrap, install build-essential and perhaps a smattering of other packages to demonstrate and experiment with performance improvements of hard float compiled software.  Reviewing the packages needed to accomplish this, it will probably involve compiling a minimum of 250 packages, but perhaps quite a bit more to include build dependencies.  I would be using the armhf packages as a starting point which will hopefully allow the compilations to go smoothly, hopefully this isn't too ambitious.

To get things started, I've built a new gcc-4.6 package in wheezy with the configuration changes needed for it to create RPi compatible armhf binaries.  A nice 24-hour compilation cycle :-(.  Comparing against the existing armhf settings for Debian and Ubuntu, I made the following changes (as specified in the Debian configuration rules2 file for gcc-4.6):

Standard Debian armhf flags:

--with-arch=armv7-a --with-float=hard --with-fpu=vfpv3-d16 --with-mode=thumb

Standard Ubuntu armhf flags:

--with-arch=armv6 --with-float=hard --with-fpu=vfpv3-d16 --with-mode=thumb

RPi Flavored Debian armhf flags:

--with-arch=armv6 --with-float=hard --with-fpu=vfp (--with-mode=thumb not specified)

Using this newly build GCC, my preliminary testing indicates the resulting binaries are fully compatible with existing armhf binaries -- ie. they can be installed on and will on a standard armhf system even though they are compiled using ARMv6+VFP.  I was a bit worried that the calling conventions of the float ABI will be different between vfp3-d16 and vpfv2, but they appear to be the same.  I guess the same registers used for parameter passing are available on both.

With some very simple benchmarks, the difference in execution between armv6+vfp and armv7+vfp3-d16+thumb2 looks to be relatively minor -- less than 10% or so.  I'm looking around for some better benchmarks to use to get some better of the speed impact.

A complication I have is that I don't yet have RPi hardware and I'm not likely to get any for at least another 4 to 6 weeks, if then  This will mean a lot of compilation before hand and the risk it will have to be thrown away if the binaries for some reason don't run on the RPi hardware.  I wonder if there is a way to configure QEMU to simulate the RPI CPU/VFP to minimize this risk.

If I can accomplish getting a minimal hard float version of Debian running on the Raspberry Pi as describe above, I'm hoping that it will generate enough interest in both the Debian and RPi community to get a real Debian port effort initiated.  This of course depends on the RPi being successful in its own right, but I have a feeling that this will occur.  It would be nice if Debian were to become a top-tier Linux distribution for this amazing $40 device, some thunder I think the Fedora folks are stealing right now.

Any thoughts or suggestions would be appreciated.  In the meantime I'll keep plodding along to better understand how to accomplish the goals outlined above.

Mike Thompson