Re: Single Chip ARM solution for Debian Linux?
On Sun, Jul 22, 2012 at 6:27 PM, David Given <dg@cowlark.com> wrote:
>> custom, minimal kernel, does a distro like SlugOS or OpenWRT offer
>> advantages? I would assume their packages are meant to minimize
>> RAM/Flash resources.
>
> It's been a while since I've done anything with them, but IIRC they're
> based on the OpenEmbedded architecture. That has its own package
> manager, ipkg, which combines some of the features of apt and dpkg.
there is also a configuration option - i.e. some bitbake files - that
can be included in a top-level file (or any sub-includes) which allows
apt and dpkg to be deployed *instead* of ipkg. dpkg is, after all,
just another bit of software that openembedded can download and
deploy.
> OpenEmbedded's big selling point is that it's a turnkey system which
> will let you run a build with your own system with custom compilation
> flags, and you end up with a custom kernel AND a root filesystem AND
> custom builds of every package in it AND a set of ipkg feeds for
> additional packages.
>
> But I've never actually made it work, so YMMV.
i have, and once you get use to it it's f*****g amazing. its
configureability, flexibility, comprehensiveness, number of platforms
it supports as well as the number of distros it supports (kde, gnome,
lxde, xfce, angstrom, opie, gpe being just a few) and the overwhelming
way in which it can work out the full set of dependencies *including*
right back to downloading the *source code* of the build toolchain -
entirely automatically - is far FAR superior to anything that ANY
other GNU/Linux distro has ever created, and that includes gentoo as
well as debian.
it's also absolutely superb for throwing in unusual or off-the-wall
compile-time options that are not usually deployed; however it is
smart enough to *stop* you from using options to compile certain
packages for certain architectures that are known not to work, and
also to add options and workarounds that are needed for particular
OS-package-architecture combinations if you yourself left them out.
translation: even if you picked a really weird and completely
untested platform and a completely untested package combination that
nobody else had tried before except for you, chances are that once you
get used to openembedded it stands a good chance of working. compare
this to debian where you are tied to a particular architecture with a
fixed set of compiler options, but you want to try something
different... well... good luck and let me know in a years' time how it
goes!
i mean... i don't know of any other build system which is capable of
performing cross-compiles of packages by not just downloading a
cross-compiler, oh no, that's been tried before and known to be
problematic. so instead, it can be configured optionally to download
a cross-compiler which is then used to compile a native compiler for
the target platform, and then it uses qemu in headless mode to run
that compiler and the configuration steps and the building of packages
as if the compilation were occurring natively!
compare and contrast this to debian having to force a rule whereby any
distro's packages *must* be compiled natively on raw hardware (of the
type of architecture for which the package is for) and you start to
understand some of the power of openembedded.
the only problem is: the sheer flexibility and scope of what
openembedded can allow a small team of engineers to achieve over such
a long period of time that openembedded has been going leaves it both
drastically underestimated, underappreciated, and also quite hard to
comprehend. the fact that python can be mixed with shell script in
amongst bitbake commands, and the fact that appending an underscore
and a suffix in lower-case to any variable, where the suffix is a
meta-variable itself which can, if set, result in a configuration file
in a subdirectory named after the meta-variable being pulled in and
thus completely alter the entire build process, is just one of the
features in bitbake that REALLY does peoples' heads in :) certainly
i've been caught out by that before now.
> http://www.openembedded.org/wiki/Main_Page
> http://narcissus.angstrom-distribution.org/
>
> It may also be worth looking at Debian's own embedded Linux project,
> Emdebian, but I know even less about that than I do about OE.
emdebian is primarily wookie's baby, and it involves cutting out bits
of debian packages that you would not normally need on an embedded
platform. such as documentation and so on. there are two variants,
one of which is closely compatible with standard debian packages
(called "grip" i think) and one which most definitely makes it harder
to install standard debian packages (called "crush" or something like
that) - i haven't looked at this stuff for a while.
anyway i believe that the primary focus of emdebian "grip" is, as far
as i can gather, to reduce the amount of disk space (NAND or other
storage), whereas the additional focus of "crush" is to take that a
bit further and also reduce the memory footprint.
however, it may need someone like wookey or someone else that is
experienced with emdebian to chime in and advise if it's suitable for
use on platforms with 8, 16 or 32 mb of RAM.
/peace
l.
Reply to: