Slashdot Mirror

Seriously.

I spent the last 5 years working for TimeSys, and we did a lot of work to adapt various Fedora Core packages for embedded systems use.

One of the tools we developed along the way was something called tsrpm, a set of wrappers for RPM that makes cross-compiling RPMs a relatively painless process. It's open source (GPL), has support for a number of different processor architectures (x86, various flavors of ARM and PPC, etc.), and can be used to compile packages using a glibc or uclibc based tool chains. It's non-intrusive, and uses a hint file (standard bash shell script) to conditionally control various phases of the RPM and source code build process. It's even capable of building a cross-development tool chain from source RPMs, though that process can be a little hairy.

When I left, IIRC, we had over 300 RPMs, mostly from FC5, that we could build for a good 9-10 distros (variations of architecture/libc combinations). That was the result of myself and the tsrpm author (Chris Faylor) spending about 2-3 months on the whole thing... and that included the time it took for Chris to get new gcc-4.x based tool chains building for most of the architectures.

If anyone's curious, you can see the free-as-in-[beer,speech] releases of tsrpm and some whet-your-appetite FC5-based distros here.

Seriously.

I spent the last 5 years working for TimeSys, and we did a lot of work to adapt various Fedora Core packages for embedded systems use.

One of the tools we developed along the way was something called tsrpm, a set of wrappers for RPM that makes cross-compiling RPMs a relatively painless process. It's open source (GPL), has support for a number of different processor architectures (x86, various flavors of ARM and PPC, etc.), and can be used to compile packages using a glibc or uclibc based tool chains. It's non-intrusive, and uses a hint file (standard bash shell script) to conditionally control various phases of the RPM and source code build process. It's even capable of building a cross-development tool chain from source RPMs, though that process can be a little hairy.

When I left, IIRC, we had over 300 RPMs, mostly from FC5, that we could build for a good 9-10 distros (variations of architecture/libc combinations). That was the result of myself and the tsrpm author (Chris Faylor) spending about 2-3 months on the whole thing... and that included the time it took for Chris to get new gcc-4.x based tool chains building for most of the architectures.

If anyone's curious, you can see the free-as-in-[beer,speech] releases of tsrpm and some whet-your-appetite FC5-based distros here.

Seriously.

I spent the last 5 years working for TimeSys, and we did a lot of work to adapt various Fedora Core packages for embedded systems use.

One of the tools we developed along the way was something called tsrpm, a set of wrappers for RPM that makes cross-compiling RPMs a relatively painless process. It's open source (GPL), has support for a number of different processor architectures (x86, various flavors of ARM and PPC, etc.), and can be used to compile packages using a glibc or uclibc based tool chains. It's non-intrusive, and uses a hint file (standard bash shell script) to conditionally control various phases of the RPM and source code build process. It's even capable of building a cross-development tool chain from source RPMs, though that process can be a little hairy.

When I left, IIRC, we had over 300 RPMs, mostly from FC5, that we could build for a good 9-10 distros (variations of architecture/libc combinations). That was the result of myself and the tsrpm author (Chris Faylor) spending about 2-3 months on the whole thing... and that included the time it took for Chris to get new gcc-4.x based tool chains building for most of the architectures.

If anyone's curious, you can see the free-as-in-[beer,speech] releases of tsrpm and some whet-your-appetite FC5-based distros here.

We currently build something like 70 releases per night... None of this is as complex as a Linux distribution; we're only a small company which is why we've automated the process.

At my previous company, we did something very similar - and there, we were building (embedded) linux distributions. Take a look at LinuxLink for a public view. Still not as hairy as a full Fedora distro, but still something pretty hard to coordinate. IIRC, we had the capability to do incremental builds on something like 30-40 distros per night, and could manage about a dozen full rebuilds per day if we needed to do so. When I left, they were working on a board farm that would enable automated testing on native (not emulated) systems.

All in all, it was an interesting problem to work on. The build system wasn't the real bottleneck... once you figure out how to do what you want to do, and then how to do it effeciently, you end up with a build system that scales to handle whatever hardware you throw at it. If we had wanted to build 70 distros per night, for example, we would have just had to double the number of build machines in our build pool. The really interesting part (at least for the embedded stuff) was figuring out how to generate those 70 projects in the first place :-) A lot of that knowledge ended up in tsrpm, a tool specifically designed for for cross-compiling source RPMs.

We currently build something like 70 releases per night... None of this is as complex as a Linux distribution; we're only a small company which is why we've automated the process.

At my previous company, we did something very similar - and there, we were building (embedded) linux distributions. Take a look at LinuxLink for a public view. Still not as hairy as a full Fedora distro, but still something pretty hard to coordinate. IIRC, we had the capability to do incremental builds on something like 30-40 distros per night, and could manage about a dozen full rebuilds per day if we needed to do so. When I left, they were working on a board farm that would enable automated testing on native (not emulated) systems.

All in all, it was an interesting problem to work on. The build system wasn't the real bottleneck... once you figure out how to do what you want to do, and then how to do it effeciently, you end up with a build system that scales to handle whatever hardware you throw at it. If we had wanted to build 70 distros per night, for example, we would have just had to double the number of build machines in our build pool. The really interesting part (at least for the embedded stuff) was figuring out how to generate those 70 projects in the first place :-) A lot of that knowledge ended up in tsrpm, a tool specifically designed for for cross-compiling source RPMs.

Say, something like LinuxLink from TimeSys. You can sign up for a free trial with LinuxLink, or if even that's too much for you, you can take a look at some free (as in beer) tools and FC5-based distributions built using LinuxLink on the TimeSys crossdev site.

Of course, I'm a bit biased, since I'm a former TimeSys employee and helped build a lot of what they're offering :-). Having been through all the pain of building a few hundred Linux SDKs over the past five years, I'd really, really, really recommend using something like LinuxLink. It probably takes away 95% of the pain and frustration of building a custom embedded Linux distro, which lets you get on to doing the really fun stuff more quickly.

Say, something like LinuxLink from TimeSys. You can sign up for a free trial with LinuxLink, or if even that's too much for you, you can take a look at some free (as in beer) tools and FC5-based distributions built using LinuxLink on the TimeSys crossdev site.

Of course, I'm a bit biased, since I'm a former TimeSys employee and helped build a lot of what they're offering :-). Having been through all the pain of building a few hundred Linux SDKs over the past five years, I'd really, really, really recommend using something like LinuxLink. It probably takes away 95% of the pain and frustration of building a custom embedded Linux distro, which lets you get on to doing the really fun stuff more quickly.

You'll need to add (or build) your own cross-compilers and debuggers.

If you're in the "add" camp here, I'd like to suggest you take a look at http://crossdev.timesys.com. This is the free (in both senses of the word) side of TimeSys, where I work; right now, we have freely downloadable releases for x86 and ppc7xx. These include cross-compilers (glibc and uClibc), host system tools, and over 400 target system packages. All the packages are based on FC5 rpms and built using tsrpm, a GPL tool (also available on the site) that makes cross-compiling most rpms trivial.

If there's something in particular you're looking for, join the mailing list and let us know. We're particualrly interested in hearing about what other processor architecture(s) and target system packages people would be interested in seeing us work on.

Is it straightforward to get Windows to cross-compile a Linux kernel for a handheld device?

Well... I've got bad news, and good news, and a question.

The bad news is: no, it's not straightforward.

The good news is: There are at least a few people who have already figured it out.

The question is: What's your time worth to you?

You're right. At least since 2002.
http://www.timesys.com/index.cfm?bdy=home_bdy_news .cfm&show_article=5

Your assumption that there are plenty of other profitable open source companies is wrong.

Timesys. MontaVista Software. Trolltech. SuSE. IBM's Linux ventures.

My current employer uses and contributes to open source software, although we're a proprietary software company -- using OSS tools for infrastructure functions saves us money, and contributing back reduces our software maintenance costs. My last employer is a member of the above list. They survived the bust, and I've heard rumors that they've started turning a profit.

Coming from this background, I didn't find this article suprising at all. There's plenty of money in OSS, as long as you're smart about making it.

Imagine what a free common system might be a better starting ground for telecom equipment -- I can see devices brought to market quicker. What does that do to people like other RTOS developers?

Java is being worked on to deliver stable guaranteed time to interrupt?

Exactly. It was the first JSR created as part of the Java Community Process. The final API can be viewed on the JCP website. The "reference implementation" being used for testing can be found here.

Keep in mind that the API is most likely to show up on hard real time systems and probably won't be available on your standard desktop OSes. (Windows? Hard realtime? *rolls eyes*)

QNX is older than linux. It's a microkernel. It's realtime. Linux is neither.

Stock Linux is neither. I personally know of at least one company that offers a hard real-time version of Linux.

ObDisclaimer: yes, I work for TimeSys.

QNX is older than linux. It's a microkernel. It's realtime. Linux is neither.

Stock Linux is neither. I personally know of at least one company that offers a hard real-time version of Linux.

ObDisclaimer: yes, I work for TimeSys.

Vendors now claim worst-case interrupt latencies under 1ms, which is far better than it used to be.

Under 1ms? Pfft. Slackers.

How about this - TimeSys Linux claims a best case latency of under 10 microseconds, and a worst-case latency of ~50 microseconds. Granted, it's with a custom kernel and proprietary modules, but it still shows you what Linux is capable of.

Heh. Just looked at the date on the paper - it actually shows what Linux was capable of, two years ago. It's probably improved a wee bit since then, don't you think?

Taken from the article you reference:

It has to be said that Red Hat Inc. does not claim any real-time behaviour.

SO... they compared a RTOS with an (admitedly) non-realtime OS? I'm not surprised at the results.

RedHat markets ELDS as an OS for embedded systems. Not all embedded systems require realtime performance. Heck, even systems that require realtime performance don't always require the level of performance that QNX can deliver. There's a large number of embedded systems for which even plain Linux without any performance enhancements is a good choice.

If you're really looking for a version of Linux that supports hard real time requirements, take a look at something other than ELDS - <shameless plug> TimeSys Linux, for example </shameless plug>

Where I'm working right now (TimeSys), I've been involved in contributions to Eclipse and Cygwin. Here's some advice:

ASSUME THAT YOU ARE NOT ALLOWED TO RELEASE ANYTHING WITHOUT PERMISSION.

If there's no clear policy already in place, ask. You probably don't have the authority to act as an agent of the company with regard to making decisions about IP. (If you don't know for sure whether you have that authority or not, you should assume not until someone tells you otherwise.) Keep pushing the suggestions/requests up the chain of command until you reach someone who has the authority to say "yea". They may still tell you "nay", but at least you'll be getting a decision on the matter instead of an "I can't make this decision, I don't want to bother my boss, so I'll just say no" response.

START WITH SOMETHING SMALL.

In my case, it was getting permission to submit patches to correct bugs - very small, very simple, very non-threatening things. The argument was that we could submit the patches, or go through the pain of developing the same patches again with each new release of the software we were using. That's a good way to get the foot in the door: show that there's a benefit to submitting patches that outweighs any perceived risk. If you can show that you spend X days out of every release cycle generating the same ol' patches again and again, it's an even more convincing argument.

DON'T PUSH TOO HARD.

For some companies, this is a big step to take. Let the folks who make the decisions think about the idea, answer their questions honestly, and be persistent without harassing them every day about the issue. You don't want to have them tell you "no" just so you'll quit bugging them.

BE HAPPY WITH WHAT YOU GET.

I don't mean that when you get the first "no", you should give up. You need to be reasonable in your expectations - IMHO, submitting patches for bug fixes is fairly minor, and the reaction to that request should give you an idea of how receptive your maangement might be towards the idea of more substantial work & contributions.

My employer lets us submit bug fix patches freely for one project, at the developer's discretion. Minor feature additions in the same project require approval, which is generally easy to get. Other projects require management approval for all patches, no matter waht. Some projects that require copyright assignments are still in the "we're considering it" phase, and may never be approved. We've contributed at least one large chunk of original code to a project, and are considering doing it for a couple of others, as well, because while we want the software to have feature X, we don't want to have to maintain feature X. That's a pretty good argument to try if you're trying to get approval to submit a patch that adds a feature or functionality to an existing project :-)

It really is the openness of the code that attracts many to Linux. As to create a new RTOS from scratch, well that's a lot of work and not many companies will fund it. Someone did mention eCos from RedHat, but it's still not Linux.

What I mean is that Linux has a lot of drivers. To use another OS, you will not get as many drivers that come with linux.

Some say that Linux is "too big" for an embedded system. But today's embedded systems are not you daddy's embedded systems. They have more power and more memory.

Also you have the buzz word of Linux. We get a lot of reaction when we mention useing Linux for a device. There are a lot of managers out there that have heard the benefits of Linux, real or otherwise, and want to jump on it if they can.

I don't have much to say about Wind River. I use to work for Lockheed Martin, and had to deal with them quite a bit. The vxWorks we had had no support for virtual memory, and only supported FAT filesystems, which gave us a problem with a database server that had thousands of files. We had found a bug in their code and since our department wasn't a big customer, the support we got was to modify the source code ourselves (we had an NDA). This was pretty much the same as an open-source project answer, but we had to pay for the code, not to mention the "support"! Also, I might add that I got the impression that Wind River was pretty at ease with their monopoly on the embedded market that they didn't progress as much as they can/should. They seemed stuck in there ways of doing things, being a monopoly, and unless you were a GM, or maybe another department of LM, you really didn't get much out of them.

Sorry for the rant, and a little disclosure: I work for TimeSys.

I am currently using (and used to work for) Timesys.

They have a bunch of BSPs for PowerPC boards. I don't know about VME support, mostly cause I'm working on something on a PCI bus right now.

Couple of cool things about the Timesys Linux kernel:

(1) Fully preemptible kernel (2.4 series, and not the Montavista-derived one that its in 2.5);

(2) Schedulable interrupt handlers and bottom halves (like IRQ7 is a separate thread);

(3) low worst case interrupt latency (70us on a 700MHz Pentium is what the data sheet says, which isn't as good as say 15us on a traditional RTOS, but that 70us is for a real Linux interrupt or process, not one under RTAI or another real time kernel);

(4) CPU and network reservations - so your real-time processes can request that, for example, 3 out of every 18 milliseconds be reserved on the CPU so that its guarenteed to meet its deadline, etc.

They also have a bunch of simulation and modeling tools so you can do things like RMA, etc., on more complicated systems, etc.

Thanks, I now understand where you are coming from. Sorry I was mainly debating the way things work in Linux. I don't use Robert's kernel, since I use my companies. We have our own version of the Linux kernel that handles preemption.

You can get it at my company's site