Hello Everyone, 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 <[email protected]> wrote: > Hi all, > > 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 > application > 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 > application). > > However the two things I currently believe get in the way of this vision > are : > 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 > > Martin > > > -- > To UNSUBSCRIBE, email to [email protected] > with a subject of "unsubscribe". Trouble? Contact > [email protected] > >
