[colug-432] Fwd: Re: Debian on Pi

lhowell at speakeasy.net lhowell at speakeasy.net
Tue May 7 19:16:20 EDT 2013

>On Sun May  5 21:15 , Rick Troth <rmt at casita.net> wrote:I'd like to hear more about this. Sounds like supporting "hard float" was/is way more complicated with ARM than the hard/soft float support back in the pre-Pentium days.  I still have a 486 "SX" which requires math emulation.  But on INTeL x86 series HW, that's a boolean flag when building the kernel.  No need to re-compile the apps.  (Unless I have missed something profound.) 
>-- R; <><

Supporting hard-float was only part of the story. The time tar-pit was rebuilding Debian for a slightly different ABI on a very specific embedded hardware platform with a proprietary GPU in the mix of devices.

The hardware:
The Pi is built around a Broadcom BCM2835 SoC (System on Chip) that contains an ARM1176JZFS core, which includes VFU floating point with the Neon instruction set.  The board also has a Videocore 4 GPU, which can do BluRay quality playback using H.264 encoding at 40 Mb/sec.  The GPU has a fast 3D core that can be accessed using vendor supplied OpenGL ES2.0 or OpenVG libraries.

The build challenge:
The hardware design team achieved the selling price constraint by using cell phone devices that are cheap due to high production volumes.  The Broadcom SoC is ARM11 with the ARM v6 ABI, rather than the much more common ARM Cortex-A8 with the v7 ABI.  If this was the only issue, it would have been almost trivial to rebuild the Debian packages.  The major ugly was the proprietary GPU.  Videocore is not releasing info about the chip, so only binary firmware blobs and library binaries are available.  When you don't have access to the chip internals or the code of the libraries, the testing/debugging cycle is much longer.  While the compiling was done on a Linux PC using a cross toolchain, the debugging/testing had to be done on pre-production Pi boards.  It was very important to wring the maximum performance out of the Pi, because users would not tolerate "slow" response.  This is why the Raspbian team decided to rebuild the Debian packages with hard float.  Once all 35000+ packages were verified as functioning as expected, the optimization process began.  Again, because of the binary blobs there was a time consuming cycle of reporting problem symptoms to the Videocode developers, waiting for changes and rebuilt blobs, then retesting.  Truly a major effort.  BTW, the Raspbian "team" is two developers.  Most of the actual building and testing was done by Mike Thompson, an embedded systems developer in San Fransisco, and Peter Green, an experienced Debian-arm project developer in Manchester, UK, who helped Mike navigate the Debian process infrastructure.   Mike had no life for six months.

Perhaps I have a greater appreciation for this work since I'm current working on application development for a Freescale i.MX53 (ARM Cortex-A8) embedded Linux based system here in Kalamazoo.  It should keep me busy for the next two years.


More information about the colug-432 mailing list