Re: emdebian development model
Martin contributed a basic embedded development use case in a recent post to the list. I would like to add to that case a few more points.
- The embedded development market is driven by chipsets and dev boards. At the moment the Intel processors (VIA, Atom), and ARM processor (TI, Samsung, Marvell) based dev boards with other chipsets are the majority.
- The dev boards are engineering references which the board manufactures by and large follow in releasing boards to the public. Most come with farily good and complete specs of the chip (SoC) and the glue chipsets.
- Recently, the most chip makers have a engineering team that releases a Linux kernel and a toolchain along with their dev boards. However, these toolchains are designed to be hosted on a workstaion running either Linux or Window XP, 2000 etc.
- The critical first step is getting the Linux kernel and a utility set running on the dev board (busybox and scatchbox) and adding a stripped-down version of the package handling utility to that utility set.
since most chips have specific booting req. the bootloader is essential as is having a TTY and serial port config'd and running
- Depending on the boards memory device config (RAM, and storage) most kernels have static built drivers and most have menuconfig for kernel rebuilds. For these boards the application porting step is fairly easy. Those boards that load drivers dynamically avoid having to rebuild the kernel, but checking the final image size (to be sure it can still fit in initramfs) is not trival.
- Most important to embedded dev work is a clean, robust toolchain and cross compile process with a GUI development and emulator support (QEMU). I use Eclipse.
On Sat, Apr 25, 2009 at 3:34 PM, Martin Fuzzey <firstname.lastname@example.org>
My understanding of the emdebian vision is that someone wanting to build
a linux device would:
1) Port the linux kernel to their hardware (including writing any
specific device drivers)
2) Select the _prebuilt_ emdebian packages needed to support their
3) Package their application as debian package(s)
4) Build a root filesystem using emdebian tools from 1,2,3
Once this is done you can upgrade on a package by package basis as you
would a normal debian system.
1) is pretty much the same whatever method / distribution you use.
For me the essential difference between emdebian and other contenders
(buildroot, open embedded) is that emdebian is based on binary packages
whereas the others are source based. Indeed buildroot doesn't even have
packages at all - its just a set of makefiles that let you create a root
filesystem as a big binary blob. I think open embedded does have
packages but I need to look more closely.
So emdebian is like debian rather than gentoo...
So in this ideal world someone putting together an embedded linux
wouldn't have to actually compile much stuff (just the kernel and the
However the two things I currently believe get in the way of this vision
a) The restricted set of architectures (crush is only available for ARM)
b) The limited set of available packages.
a) is being actively worked on so I won't say any more about it.
However I think there is a problem with b) because I don't see how the
currently small emdebian team can possibly be expected to provide all
the packages that may be required.
Unless I am mistaken crush 1.0 is currently a (small) _fixed_ subset of
lenny cross compiled with modifications where required to reduce
footprint (remove perl, ...). There doesn't seem to be any process to
allow contributions of "emdebianisations" of _lenny_ packages, only
_sid_ ones. But I'm not at all sure people developping a linux embedded
device want to be running sid any more than a system administrator would
want to run it on their production servers.
Sure nothing prevents me or anyone else emdebianising lenny packages in
a private repository but if everyone does this it will lead to lots of
duplicated effort and an overall lower adoption of emdebian since the
entry barrier is higher.
So I am envisionning emdebian-crush-stable, emdebian-grip-stable which
both consist a subset of lenny (same package versions) but where that
subset expands over time as people contribute to "scratch their itch".
So in this scheme:
* debian - defines set of packages that constitutes a stable release
and hence the maximum theoretical set of emdebian
* emdebian developpers - work on tools, infrastructure and core
packages and maintain repositories
* contributers - submit emdebianisations of stable packages.
I guess the problem with this scheme is that it will mean more packages
to migrate when the tools change...
Just my 2c
To UNSUBSCRIBE, email to debian-embedded-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact email@example.com