Slashdot Mirror
Requirements for Embedded Linux
An anonymous reader sent in: "As Embedded Linux becomes established as a solid alternative to many proprietary OSes and RTOSes, demands on embedded Linux developers and providers are increasing. This detailed technical article by Nicholas McGuire sketches the top requirements for Embedded Linux systems including considerations of user interface, network capabilities, security issues, resource optimization, performance requirements and issues, and compatibility and standards issues."
One thing that I think may detract folks from using Linux as an embedded OS is its hackability. For example, TiVo is now hacked 10 ways from sunday. As long as it's adding hard drives and so on, the TiVo folks have been pretty cool about it, but when the encryption scheme for storing recordings was hacked, that leaves them open to legal problems.
While proprietary EOS's are more difficult (for many of the reasons outlined in the article), they can be much more secure (in the weak sense of security through obscurity) than Linux.
Lots of info on Embedded Linux at the Embedded Linux Consortium
I used to work closely with a development team that made the transition from a proprietary (and, may I add, unmaintainable and unreliable) embedded OS to Linux. Though some of the concerns in the article did come up, especially speed and size issues, those didn't hurt us much. After all, we could afford a better processor and more memory with the money we saved on royalties and maintenance expenses - these were substantial.
Unfortunately, if the many features of Linux and the transition from assembler to C didn't hurt us, the licensing did. Things went very smoothly until we needed to make some big changes to the kernel to accomodate a newer version of our hardware. At that point, there was a schism in the group: some of the developers wanted to change the kernel and release the product without source (the "who would find out?" crowd) and the rest of us knew that Linux was not going to fit our needs anymore unless we wanted to give our work away to competitors.
Well, the "who would find out?" crowd won the first round, and because of release deadlines we "slipped" the kernel changes into the next version of the product. And nobody knew. Except one of us told the legal department about what happened and they became very agitated.
Now our software runs on embedded NetBSD. It wasn't quite as robust as embedded Linux but it works well and we really can't complain. Transitioning to a new OS took a lot of effort but it was a necessary evil. After all, we couldn't risk getting sued out of existence to save a little money.
But the question I draw from this is: why not relax the GPL restrictions a bit for embedded applications? It seems like this area of the market will never be dominated by Linux until companies can stop fretting about licensing problems and start concentrating on coding instead.
-Name withheld so I don't get canned
Its a really good read!
BusyBox for basic embedded versions of common linux apps (e.g. init, cp, sed, etc.)
KDrive a tiny X server from XFree86
Galeon for a fairly small browser (there are some other smaller ones in development (for example Skipstone and Dillo)
What I would do is compile a stripped down kernel, use busybox for most system apps, and have your init scripts call the tinyX server and then instead of using a window manager have the startx script start galeon in full screen mode using tabs instead of separate windows for popups. The only difficult part may be getting mozilla or galeon compiled because of the gtk requirements) You could try the Xlib mozilla port perhaps.
For a little bit of info on how I have done a similar project take a look at my linux on a floppy page.
I think TiVo sees the hackability of its systems to be a selling point. Maybe if the company who made the iOpener (anyone remember thier name ?) had embraced the those who wanted to extend the usabilty of thier machines, they might still be around.
"Our products just aren't engineered for security,"
-Brian Valentine,VP in charge of MS Windows Development
Did your dev team look into using Windows CE.NET or Windows XP Embedded ?
cpeterso
"As Embedded Linux becomes established as a solid alternative to many proprietary OSes and RTOSes"
If anything,the embedded Linux hysteria has died down quite a bit. Linux has it's share of problems in the embedded marketplace. Large memory footprint, filesystems that need time to shutdown, interrupt latency to name a few. I work in the single board computer industry and we've seen a sharp decline in the requests for embedded linux support over the last year.
They stab it with their steely knives,
But they just can't kill the beast.
You mean you want to build a linux-based kiosk?
My company recently went down the path of evaluating several embedded linux suppliers, including Hard Hat Linux, LynuxWorks, RTLinux, and others. This evaluation was for an embedded communications platform.
There are many "real-world" issues that will arise when considering Linux instead of some of the more established embedded OS players (WindRiver/pSOS, Green Hills, Keil, QNX, et al -- see Embedded Systems Programming magazine for a pdf summary of embedded OS providers). These real-world issues, which will vary in importance among organizations for various reasons, include:
In short, development in the embedded world tends to have many more complications associated with it. That's not necessarily bad -- in fact it often makes it more technically challenging and thus professionally satisfying -- it's just something that ought to be recognized, acknowledged, and taken into account when OS decisions are being made.
Andy
I guess the distinctions between embedded and non-embedded systems are disappearing.
Traditionally, embedded systems have a minimal user interface (number pad and 7-segment displays come to mind), minimal ROM and RAM, no mass storage, and hard real-time requirements. For a system like this, Linux (or any desktop, mini, or mainframe OS) seems both inadequate and bloated.
Today's definition of an embedded system seems to be "a portable general purpose computer system". Perhaps we should just call it that rather than use the term embedded system.
At our last meeting, a couple of cool folks from BlueMug in Berkeley came and talked about an embedded Linux prototype they built for a client (photos). Their presentation slide is also online here (2MB PDF).
At the meeting before that, Rob Wehrli of Arizona Cooperative Power came to talk about Clinux (photos). His presentation is online, too.
Enjoy!
This is common issue in the embedded world and sometimes is the main reason linux isn't used. I have been in a situation where linux was considered and one of the reasons it lost out was that we felt the amount of real intellectual property we could put into it was limited. We make our systems from parts that other vendors could also buy and so our software really makes a big difference. In these cases, we felt that we had to use either a BSD based system or a proprietary one that allowed us rights to change the full source. We are currently with the proprietary model but the licensing charges are keeping us looking BSD again.
-- soldack
I've just completed a 3 month development contract for an automotive company using embedded linux, and NO WAY is it that simple. Embedded Linux has a long way to go before it can compete with other systems, most notably in the areas of configuration management (the kernel configuration process for embedded targets is particularly poor) and device drivers (Linux in the embedded world badly needs a Hardware Abstraction Layer). On some popular embedded platforms (think Motorola, and telecoms), it took a major kernel revision (2.2 to 2.4) to fix problems with the UART driver.
The fact that the two most successful embedded architectures have forked their own kernels suggests that Embedded Linux is still quite badly fragmented, and no-one designing a system from scratch wants to see that.
Jon.