<box round left orange 240px>
This page is a work in progress…



There curently exist some tools whose purpose is very similar to the one Ab Nihilo targets.

This study gathers all known existing solutions, and for each details its history, current status, and, in my point of view, its strengths and weaknesses.

DISCLAIMER This is the result of my own experiments, and somewhat tainted with a little bit of my own feelings. Do not take this study as gospel truth, and if you really need to set your mind, go and check for yourself.

Individual studies


  • Homepage: buildroot portal
  • Overview (from the buildroot site):
    • Buildroot is a set of Makefiles and patches that makes it easy generate a cross-compilation toolchain and root filesystem for your target Linux system using the uClibc C library.
  • History:
    • Initially designed to provide an easy way to build a uClibc-based cross-compiler, along with a minimal root file system.
    • Evolved to include support for a large set of packages, ranging from busybox up to Xorg.
  • Macro-design:
    • a centralised configuration menu not unlinke the one from the Linux kernel
    • a set of makefiles and patches to build a cross-compiler
    • for each package, a makefile and a set of patches
    • a "make all" philosophy, that downloads, extracts and patches the packages' sources, builds the cross-compiler, builds and install each packages in turn, and assembles the file system images.
  • Notes:
    • none
  • Pros:
    • large set of packages
    • large collection of patches
    • a (crude) dependency system
    • (somewhat) maintained
  • Cons:
    • impossible to configure most packages (only uClibc and the kernel have configure targets, to my knowledge)
    • difficult to re-build a single package
    • difficult to add/updatee new packages (Makefiles are complex)
    • builds are conducted in the buildroot source tree (not out-of-tree builds, no way to install buildroot)
    • almost impossible to use external toolchains (there exist config entries, but "It Does Not Work For Me (TM)")
    • there is no way
    • evolution of buildroot is somewhat anarchical, there is no agreed-on global roadmap
    • there are more than one repository, and even some active committers have git variants of the tree with their own changes, and don't agree what targets are supported (thread)
  • Conclusion:
    • while buildroot can be easy to begin with, it soon shows its limitations when it comes to doing actual development on the packages that are used to build the firmware. IMHO, it is OK to use buildroot for a single, one-shot build. It does not fit well in a software production process.


  • Overview (from the dev portal):
    • OpenWrt takes a different approach to building a firmware, downloading, patching and compiling everything from scratch, including the cross compiler.
  • History:
    • Initialy a fork of buildroot (see above)
    • growed its own Makefiles structure, API, and packages and patches sets
  • Macro-design: cf. buildroot, above.
  • Notes:
    • none
  • Pros: cf. buildroot, above, except:
    • maintained
  • Cons: cf. buildroot, above, except:
    • seems easier to add a new package or target
  • Conclusion: cf. buildroot, above, plus:
    • the openWRT targets home appliances such as gateways (initialy, Linksys' WRT). As such, a build system that builds from scratch a whole toolchain, and a whole userland in one pass is quite well suited for the end user that only wants to test the latest development onto his/her router.
    • again, it is not well suited for actual development


  • Homepage: ptxdist portal
  • Overview (from the ptxdist site):
    • PTXdist is no distribution: our experience is that binary distributions are too inflexible for embedded systems. That's why PTXdist builds the target system directly from the original sources.
  • History:
    • unknown
  • Macro design:
    • a little bit like buildroot
    • has the notion of "projects", where each project is a separate instance of a build
  • Notes:
    • I was not able to use ptxdist. Installed OK, but the documentation lacks explanations on how to create a new project from scratch, and no existing project was available for the version I tested (1.99.8, 20081213)
  • Pros:
    • the "projects" stuff
    • maintained, I guess
  • Cons:
  • Conclusion:
    • for a professional solution, I thought it would be straightforward to at least create a minimalistic project. Alas, I was disapointed… :-(


  • Overview (from the OE site):
    • Openembedded allows developers to create a complete Linux Distribution for embedded systems.
  • History:
    • unknown
  • Macro-design:
    • a "distribution"
      • defines the type of system: gateway, NAS, handheld…
    • a "machine"
      • selects (and builds) the appropriate build tools
      • sets corresponding options
    • a "recipe"
      • a set of atomic actions to be executed to retrieve, build and install a package
      • a set of patches for each package
  • Notes:
    • build system written in python
  • Pros:
    • many "distributions"
    • a lot of supported "machines"
    • a very large and comprehensive list of "recipes"
    • maintained
  • Cons:
    • admintedly, many would see it a benefit, but I don't know/like Python
    • no separation between the build system itself from the "distributions", "machines" and "recipes" lists (it's again a get-it-all-or-get-nothing)
    • builds all from scratch: toolchain (both cross and native!!!), qemu, packages, file system image builders… There's no way restarting from scratch a new project using previously build tools.
  • Conclusion:
    • so far OE is the best candidate for vampirising ideas! :-)

Firmware Linux

  • Homepage: FWL
  • Overview (from the FWL site):
    • Firmware Linux is an embedded Linux build system, designed to eliminate the need for cross compiling.
  • History:
    • (this is my own writings) While he still was the busybox maintainer, Rob LANDLEY had the need (or the will) to create a new build system that would allow him to create Linux-based systems from scratch, with as few as apossible GNU stuff in it (there are a few mails by him on the subject on the busybox mailing list).
  • Macro-design (from the FWL site):
    • The build system is a series of bash scripts which create a small native Linux development environment for each target, runnable on real hardware or under emulators such as QEMU.
  • Notes:
    • I usualy like what Rob does, because he tends to be doing things right and nice at first shot. Let's look at his FWL…
  • Pros:
    • small, concise
    • maintained
  • Cons:
    • non-modular: a single shell script for a lot of work
    • not many packages, as the purpose is to build a self-replicating system
    • targets being a proof-of-concept that a Linux-based system can be called without the prefix "GNU/" (ie. with no GNU-owned software), still WIP though.


  • Homepage: emdebian
  • Overview (from the site):
    • The Embedded Debian Project is making Debian GNU/Linux a mainstream choice for embedded projects.
  • History:
    • unknown
  • Macro-design:
    • builds on top of the Debian architecture
    • strips down package to their minimum, moving documentation, and othe un-necessary data out (sometime to another package, sometime to /dev/null)
  • Notes:
    • I don't really know much about Emdebian, but it strives to be a Debian-like distribution targetting embedded devices, and being Debian-based, it looked like a good candidate to look at.
  • Pros:
    • the Debian package list (when they are adapted)
    • good support from the comunity
    • includes a packaging system
  • Cons:
    • still very young
    • includes a packaging system (no, that's no error, this is both a god and a bad point)
    • (IMHO) very complex to package for Debian (and thus emdebian).
  • Conclusion:
    • more like a general-purpose embedded distribution to me, rather than a build-system for developing embedded software.

Linux Target Image Builder

Idea submitted by Thomas JOURDAN, study will come a bit later… http://www.bitshrine.org/


Idea submitted by Thomas JOURDAN, study will come a bit later… http://www.t2-project.org/


The main goal of all theses tools is to build firmwares from sources. But for all of them but one, it's a single step procedure that groups all the steps needed to build the firmware; they are kind of monolithic. Adding new packages or new target platforms, using external toolchains, re-using the build tools in another environment is less than easy. Some have provision for intermediate steps and configure actions, but they are limited, if even functional.

Of all these tools, OE seems the most versatile of them, with the ability to easily add new packages, define new targets. Unfortunately, the syntax for doing so is quite complex. It's writen in Python, and I don't grok Python.

(More to come later…)

projects/abn/study.txt · Last modified: 20090114.162005 by ymorin
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 3.0 Unported
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki