+++ Mike Thompson [2012-03-06 18:22 -0800]: > I am potentially interested in creating/maintaining a Debian port that would > mirror the work being done in armhf, but with the port tuned to the specifics > of the Raspberry Pi hardware which I believe is ARMv6+VFPv2. The goal would > be > a Debian distribution on the Raspberry Pi which would squeeze the most > performance possible from the CPU/MPU on the $25 to $35 device. It seems that > such an effort could piggyback off the efforts of those working on armhf so it > could be managed by a small group of volunteers.
As you presumably know we already have 2 arm parts. The armhf arm v7+VFP3 (using FP registers in calling convention and thumb2 instructions) and the armel v4t (using softfp FP emulation and only non-FP registers in calling convention). Only armel will work unchanged on the RPi, and that is the Debian distro currently used on these device, and what we expect people with v6 chips to use. 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. The first thing you need to decide is whether there is enough speedup from rebuilding/optimising for armv6 to make it worth doing. For FP-intensive work there could be significant speedups. For everything else it probably makes no odds. Just rebuilding a few packages that matter to use VFP instead of FP-emulation and sticking to armel would get you almost the same speedups for a whole heap less work. It would be good if Debian had HWCaps-aware dpkg to make this transparent (automatically picks packages optimised for your hardware), but that work has not been done - only vaguely specced. Your platform might be a good reason to work on it. > First, is there an existing group of volunteers already looking to support the > Raspberry Pi hardware in this manner? If so, I could look to lend a helping > hand rather than trying to duplicate working being done by others that > potentially have much more experience/knowledge of what would be involved. I don't know. 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). > Second, where would I start to understand what is involved with creating a > Debain port that supports a specific set of hardware such as the Raspberry > Pi. > Obviously the archive management and autobuilding tools will have to learned. > Hopefully this path has been followed enough that it s fairly well documented > and not tribal knowledge. Actually making a whole new port is a big deal, and in this case probably unnecessary. Your rebuild will not be a new port whatever happens - it might be a rebuild of one of the two existing ports with different optimisations. This is technically an easier job. In fact in theory it is very straightforward, but it's not something well-tested so there will be some breakage to fix. If you did do it as a whole new repo then reproducing the actual Debian build infrastructure is currently unecessarily hard work. In practice people use the 'ports' infrastrucutre for unofficial ports, and that would be the easiest way to get it done: http://www.debian-ports.org/ It is not clear at this point that such a rebuild has any prospect of inclusion in the archive at this stage so you'd have to ask if the ports people would host it. It might make sense in order to do the rebuild and test whether it really makes any odds. It shouldn't actually be hard to make your own debian autobuilders and work is ongoing to make it easy to set up local builders. I can discuss that with you at greater length if you wanted to do that. Reprepro+rebuildd+sbuild can make a simple rebuilder fairly straightforward to do. > Third, beyond time to learn everything involved and organize whatever other > volunteers might help, what would be required in terms of hardware, network > bandwidth, etc A person I ve communicated with on the Raspberry Pi forums > indicated that cluster of six Freescale i.MX535 Quick Start boards with SATA > hard disks may be enough to get started with. If figure this could probably be > had for about $2000 or perhaps less. Yep That makes a pretty good current buildd setup. The limited RAM means they struggle with a few really big packages like firefox and chromium, but in general they work well. The just-coming now imx6s are much better (2G RAM) but hard to get hold of at this moment. > Finally, what high-level things should be thought through before starting such > a project. I m certain many projects like this get started all the time just > to whither on the vine for various reasons. I would like to avoid that > scenario if possible. I've covered the basic questions about the pointfulness and some of the techical aspects of this above. 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. v6+VFP2 hardware is a slightly awkward spot between the new basline and the old one. The first thing you need to do is some benchmarking to work out whether you should be using * plain armel (trivial, but some performance loss on some specific tasks - how much?) * armel + some VFP2 optimised packages (quite easy, but room for improvement in how debian handles this sort of thing) * v6+vfp2 rebuild of armhf (a lot of work - does it make enough odds to be worthwile?). This should be easier than it is, and I'd like to see tools improvements that make it so. Easy buildd set-up plus dpkg-buldflags ought to 'just work' for most packages, but in practice I expect we are not quite there. Work in this area is welcome. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120307113943.gj26...@dream.aleph1.co.uk
