Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Linux Business

Which Embedded Linux Distribution? 62

Posted by Cliff from the cream-of-the-crop dept.
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?"
This discussion has been archived. No new comments can be posted.

Which Embedded Linux Distribution? More

Which Embedded Linux Distribution?

Comments Filter:

  • Coming Soon: Ubuntu (Score:3, Insightful)

    by div_2n ( 525075 ) on Thursday May 03, 2007 @08:00PM (#18981817)
    If their employment page [ubuntu.com] is any indication, I'd say Ubuntu will be very soon.

    • Re: (Score:3, Informative)

      by dgatwood ( 11270 )

      Eh. Practically any Linux distro could do what this person is asking for without blinking at this point, assuming the CPU is fast enough to keep up. Video isn't really a hard-real-time environment. Where the embedded vendors shine is in supporting custom hardware, which I assume this company is using. That doesn't sound like it's up Ubuntu's alley. Mobile and embedded are not the same thing, though they do overlap.

      My advice: talk to several vendors, tell them what you're trying to do, and let them gi

  • Openembedded (Score:5, Informative)

    by bug1 ( 96678 ) on Thursday May 03, 2007 @08:01PM (#18981821)
    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.

    • I just built a filesystem with OE, and I wasn't that impressed. The documentation is very sparse, and there doesn't seem to be any way of defining what components should go into the filesystem. You only get pre-baked choices for particular platforms. If there's a way to choose which packages you want, I sure haven't found it.

    • Mod Parent Up (Score:2, Informative)

      by quo_vadis ( 889902 )
      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.

  • Dont forget about the GPL (Score:4, Informative)

    by Constantine XVI ( 880691 ) <trash@eighty+slashdot.gmail@com> on Thursday May 03, 2007 @08:09PM (#18981915)
    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%)

    • ... 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 the

      • Re:GPL is not a problem ... (Score:4, Informative)

        by Constantine XVI ( 880691 ) <trash@eighty+slashdot.gmail@com> on Thursday May 03, 2007 @08:36PM (#18982175)
        It is quite possible that this company doesn't want anyone to know about what they've done to the kernel to work better on their hardware or for their purpose. If I start modifying the kernel to be more efficient in handling a widget-smashing box, then put it into my super-fancy widget-smashing box without disclosing the fact or releasing the code, I am in a lot of legal trouble, because the GPL says that I have to release the modified versions of any GPL code I've used. I can still write the widget-smashing code and make it 100% closed, it's just the kernel I have to be careful about. It's not that I'm trying to steer them away from using Linux in their product, I'm just making sure they know what they're doing. Once again, I have no idea how anal these people might be, but if they are, this is stuff they should be aware of.
        • Well, if they can modify the kernel to work so well, maybe they can just write their own kernel. All the GPL says is if you modify someone else's work, then you need to pass the revisions downstream (to the people you distribute the binaries to). If you're not willing to do that, then you don't get the benefit of a free kernel with source code, and you'll just have to make your own.

        • Re: (Score:2)

          by dedazo ( 737510 )

          the GPL says that I have to release the modified versions of any GPL code I've used.

          Not to side with twitter here, but the GPL says you have to make available the source of any modifications you've made to GPL'ed software if you are also distributing them. If you're not, then you don't have to do anything. Like Google. Although I think the GPL3 will pretty much kill that (I think?).

          Now in this case obviously there is intent to distribute modifications to Linux in the device(s) the company will sell, but

          • Re: (Score:3, Interesting)

            by Grishnakh ( 216268 )
            Although I think the GPL3 will pretty much kill that (I think?).

            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 t

            • Re:GPL is not a problem ... (Score:4, Informative)

              by codemachine ( 245871 ) on Thursday May 03, 2007 @09:13PM (#18982539)
              If I recall, there were 3 things that GPLv3 was originially going to accomplish, all of which had to do with ways people were perceived to be abusing GPLv2:

              - address patents and how they may affect distribution of code
              - close the TiVo problem of tying hardware to a software revision (where people can't truly modify their own GPL code on their own device)
              - close the ISP loophole where you aren't really "distributing" your code, so you don't have to share it

              We mostly hear about patents, and we heard a bit about the hardware issue when Linux objected to a GPLv3 revision. Not so much makes the news about the ISP loophole. I am not sure what the latest draft of the license does in this regard.

          • Now in this case obviously there is intent to distribute modifications to Linux in the device(s) the company will sell, but still.

            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 har

        • Re: (Score:2)

          by xtal ( 49134 )
          You only have to release changes to people who you liscence the code, or product to. You do NOT have to release the changes to the open community. The person who receives the changes is free to do that, if they want, however.

  • Realtime Control with Linux Considered Harmful (Score:5, Interesting)

    by TerranFury ( 726743 ) on Thursday May 03, 2007 @08:19PM (#18981997)

    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.

    • This sounds more like a bad job on the manufacturers side than a problem with linux itself.

      • Re:Realtime Control with Linux Considered Harmful (Score:5, Informative)

        by dugenou ( 850340 ) on Thursday May 03, 2007 @11:18PM (#18983409)
        Hard realtime works great on Linux, but choose your manufacturer carefully. All the following are free and open source.

        When it comes to hard RT extension (even in userland), I tend to prefer Xenomai [xenomai.org] over RTAI. Xenomai has better non-x86 support (ARM is there), nifty so-called skin support for legacy API's (VxWorks, uITRON, ..), and very good community.

        Talking about distro, ELDK [www.denx.de] is best what comes to mind. This is industrial grade software, free as in beer and speech, but with commercial support if needed. The toolchain is excellent. What goes into the flash image must be hand-picked because only you know the necessary stuff.

        If you are in D/A A/D business, then have a look at Comedi [comedi.org], it is also RT enabled by the comedi-rtdm project.

        All these tools/projects are used and backed by industry. I'm a simple user of these tools, and they make my day life happy.

        • Thanks for the links. May be useful in future if I do something like this again. *bookmarks*
        • If you use the right extension, it is NOT harmful.

          I have used Xenomai in a real product that shipped for a company that does embedded real-time systems for industrial controls. This was on a Freescale mpc5200 (PowerPC). Worked nicely for our real-time application. A guy named Philip Gerum heads up the project and is a swell guy to work with. If you need real-time support on x86, ppc or arm, then xenomai is definitely the way to go.

          Accolades Xenomai!

  • Speaking of VxWorks (Score:2, Informative)

    by Anonymous Coward
    If your company if comfortable with VxWorks, how about Wind River's offering...

    http://www.windriver.com/announces/rtlinux/ [windriver.com]
    • *um*... Tried that once (their Linux offering). It was good, but it wasn't exactly small when we tried it . It wanted a target with well over 500M of flash, and that was after I went through their messed up dependency tree and cut it down from the default size which was just crazy. We did work with them on it but it wasn't shrinking fast enough for our liking.
  • 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.
    • 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.

    • Re: (Score:3, Insightful)

      by dhasenan ( 758719 )
      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

      • Re: (Score:3, Interesting)

        by Dahamma ( 304068 )
        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 [busybox.net] will get you everything you need in a multicall binary under 1MB (dynamically linked
    • 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?
  • 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.

    • Why people use Montevista or Windriver (Score:1, Insightful)

      by Anonymous Coward
      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 i
  • 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.

  • Some ponderings to think about (Score:3)

    by wellingj ( 1030460 ) on Thursday May 03, 2007 @09:47PM (#18982813)
    You might want to check out BuildRoot [uclibc.org]. It's what Gumstix [gumstix.com] uses for their distributions and it works pretty well.
    They have even has the rt patch [kernel.org] 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 ...
  • Montavista [mvista.com] hired spammers [macarthurservices.com] to send their ad [80211libre.org]. Not nice. They didn't even reply to the developer who complained [lkml.org] in LKML.

  • Why?? (Score:2, Redundant)

    by sunderland56 ( 621843 )
    Why do you want to do this? Sure, it's "cool" and you'll get modded up for life on /. - but is it a wise decision?

    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:

    1. A learning curve - things work differently, and all the function names are different.
    2. You spend some significant time configuring
    • I worked for years with Nucleus+ and VxWorks, and tried WindRiver RtLinux. And honestly, I really like all of those, but you can't really compare Nucleus+ and Linux because they are not designed for the same usage.

      Nucleus+ is a small closed OS (that means you need to statically link everything you need unless you use something like a Java virtual machine on top of it). It can be OK, but not for everyone.
      Also note that I rewrote the dynamic memory allocation from scratch because the one provided with Nucleus

  • NetBSD (Score:4, Interesting)

    by allenw ( 33234 ) on Thursday May 03, 2007 @11:05PM (#18983329) Homepage Journal
    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 [netbsd.org] for more information.

  • RTEMS rather than LINUX (Score:2, Informative)

    by Anonymous Coward
    Linux is not the only open source solution for embedded devices: Other include

    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.

  • My company went with Lynuxwork's BlueCat [lynuxworks.com] 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
  • As the page says, http://ecos.sourceware.org/ [sourceware.org]

    eCos is an open source, royalty-free, real-time operating system intended for embedded applications. The highly configurable nature of eCos allows the operating system to be customised to precise application requirements, delivering the best possible run-time performance and an optimised hardware resource footprint.

    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

  • Roll your own (Score:3, Interesting)

    by bensch128 ( 563853 ) <bensch128@@@yahoo...com> on Friday May 04, 2007 @02:42AM (#18984583)
    Thats what we did:
    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!
  • 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)

  • The one you build... (Score:3, Insightful)

    by wolf31o2 ( 778801 ) on Friday May 04, 2007 @03:33AM (#18984831)
    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.

  • Observation about support (Score:1, Insightful)

    by Anonymous Coward
    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.
  • 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.

    Snapgear
    http://ftp.snapgear.org/pub/ [snapgear.org]

    armedslack
  • 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.

  • These guys [picotux.com] might know something about embedded Linux. The info [picotux.com] page says uCLinux.
  • 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. Other

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close