Review of Embedded Linux Book

An Anonymous Coward writes "LinuxDevices.com has just published a very detailed review by Jerry Epplin of the new book by Craig Hollabaugh, Embedded Linux -- Hardware, Software, and Interfacing, published by Addison Wesley Professional. Quoting briefly from the review, "A system developer planning to use Linux for an embedded design is faced with a number of decisions, not the least of which is whether to use a packaged commercial Embedded Linux distribution or to devise a homebrew solution from the available free tools and components. The custom approach has much appeal because of its low cost and radical flexibility, allowing one to choose any approach or tool rather than those chosen by the toolkit vendor. But with this flexibility and low cost comes the chaotic documentation typical of Linux. Thus, books like [this one] fill a significant void . . .""

Comments

Interesting but

[RTFA Man]

The only disagreement I have with this is Hollabaugh's philosophy regarding non-x86 architectures. He contends, "This book's examples show that working with the [ARM-based] MediaEngine and the [PowerPC-based] RPX-CLLF was as easy as working with the [x86-based] MZ104."

This assertion is hard to credit -- even with the author's well-written scripts, acquiring and building cross-development GNU toolchains certainly takes more time than simply using those already provided on your desktop computer.

Hollabaugh had to modify the netcat source in order to compile it for ARM, show that even the author himself has had his share of trouble working with non-x86 architectures. The lesson is certainly not that x86 should be the only architecture considered, but it is fair to say that a slight bias toward x86-based devices is prudent when choosing embedded Linux target platforms because of the maturity of Linux on that architecture.

Re:Interesting but

[JKR]

I agree with you 100%. The GNU tool chain is not a no-brainer on non-x86 platforms, presumably because the projects rely on testing feedback to find and fix bugs.

For my first (PPC-based) project where I tried to build a toolchain from scratch I had real problems finding a mutually compatible set of binutils, gcc & glibc that could successfully compile QT Embedded (i.e. C++).

I think this presents a real problem for business. The source code is freely available, but some feature or other doesn't work on your chosen platform without extra patches (gcc in particular, but also glibc). The appropriate set patches is hard to find - Redhat and Montavista know about them, but they ain't telling because their business model effectively revolves around knowing what you need to do to make the software work. So, "Open Source" becomes "Closed Knowledge" because at the end of the day, everyone needs to make money and if the source is free, then charge for the knowledge / expertise.

This makes support an interesting proposition - you get companies who will help you, but only by doling out the information a piece at a time - because in their marketplace, knowledge is power.

Now, Montevista supply (excellent, patched and working) toolchains for all their supported platforms for "free" (or rather the cost of downloading 3 ISO images). By doing so, they effectively try to lock you in to their support model (which is around $10,000 a year for a single point-of-contact), especially when you discover that the range of BSPs they ship is pretty small, and expensive to add to - you're on your own if you're platform isn't on the list.

In the end, it's no better than proprietry solutions - just different.

Jon

Re:Interesting but

[alext]

This is unfortunately just wishful thinking, as others have pointed out.

1) The development tool chain simply isn't there for non-x86 developments such as ARM, unless you pay for it.

2) The deployment problems are crippling because all apps have to be targeted. And not just ARM vs. x86, but often ARM 9 vs ARM 7, PIII vs. AMD vs. VIA etc.

PDA users simply can't and won't build apps for themselves. The Linux model breaks down, resulting in a gift to MS because vendors are trying to avoid using Java, the only viable VM currently available.

Re:Interesting but

[dbarclay10]

Use Debian.

Not only is Woody (the next Debian/stable release, due Real Soon Now) being released for alpha, arm, m68k, i386, sparc, powerpc, mips, mipsel, hppa, ia64, and s390 (that's 11 architectures, friends), but in order for an architecture to actually be officially released, the massive bulk of all packages have to be compiled and ready on that platform - with _the same version as every other architecture_. You won't be getting XFree 3.3.6 on PPC and XFree 4.2.0 on i386. You'll be getting the same.

Oh, right, "not only" :) Most complex packages, which include extensive patches, are organised in a very nice way. 'apt-get source libc6', go into the new directory, and poke around in debian/, there should be a directory there with all the patches that are applied during the build process.

Nice and easy to seperate, pick 'n choose, what have you.

Re:Interesting but

[alext]

Hmmm, you don't work in this field, do you?

...obscure architectures such as ARM do not require payment, just extra legwork. Have you seen .NET on ARM lately? I don't think so.

ARM will be the single most widely deployed PDA and phone CPU. Period.

.NET on ARM? Try here on the Microsoft site (of all places). To quote:

Windows CE .NET allows developers to select the optimal hardware architecture for their projects by supporting a broad range of processor families, including x86, Xscale, ARM, MIPS and the SH series. Device bring-up is now faster than ever with Windows CE .NET providing numerous board support packages and features such as the Platform Wizard, which provides preconfigured design templates for embedded devices such as handhelds, smart phones, Web pads, retail point-of-sale devices and set-top boxes.

Your devastating critique continues:

What does this [deployment problems] have to do with anything? There are many, _many_ sites that are dedicated repositories of binaries for particular architectures.

There are? I think you'll find that most applications (as opposed to platform builds) are offered in a few builds that the authors know about, and finding any others is down to luck.

Let's try searching for 'linux tetris' in Google, shall we? OK, here's the first one. Oh dear! There's one build, and it's for x86 Mandrake. Care to point to one of your "many, many binary sites" that has it built for a PPC, for example?

And, lastly, our special bonus, the extra-insightful:

Having a VM is a waste of time... Any architecture can be virtualized

Riiiigghhtt. Well, I hope you've taken the opportunity to tell Microsoft, Sun and all those phone vendors that they're wasting their time pushing VMs. I bet they'll be kicking themselves soon! Perhaps you'd like to point to a phone or PDA that runs a foreign CPU instruction set, just as an example?

Why Linux ?

[MosesJones]

Why not Symbian, QNX/a> or any of these ? This unhealthy obsession of "one size fits all" that abounds in the Linux world is exactly the sort of thing that people on Slashdot complain about the Microsoft world. You can't shoehorn these things without getting a poorer product as a result.

Wouldn't it be a better open source project if someone did what Linus did when he wanted to build an Open Source Unix and do the same for a proper RTOS ? By viewing Linux as the "only" solution it turns into the old "everything is a nail if you only have a hammer" discussion.

News for Nerds would be detailing what is happening in the RTOS and embedded world, rather than just being "News about Linux" to the detriment of better technologies. I know it sounds like a rant, but people like Wind River really do know what they are doing, this isn't a crappy Microsoft driven arena, this is where people really do know their shit, and the customer will not accept failure as part of the package.

Re:Why Linux ?

[nevets]

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.

Re:NetBSD

[dbarclay10]

Woody is not yet released.

Don't install Woody. :)

Install Potato. Or know what you're doing :) It's one, or the other.

If you're not inredibly familiar with Debian ingeneral, you really shouldn't even consider installing something other than the RELEASED Debian...

You were installing the equivalent of an early Red Hat beta release :)