On Wed, Mar 07, 2012 at 09:32:05AM -0800, Mike Thompson wrote:5~ > > 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'? 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. On Wed, Mar 07, 2012 at 10:37:14AM -0800, Mike Thompson wrote: > On Wed, Mar 7, 2012 at 10:07 AM, Lennart Sorensen < > lsorense@csclub.uwaterloo.ca> wrote: > > You can certainly run armel, armhf and armWhateverYouNameIt in chroots > > on an i.MX53 (I have helped with armel issues while running armhf using > > chroots and it works fine since the armhf kernel can run everything). > Useful to know the kernel is independent from the ABI. I would have > thought that wouldn't be the case, but I guess it makes sense as user code > doesn't directly 'call' the kernel. It's been 25+ years since I've had my > OS classes. There's a particular reason why this is true for armel vs. armhf. The difference between armel and armhf ABIs lies entirely in the calling convention when using floating point arguments, and there are no syscalls that take floating point arguments, let alone using floating point registers to pass them. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature