Slashdot Mirror
Which Embedded Linux Distribution?
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?"
If their employment page is any indication, I'd say Ubuntu will be very soon.
It seems openembedded.org isnt as well known as it deserves.
Openembedded has;
- Been around for a number of years
- Has a strong developer community
- Is used be a few commercial projects, notably openmoko.
- Can builds its own cross compiler
It allows you to pretty easily define your own distro and build an image for it.
Just a friendly reminder, but don't forget to tell your higher-ups that using a *modified* Linux in their product means they have to release the source. Don't forget that, or you may be in for a nasty suprise. I don't know how much of an embedded system NetBSD is, but if putting out the source is going too far for them, that could be an option. If they don't mind that, then by all means go ahead.
(karma shields to 120%)
"I think an etch-a-sketch with an ethernet port would beat IE7 in web standards compliance."
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 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 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 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.
... except with people saying things like this:
Just a friendly reminder, but don't forget to tell your higher-ups that using a *modified* Linux in their product means they have to release the source. Don't forget that, or you may be in for a nasty suprise.
How friendly/nasty of you. First, you assume the company is anal about the working of their systems or sharing kernel fixes and drivers. Second, it does not matter anyway. They can put all of the stuff they can't or don't want to share into code they don't share. The GPL does not force you to break MPEG4 NDAs, it won't publicize code you don't mix in, or steal your wife. All it does is make sure you pass on the same rights for code that's not yours that others passed onto you. The GPL encourages people to share but it never forces an issue. To draw GPL ire, you have to close off someone else's code.
Friends don't help friends install M$ junk.
If your company if comfortable with VxWorks, how about Wind River's offering...
http://www.windriver.com/announces/rtlinux/
whatever, just make him a foe so he's automatically modded down for you.
On an embedded system, you probably don't need anything running but the kernel, udev, and your application. You don't need most of your libraries; it's going to be more efficient to statically link everything. You don't need bash. You don't need Python. You don't need a package manager. For this task (networked cameras), you need ifconfig, a dhcp client, maybe a stripped Apache, and your custom application. And you can probably incorporate ifconfig / dhcp functionality into a library (take them from BSD or something licensed under LGPL) and put them in your application, which could also handle init if space is tight. (Though you probably don't want this, in case your appliance has to be reset.)
In short, while you can use Gentoo to build your target system, it won't effectively be Gentoo by the time you're finished. And it doesn't matter which distribution you choose at that point.
You might want to check out BuildRoot. It's what Gumstix uses for their distributions and it works pretty well. ...
They have even has the rt patch from Ingo Molnar merged into their standard distribution. Sounds like a Gumstix might
not be a bad way to go now that I think about it. And then you would have some pretty good community support. My $.02
Money is the root of all evil?
While I realize you specifically asked about Linux, it is probably worth pointing out that NetBSD has been used as an embedded OS on ARM for quite a while. See NetBSD's embedded page for more information.
- eCOS http://ecos.sourceware.org/
- RTEMS http://www.rtems.com/
- FreeRTOS http://www.freertos.org/
RTEMS in particular is much closer in functionality to VxWorks so it is likely porting to it would not be a huge job. It is well supported, extremely stable and free from GLP licensing issues.On an embedded system, you probably don't need anything running but the kernel, udev, and your application. You don't need most of your libraries; it's going to be more efficient to statically link everything. You don't need bash. You don't need Python. You don't need a package manager.
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 will get you everything you need in a multicall binary under 1MB (dynamically linked to glibc).
Things can be even smaller using uclibc 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).
Thats what we did:
1) build a tool chain using http://kegel.com/crosstool/. 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!
As I am sure you can guess, I'll answer with a simple answer, which likely means the most up front work but also the best capabilities. You'll want to build one yourself. This doesn't mean that you have to do all the work. As an example, I'll (obviously) use Gentoo. You install Gentoo and build your Gentoo-based distribution with exactly what you want in it. Since Gentoo is source-based to begin with, it should be easy to transition to your actual platform. Of course you won't want a C compiler and such on your actual platform, you do that on your development systems. This is really how most embedded Linux is done, with a development machine building the customized distribution for the actual release platform. I'll be honest and say that my experience with other embedded Linux is pretty much nil, but Gentoo will do what you want, and we have great community support. The nice thing about using Gentoo is it is basically the same thing as the normal distribution, and we support the platforms used for most embedded devices. Of course, you'll want to use what suits your needs best.
TiVo distributes Linux every time they sell a device, and they distribute source code. The TiVo hardware has some kind of device that checks for the original unmodified TiVo software, so that their Linux device cannot accept user-made changes. This does not violate GPL v2.
I just spent last semester dealing with openembedded and a pxa270 based dev board. The documentation is not the greatest, but once you have everything figured out and working, OE's power and flexibility really shine through.
Legally obligatory sig : My opinions are my own... etc etc