Re: Questions regarding armhf port for Raspberry Pi
+++ Mike Thompson [2012-03-22 10:50 -0700]:
>
> 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.
It's quite a lot of work, but there shouldn't be much breakage to deal
with given the minor changes so it looks do-able to me.
> 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
>
> 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.
That's right. This is deliberate to keep things compatible, so
ARMv6+VFP binaires should indeed run fine with ARMv7+vfp3-d16
binaries. (On v7 hardware).
> 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.
Look at some of the cases used to justify the armhf port. Some of
those may emphasis the differences, but in general they shouldn't be
dramatic. I'm not sure what the pathological cases for v6, no thumb,
vfp2 are. Hmm, failing to find the details for that (it'll be in an
old debian-arm thread, but doesn't seem to be on
http://wiki.debian.org/ArmHardFloatPort . povray was one interesting
case I recall.
> 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.
No idea about qemu, but there are some arm binary checker tools which
look for 'wrong' instructions. I'm sure someone sent me a copy. Might
need a bit of adjustment but could at least somewhat assure yourself
that you didn't have v7 or thumb instructions in your output. Finding
some other v6 hardware to text on might be useful too. Someone here
probably has some.
> Any thoughts or suggestions would be appreciated.
You seem to be doing a fine job. Keep it up.
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
Reply to: