Re: Embedded and ARM Debian Sprint
On Fri, Nov 5, 2010 at 4:35 PM, Hector Oron <zumbi@debian.org> wrote:
> Hello,
>
> I am proud to announce a Debian Sprint[1] supported by Debian, Genesi USA and Toby Churchill.
yay!
> = Agenda =
> * armhf status and Debian integration into dpkg and lintian
> * multiarch support into dpkg
> * Handling 'flavours' (ISA and optimisation options) (e.g. ARM v5/v6/v7/VFP/Neon, x86 i586/i686/MMX) within Debian (dpkg support, package metadata, partial archives, multilib gcc/install paths, multilib- or flavoured- cross-tools)
i haven't looked around, but has anyone suggested adding a
base64-encoded extension to the .deb name, containing a bit-field of
"capabilities"? the problem with splatting the capabilities into the
.deb itself is that you then end up with dozens of combinations of
capabilities, all with the exact same .deb filename. by encoding the
capabilities in the actual filename, you can still pick a particular
package by its version number etc. etc. _but_ you can identify whether
it will work on a particular CPU by decoding its capabilities bits.
0x1 -> v5, 0x2 -> v6 .... 0x10 -> NEON
and for x86, because, duh, you _so_ aren't going to get x86
instructions on ARM CPUs :)
0x1 -> i586 0x2 -> i686 0x4->MMX 0x8-> MMX2
there's a low-cost embedded x86 processor by RDC which ... hum... it
can't run qt4 apps because the f*****g qt4 low-level image blit
library assumes MMX instructions by default. and... 486 .debs were
dropped several years ago, weren't they? so you get 386 .debs and
they don't f****g work.
> * Cross compilation environment (cross toolchains and target packages) - bare metal support
the level of expertise / machine-specific information is so vast that
i strongly advise against "beginning from scratch". whilst wookey (or
neil?) pointed out a few months back that it took several months -
almost a year - to do the armel port, most of which was done by hand,
and someone else pointed out recently that they managed in a couple of
weeks to recompile automatically several hundred packages for Cortex
A8, gaining a 40% performance jump by doing so, this is still an
insanely ridiculous situation... when you compare it to openembedded.
i believe that a sensible and sane approach to the dog's dinner mess
of doing cross-compiling for dozens of targets and hundreds of
machines would be to part-replace the capabilities of buildd with the
capabilities of bitbake. in other words, write a bitbake recipe for
openembedded that understood about debian/rules, dpkg-buildpackage and
the debian cross buildpackage tools (note: openembedded already
understands .deb packaging).
now, that ain't gonna cut it for the _entire_ suite of debian
packages: some of them simply aren't going to cross-compile as-is.
two things help solve that: 1) openembedded has the ability to use
qemu to configure packages! yes, you actually end up running _really_
native (only not really) via command-line qemu. 2) there is precedent
for "OS-specific" debian/rules #includes (from the painful ubuntu) if
you're absolutely desperate but i imagine that qemu pretty much solves
it except in extreme rare cases (for example, that package mentioned
last week which requires 1gb RAM to compile: current stable versions
of qemu only do up to 256mb RAM, damnit)
as far as cross toolchains are concerned: openembedded has it all,
done already. why the f*** would you want to "start from scratch"
when openembedded has everything that's needed??
question: why not recommend portage / gentoo instead of openembedded?
answer: because openembedded has over one hundred ARM platforms
supported already, with ARM CPU variants dating back over 10 years,
and gentoo um... well... i don't have to look it up to know that it's
not going to have anything _like_ the level of support for ARM CPUs.
l.
Reply to: