Re: Embedded and ARM Debian Sprint
Hello,
2010/11/7 Luke Kenneth Casson Leighton <lkcl@lkcl.net>:
> 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
Yes, it is not bad idea at all. There are suggestions on encoding a
flavour field on the Debian package name, other suggestions of
encoding the field after debian version, other suggestions of handling
multiple repositories with optimized libraries (maybe components). It
certainly needs some discussion on how to standardize it.
>> * Cross compilation environment (cross toolchains and target packages) - bare metal support
I want to be able to (cross-)compile my firmware for Cortex M3 or
MSP430. (bare-metal)
> 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.
Debian (binary based) != OpenEmbedded (source based)
Changes in Debian take longer because we need consensus among
community to do things properly and maintainable in the long term. Why
would I want to cross compile a whole distribution and run an extra
emulation layer (introducing more overhead in maintainability) if I am
able to debootstrap/multistrap it in less than a minute, then cross
compile my application for faster development/test cycle to run on
that system which already has gone through lots of QA proceedings.
> question: why not recommend portage / gentoo instead of openembedded?
Certainly this is a topic to be discussed. How do we provide a useful
user land for systems with short size and memory requirements
(Emdebian/Crush)? Do we need to have 100 developers to maintain the
thing? (*bad idea*) Glibc or uClibc based? Trying to avoid
fragmentation, it would be good to trim down already in use EGlibc,...
It is to be discussed if we provide the tools (buildroot, bitbake,...)
to build from $somewhere sources or if we are capable to provide a
binary based image like the ones used by debian-installer using udebs
or maybe something else $someone stills needs to propose/think about
it.
Best regards,
--
Héctor Orón
"Our Sun unleashes tremendous flares expelling hot gas into the Solar
System, which one day will disconnect us."
-- Day DVB-T stop working nicely
Video flare: http://antwrp.gsfc.nasa.gov/apod/ap100510.html
Reply to: