Re: Questions regarding armhf port for Raspberry Pi
+++ Mike Thompson [2012-03-07 09:32 -0800]:
> Wookey, thank you for the very detailed response.
> 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.
If you are supplying an SD-card image then having the right optimised
packages installed is not 'confusing' - it's done already, is totally
invisible to the inexperienced users, and apt-get update will update
correctly. As someone already pointed out already, i686 users manage OK
and there are an awful lot of them.
It's a manageable mechansim as it stands and has the advantage that
it's been working for years already.
The spec for making apt/dpkg automatically optimise from
differenty-optimised 'partial architectures' was discussed at a UDS a
while back but I can't find the corresponding doc right now.
> 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.
Yes, That would work.
> 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?
You are.
> I presume that
> Reprepro+rebuildd+sbuild is what would make the build of the RPi tuned
> respository possible.
Yes, they are build tools:
* Sbuild builds packages on buildds.
* reprepro is the package repository which has all the package lists,
and the package pool.
* rebuildd is a simple build-daemon. It's a bit dim for running a whole
distro-build system with, but it's approximately 100 times easier to
set up than wanna-build + buildd which are the standard Debian tools.
Here are a few postings on the subject:
http://www.jejik.com/articles/2006/09/setting_up_and_managing_an_apt_repository_with_reprepro/
http://inodes.org/2009/09/14/building-a-private-ppa-on-ubuntu/
https://wiki.linaro.org/Platform/DevPlatform/CrossBuildd
(that last one is for setting up a cross-buildd which isn't what you
want, but between the 3 you should see how it works.
If you get to camp on the debian-ports infrastructure then you don't
need to care about most of this - it's all done for you, except
setting up your own buildds. Someone from there might be along in a
bit.
You'll need to start by rebuilding the toolchain to default to
armv6+vfp2. Then it's largely a matter of feeding a pile of packages
through. A few will break and a some will build for v7, thumb anyway.
Some tests to root these out will be useful.
You can avoid the whole 'boostrapping from scratch' pain (which is
large) by using existing armhf packages and building everything twice
to remove any 'v7/thumb' contamination that occurs. That'll probably
work well enough.
> 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.
Just to avoid confusion the NSLU2 has an xscale IXP420 in it which is
a v5 device, SFAIK.
> With actual RPi hardware still being 6 to 8 weeks out, would a Freescale
> i.MX535 Quick Start board allow such benchmarking?
Nope. That Cortex A8 is very different from ARM11 (Pi) is very
different from Cortex A9 (e.g. Panda). You need to test stuff on the
real hardware to get anything reliable.
> I presume an armel install
> of Debian and compiling certain packages with VFP2 optimizations would be
> pretty straight forward.
Yep, should be. To get stuff in the main archive would need packaging
changes which are a bit more work (as you have to build both VFP and
non-VFP vaiants).
> Is armhf in such a state that it would be easy to bring up on the board as well?
Which board? It's trivial to bring up on the i.MX535. You'll need to
rebuild/change defaults in the toolchain and then rebuild all
installed packages to bring it up on Pi, as covered above.
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
Reply to: