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?"
Can we get this guy banned? Seriously, this fuckwit is not contributing
Stay on topic or chances are somebody will find out where you live and teabag your sister (sorry but shes not going to sleep with you)
Make SELinux enforcing again!
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/
Gentoo can do what you want, if you know what you're doing, so can LFS and other source distros. It's just what you need really, lets you skip anything you don't need and put only what you want.
"Don't meddle in the affairs of a patent dragon, for thou art tasty and good with ketchup." ~ohcrapitssteve
i enjoy him.
:)
missed ya, buddy! welcome back
whatever, just make him a foe so he's automatically modded down for you.
Because people like parent make slashdot enjoyable for me.
As much as I'd like to read everyone's uninformed ego inflating karma whoring posts, the Parent livens things up, and breaks the monotony. It's great trolls get freak out replies, too. Esp. that 20 minutes for a 17 meg file mac troll. Good Stuff.
I've worked with Montavista at two employers now, and the biggest complaint is the extremely high licensing costs. Apparently, it's a lot cheaper to use some highly proprietary RTOS than Montavista's offering.
Also, you have to pay high per-unit royalties, even though the software is GPL. For this reason, customers don't want to use it.
You really might want to consider going with Wind River's Linux product. It keeps the bosses happy because they have a familiar vendor and honestly, it is not a bad embedded distribution/tool suite either.
--- Liberty in our Lifetime
There is no reason why the OS for an embedded application shouldn't be part of your product build. Back in 2002 we developed with a custom GNU/Linux build for our hardware, and it was much easier to work with than anything offered by commercial providers of 'real-time' GNU/Linux.
What you really need to pay attention to is your toolchain. Get that right, and you are laughing.
Any fool can talk, but it takes a wise man to listen.
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?
Montavista hired spammers to send their ad. Not nice. They didn't even reply to the developer who complained in LKML.
We're considering using QNX for a new (embedded) project at our company - anyone with QNX experience want to comment?
With Nucleus, for example, you spend 99.9% of your time writing/testing your own code. You're on a solid, well-known base that you have prior experience with. Clearly your management has no problems with their licensing scheme or pricing.
If you go to linux, you'll get:
I'm not saying that Linux is necessarily bad here.... just that it may not be the nirvana that you think.
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.
As I recall, TiVo "distributes" its modified code every time it sells a device. However, TiVo doesn't give away the modifications to the kernel in their device. Is TiVo violating the GPL? If not, then why does the OP's company have to give away their modifications?
As I recall, TiVo made the argument that they were primarily distributing hardware, and that the fact that the hardware ran a modified version of Linux was incidental. Can the OP's company use the same argument?
We all know what to do, but we don't know how to get re-elected once we have done it
Thanks for the links. May be useful in future if I do something like this again. *bookmarks*
- 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.I don't know if it's still true, but the last time I looked at uCLinux, it had a rather different approach to memory management than regular Linux, and was designed for devices that didn't have real memory manager chips. Is that still the case, or is it more mainstream now?
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
My company went with Lynuxwork's BlueCat as our embedded Linux and continually regretted it. We had no Linux expertise and so wanted the professional services that was available from Lynuxworks along with their distro. However, we found that 1) we had a hard time getting them to honor our business priorities, and 2) the distro was based on a kernel old enough that we couldn't update to the latest releases of things to get bugs fixed. It would have been much better to hire a good Linux guy (which we ended up needing to do anyway) and going with a standard distro. The amount of support we could rustle up from the community and consultants was at least as good and sometimes better than the support from Lynuxworks that we were paying for.
It's a pretty cool little OS, mostly because it's smaller and easier to understand, and hack on, then Linux. That said, it also doesn't do, or even try to do, as much as Linux, so you would want to use it for smaller, simpler devices, most likely.
http://www.welton.it/davidw/
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!
All you really need is a kernel, some startup scripts and busybox. That way you can have pretty much everything you need in less than 4mb of flash, and it's all free! (as in beer and speech)
If a train station is a place where a train stops, what's a workstation?
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.
Something you can point out to your doubtful manaagers...
Having worked with pSoS, vxWorks, and embedded Linux, I have found the support process to be identical for both pay and free OSs:
1. Ask the provider for help.
2. Ask on a user's group / mailing list.
3. Get the code and fix it yourself.
You will be ignored at stage 1 nearly every time, because the Linux development people are busy, and because your proprietary OS provider has enough bigger, better paying customers that they can afford to ignore you. In stage 2, a free OS often has a bigger user group which is much more willing to share, so you stand a better chance of getting an answer there. Of course, you usually end up at step 3 anyway, which is free for eCos/Linux (give or take paying the developer), but which costs tens of thousands of dollars for the vxWorks etc...
I've been able to get armedslack up and running on an arm board with 32 meg of ram. It worked quite well. Eventually ended up with debian-arm for production because of specific glibc and kernel versions which were available. I was able to use NFS and ssh on the ARM system and didn't notice any oddities with the networking stack (2.4 kernel). Some sites below where you can get a few of the arm distros I used.
s taller-arm/current/images/netwinder/
Snapgear
http://ftp.snapgear.org/pub/
armedslack
http://www.armedslack.org/
debian
http://www.debian.org/ports/arm/
http://mirrors.midco.net/debian/pool/main/
http://mirrors.midco.net/debian/pool/main/
http://ftp.egr.msu.edu/debian/dists/sarge/main/in
boycott slashdot February 10th - 17th check out: altSlashdot.org
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
I've used Arcom Linux Distribution(Debian based) and for the most part, I like their products.
Also, eCos isn't a linux distro - it's a bootstrapper like RedBoot. You can use it on ARM, but it's not a full kernel.
Don't think that a small group of dedicated individuals can't change the world. It's the only thing that ever has.
I've done a number of embedded Linux ports, on a wide variety of hardware. My experience has been that the ONLY reason why people go with Montevista or Windriver is CYA (Cover your A**). It's the paperpushers (managers and bean counters) who like these companies, not the techies.
As far as support goes, both companies are well known for not providing any serious support. Sure, they'll take your money (usually) so that you can say you have a support contract. But forget getting any real help.
The bottom line is that you really need kernel talent in-house if you're doing any sort of embedded project, regardless of what O.S. you're using. This is simply the name of the game.
To put things in perspective, I once saw a Cisco Business Unit which had a Purchase Order for a support contract with Montevista try to get Montevista to take it. The sales staff at Montevista wouldn't even return their calls!!!
I know that sounds hard to believe; I couldn't believe it myself, and I was there. Normally people die to try to get Cisco's business, especially for an entire BU. This is as close to free money that you can get. And yet they simply wouldn't return the phone calls until much later.
This is truly amazing. But it gives you an idea of what these companies are like. And still, people do business with them. Go figure.
These guys might know something about embedded Linux. The info page says uCLinux.
the NPG electrode was replaced with carbon blac
does this way work
I have paid hard cash for all that you are trying to do and did it with ARM and I got to tell you that if I were going to use an ARM platform I would not use any of the mentioned
con artist because you are in way over 50 grand and way over your head and no matter what and you will still be holding your D*&% in your hand....In fact those companies do not sit around and fix your problems they are there to steal money from you and put you further away from your arrival point while they collect all the cash. Those companies are all a scam period. One reply stated on the absolute crap of a release that was not even Q C'ed. Do yourself a favor and go with a PROVEN embedded leader that has great price points and the MOST mature user linux support COMPULAB in Hiafa Israel. Numerous mature builds in the community plus they give you their own updated and mature kernel release with robust board support for drivers and basically everything you need. I wish I would have found these guys before I got screwed by Xscale Intel PXA255 and PXA270 as well as AMD mips au1200, LOGICPD, WIND RIVER,
and the others who talk big and CANNOT deliver. If I were you I would dump the ARM platform like even INTEL did and fo with embedded X86 so you dont have to make a custome modified build of the kernel and every app you want to use and instead just load the x86 version and BAM you are running and your bosses will be happy that you didn't screw up and saved them money... If I would have had straight talk and real advice I would have enough money to go buy a new Mercedes instead of driving a Civic...
PS anyone who writes anything to dispute what I have written is full of Sh*#!
When starting a new embedded project, not only an operating system has to be chosen but it also has to be decided which CPU will be used in the project (Intel-architecture, PPC, MIPS or ARM). You cannot choose a CPU and ignore the operating system, and you cannot choose an operating system while ignoring the CPU it will run on. What I learned the hard way is that it is important to choose a mainstream CPU, even if this means that it will consume a little bit more power or takes up some more PCB space. Otherwise you might be surprised some day that the embedded Linux vendor drops support for the CPU you selected for your project.
I'm a Cisco employee, and I am involved in weekly conference calls with MontaVista for an embedded Linux project. MontaVista really solves the issues we report to their support department, although not always as fast as we would like it.