Tag Archives: uclinux

Linux, Rockbox

Sansalinux

1 Comment

sansa e200RWith an unfortunate Sourceforge registry date of April 1st 2008, it could very well be an April’s fools prank but then I can’t see any real reasons why someone couldn’t port ipodlinux over to the Sansa e200 v1 series.

So Sansalinux is working according to their site, and they also provide some crappy screenshots that aren’t really good enough to make it possible to tell if they are for real or fakes.

The uclinux patch on their download page seems genuine and contains a lot of code originating from Rockbox (including copyright lines from Rockbox hackers).

As in the case with the ipod version, it begs the question what they want with this apart from the fun of getting Linux on yet another target. Also, seeing how there’s really no developers around to hack on ipodlinux it’ll be interesting to see if there will be any on the Sansa version. Seeing that it doesn’t run on the v2 version (no surprise really since Rockbox doesn’t either) so there’s no new Sansa e200 to buy to run this linux on.

If someone actually tries this out, please let us know what you find out!

Linux

uclinux is weird

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.