I do a lot of work on various types of embedded systems. Professionally I’ve been working more or less exclusively with embedded development since 1996 (pSOS, VxWorks, OS9000, etc) and privately I hack a lot on Rockbox. The embedded work of mine has grown to become pure Linux-based since around the year 2000.

I’ve worked with (embedded) Linux on more than 10 different chip families, using cores such as x86, AMD64, ARM9, StrongARM, XScale, PPC, MIPS, SH4, m68k, MicroBlaze, Nios II etc.

And this is what I’ve learned: uClinux is weird.

I’ll of course admit that the fact that uclinux is currently more or less integrated into the regular kernel development is a good thing and all, and even though I haven’t done much uclinux hacking with older kernels I bet things were worse before.

The problem with uClinux that I think is the major obstacle is their build system. Oh wait, perhaps the problem is actually two: the first being that they ship as an entire distribution with kernel and tools and stuff all lumped together instead of doing it like all the other embedded (real) Linuxes do: assume that people fix their kernel in one go and the entire rest of the user-land universe in a separate tree.

Anyway, what’s the actual problem is the build system. There’s no scattered Kconfig files that you’d expect if you based a build on that concept, and it is really hard to figure out where to poke to change a build to do what you want. Then, there’s a top-level make that take ages and runs through all sorts of hoops even when there’s nothing at all changed. Not to mention that it alerts about make -j “sometimes not working”. In a recent project of mine I learned that I usually had to run make twice(!) in the uclinux-dist directory to be really sure that the output image was correctly made!

Unfortunately, I’ve not been able to dig into this issue properly to work on or suggest proper fixes but I hope that I will one day. Of course a factor in all this is that many people (like the entire embedded Linux universe) use very old versions of the packages so fixes can have been made in the recent years(!) without them having yet get absorbed at many companies.

So the truth is: I do recommend customers to go “full”, “real” Linux not only for the powers a real MMU gives but also for the more mature and nicer build environments.