MontaVista opinions?

We went with MV for my current Xilinx V4 based project. The theory was that we'd have something working out of the box (particularly 2.6 kernel based) so we could just focus on the signal processing part of our project. The reality has been:

devrocket (the main MV tool) is very buggy particularly the tool for the root file system. I frequently have to close and reopen to get changes to take affect. documentation is mediocre integration is poor - basically if you don't know how to build a linux kernel and filesystem from scratch you'll not be able to do it with the MV tool either support is okay - we get decent turn around on questions but frequently end up with they don't support or don't have ready the piece we need coverage is poor - they are stuck back at the 2.6.10 and on my platform elementary things like an SPI driver are missing

The last item is really the kicker. I don't care what your project is, eventually you are going to be rooting around menuconfig or patching driver code or figuring out how to use objcopy, etc. to the point that EVENTUALLY you'll have to know everything MV knows about your platform anyway. So do you want to deal with all the glitches with the mainline kernel code AND all of the bugs/glitches in the MV tools or just the former.

Personally, I think MV is biting off more than it can chew by trying to support dozens of processors. If they focused on a pre-rolled Xilinx tree that really worked with the Xilinx tools and was a one button click to generate kernel, modules, RFS into a single .bin to burn to flash they'd add a lot more value.

MV was good in that I was able to get SOMETHING up quickly to show my bosses but the overall value to the project is considerably less than the $30K we paid for it. But that's not MV's fault, the real problem in my case is that Xilinx has farmed out Linux to MV rather than doing it themselves. The result is a "worst of both worlds" solution that's left my team wasting time on stupid little things that have nothing to do with our product.

-Clark

Thanks very much for your candor.

Dave

Hello ,

If you have linux expertise, why dont you pickup the kernel that you want, configure it, use gcc to build your own embedded linux!! You have lots of how to documents to speed up your work, even if you are new to embedded linux! If you are looking for size or speed optimization there are lots of interesting documents which mention the steps to be followed for size/speed for the embedded linux kernel.

Best Rgards, Vivekanandan M

Dave Littell wrote:

Do you think you'd have avoided this with another OS, for the same cost ?

Let's face it, the attraction of Linux is that it's cheap.

bosses

we

that

time

That's a good point. I should be clear that I'm down on Xilinx and MV not Linux. I'm a big advocate of Linux.

For a couple hundred bucks in parts I have a system now with 2.6 level kernel and USB host functionality where I can plug in flash drives, blue tooth headsets, wireless lan cards, gps receivers, etc. I can control it with raw USB, serial port, PPP over serial, TCP/IP, bluetooth, etc. I can run a web sever, telnet into it, nsf mount drives over to it, etc. None of the other OSes out there come close to this level of functionality. That's why in my opinion they always pimp "real time" issues to convince people that stock Linux is inadequate. The truth is as long as you architect your system correctly "real time" is a non-issue.

As for development, with linux virtually any problem you run into is a google search away. With millions of developers on thousands of platforms there is a massive amount of free support on the web. How many people out there know anything about Nucleus, for example?

So yeah, I wouldn't want to own stock in any boutique OS company trying to get by charging per unit licensing fees. In fact, MV probably has the right business model it's just that they haven't done their technical work very well.

-Clark

All true.

real-time, or at least task prioritization of any kind, can be an issue. With some of the other OSs eg Integrity, you can partition up the available CPU time so tasks always get a fixed number of CPU cycles to work with. Priorities in Linux are a bit on the fiddly side.

My experience with Montavista has been okay; on some occasions I've had kernel developers (who are on their payroll) step in to help with support calls. You won't get that for free, I can tell you. What I suspect is that support is better on some architectures than others; this is true of Linux itself. Out of all the possible embedded CPUs (other than x86), PPC is probably the best supported in the kernel.