Which Embedded Linux Distribution? 62
Abhikhurana writes "I work for a company which designs a variety of video surveillance devices (such as MPEG4 video servers). Traditionally, these products have been based on proprietary OSs such as Nucleus and VxWorks. Now, we are redesigning a few of our products and I am trying to convince my company to go down the Linux route. Understandably, our management is quite skeptical about that and so I was asked by our CTO to recommend a few RTOSs which have mature networking stacks and which work well on ARM platform. I know that there are many embedded Linux based distributions out there. There are commercial ones such as Montavista, LynuxWorks, free ones such as uclinux, muLinux and some Linux like distros such as Ecos. What is the most stable and best community supported embedded Linux distribution out there?"
Realtime Control with Linux Considered Harmful (Score:5, Interesting)
Whether Linux is appropriate depends largely on the type of project you're doing. You're probably aware that tons of routers and assorted network gear runs Linux. It might be the best choice if that's what you're doing. But if you're trying to do hard realtime control with Linux... well, if your experience is anything like mine was, it'll be painful.
I did a project with a 266 MHz PII single-board computer [embeddedsys.com] once. I chose it because it had tons of on-board A/D and D/A, and when I ordered it I asked the company [embeddedsys.com] for their Linux drivers, etc, as well (which they advertised). They sent me a customized version of Redhat to be installed on the development machine, and a bunch of tools to set up a stripped down distro on the target as well, using the same libc libraries, etc.
There were numerous errors in what they sent me, including stupid things like configuration files having DOS instead of UNIX line endings. How this got out the door I do not know. But, I could fix all those dumb oversights, so that wasn't the problem.
The issue was that the distro they sent did not include any realtime extensions (a must for my application), so I endeavored to install RTAI [rtai.org] on it. This was where I began to have real problems.
The kernel they were using was old -- 2.2.some-low-number. Assuming this is what their drivers would work with, I found the vanilla source from kernel.org for a nearby 2.2 version, slightly higher, compiled it, no problems. I then tried it with their extra A/D and D/A drivers compiled in: no problems. Then, I tried it with the RTAI extensions (without their extra drivers: Test one thing at a time!) It compiled, but when I tried to run RTAI diagnostic programs the machine would unceremoniously reboot. No good.
"Ok," I thought, "this is a pretty old version of RTAI. Let's try a newer version; maybe that's a little more mature." In order to do that, I needed to use either a 2.4 or a 2.6 kernel. So, I started by trying to build a 2.4 or a 2.6 kernel, again from kernel.org, first, without either RTAI or the extra drivers. First problem: gcc too old. Solution: Compiled on another machine (really, coLinux on my laptop, running Debian Sarge). But after putting the kernel images in the correct locations and reinstalling the boatloader with lilo as you'd expect, the machine would just reboot every time it'd start to execute the kernel. This happened for more permutations than I can remember of 2.4 and 2.6 kernel versions, and configuration options.
Unable to get RTAI working on an old kernel, and unable to get a new kernel to run, (and desperately needing realtime), I ended up putting DOS on the thing and writing code in 16-bit real mode. This gave me essentially unfettered access to the hardware, with fast interrupts, so that, even though people tend not to consider DOS an 'RTOS' per-se, it stayed out of my way enough that I was able to access the hardware directly and run with guaranteeable latencies.
DOS made lots of things harder -- networking and accessing extended memory in particular -- but solving each of those problems proved possible, since I was working with small enough atomic "pieces of the system" that they could be debugged. When I'd been trying to put together linux with RTAI with the given drivers, I was working with a big-monolithic-kernel... running-in-another-mini-kernel, and I could do little more than follow instructions, compile, and pray. If it'd worked, it'd've made my life much easier, but, when it didn't work, I was pretty much at a loss.
If you're on a tight time budget and you've never used embedded Linux before, as much as I love Linux, I've got to say: If you're doing a realtime project, just pay the money for a "real" RTOS.
** If anyone else has had different experiences, I'd be curious to hear them. Though it's too late now, I'd also be curious if anyone has some after-the-fact ideas about why the 2.4 and 2.6 kernels wouldn't execute.
Re:GPL is not a problem ... (Score:3, Interesting)
Huh? No, GPLv3 has the same terms for distribution as GPLv2. Its main change is the patent provision, which (I believe) requires you to unconditionally license your patents, which apply to GPL code that you distribute, to the people you distribute it to. So if MS adopted some GPL program, added some great feature which they had a patent on, and then distributed this new version, the GPLv3 would require that anyone they distribute this code to also have a free patent license, so that MS can't turn around and sue them for patent infringement on software they gave to them.
NetBSD (Score:4, Interesting)
Re:Well (Score:3, Interesting)
You don't *technically* need anything else, but for development it can be IMMENSELY useful to have a shell and a base set of utils. Busybox [busybox.net] will get you everything you need in a multicall binary under 1MB (dynamically linked to glibc).
Things can be even smaller using uclibc [uclibc.org] instead of glibc, but unless you are building an EXTREMELY low end embedded device and can't spare an extra 1-2MB or so (or 1/2 that with a compressed filesystem like cramfs) it may not be worth the extra hassle trying to build a uclibc toolchain (and potentially deal with uclibc issues with other utils/libs you may use).
Anyway, the nice thing about Busybox is that you port a single package and get huge range of utils. Overall I agree 100% with a previous poster who said the key to rolling your own OS is getting the toolchain working - once you have that, porting is relatively easy (I'm assuming we're talking about non-x86 embedded systems here... with x86 it becomes easier still, as the vast majority of open source development is done on that architecture).
Roll your own (Score:3, Interesting)
1) build a tool chain using http://kegel.com/crosstool/ [kegel.com]. Note: this uses glibc instead of newlib/uClibc but there are patches to make it work.
2) Download and build the mainline kernel with needed modules compiled in
3) Place onto device.
4) Develop application
5) ???
6) Profit!