Re: Questions regarding armhf port for Raspberry Pi
On Wed, Mar 07, 2012 at 09:32:05AM -0800, Mike Thompson wrote:
> 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.
>
> 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'?
You certainly don't want to put rpi in there. That's too specific and
leaves out other machines that would work the same way. The v6 would
be closer. Do all ARMv6 machines have VFP2-32?
> 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.
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).
So yes you could build and test the performance to some extent, although
the i.MX53 doesn't perform the same way as the pi would, but it should
give you a rough idea of the speed difference between armel and a
rebuilt armhf.
> 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.
Both involve work. If any packages in armhf specifically have assembly
that requires thumb2 or something similar, then you could have some
tricky stuff to fix. The other option would be more focused on specific
packages or libraries. Certainly there is overhead in armel's calling
convention even when using hardware floating point, but it would be much
less work to officially get packages included in official debian armel
I believe. So the HWCaps + armel would be less work longterm I would
think.
Of course if the pi really takes off, maybe it could justify a new
official port.
> 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.
Well that would also be true for people running i686 machines, and
they aren't being catered to that way. There are a lot more of those.
Debian i386 is optimized for i486 except for a few libraries that include
i686 optimized versions (like the libc6-i686 package). But you have to
install it yourself as far as I recall.
> 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.
Sure it's the simplest for the user, but also means a new port to maintain.
> 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.
>
> I'm very happy you've done this as it makes my NSLU2 still relevant and
> useful as a low power utility device.
>
> 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?
I get the impression that the kernel and such are now ready, although
I must admit my board is still running the ubuntu it came with on SD,
and then I mount a sata harddisk and chroot to debian armhf. I haven't
actually done an install yet. Too many things weren't ready when I got
it, so I was trying to work on fixing packages that would not build, for
which the chroot did the job.
> 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.
--
Len Sorensen
Reply to: