Embedded Linux Primer 59
s1axter writes "Embedded system development is crucial in this day of high tech specialized appliances and devices. However much of the knowledge of embedded development resides in the heads of engineers who have been doing it for years. The hardware aspect of embedded systems is now available to the smaller startup companies, however many specialized, proprietary operating systems are not. This is where Linux and the book Embedded Linux Primer: A Practical Real-World Approach enters. Embedded Linux Primer is written to introduce engineers and designers to using the Linux operating systems for embedded applications." Read on for s1axter's review.
Prentice Hall's Embedded Linux Primer by Christopher Hallinan was published September 18th, 2006 as part of their Open Source Software Development Series. Very much like a textbook, Embedded Linux Primer is very informative and an excellent source of information for an engineer looking to enter or move to the embedded Linux field. The text is a decent size, with 537 pages spanning 17 chapters and 6 appendices; it retails for around $45 USD.| Embedded Linux Primer | |
| author | Christopher Hallinan |
| pages | 537 |
| publisher | Prentice Hall |
| rating | 9 |
| reviewer | s1axter |
| ISBN | 0-13-167984-8 |
| summary | A Practical Real-World Approach to Embedded Linux |
I had some reservations on reviewing a detailed technical book since most of the ones I have are dry and have a very segmented structure. However after taking a look at the sample chapter, chapter 7 "Bootloaders", available on the Prentice Hall website along with the table of contents for the text I figured I would give it a look and I am very glad I did.
Many technical books focus on a specific demographic in the technology world, mostly beginners or professionals expanding their knowledge base. I was quite pleased to see this text is written for both professional developers and emerging embedded engineers.
Professional engineers will find the text informative on the Linux operating system and how flexible it is to implement on even the most custom hardware. The author understands that a large number of embedded system engineers work with proprietary systems and explains items that might be new and different than these systems. For example Chapters 4-6 detail the Linux boot sequence and describe common pitfalls engineers new to the embedded Linux methodology might make. Chapters 8-11 dive further into the operating system and explain device driver creation, the important file system and how Linux handles volatile and non-volatile memory systems using the MTD subsystem.
Engineers starting in the field of embedded systems will find information on what an embedded system is in Chapter 1, processor and board comparisons in Chapter 2 and setting up an embedded environment for development in Chapter 12.
It is quite obvious throughout the text the author has an extensive in depth understanding of embedded systems and the inner workings of the Linux operating system. With such a deep understanding of the material an author many times explains items in such detail it clouds the mind of the reader. The first line in Chapter 2 says (paraphrasing) that the best way understand something is to understand the 'big picture' . This is exactly the approach the author takes through out the text, first explaining the theory and high level aspect of the system, then diving into the detail of how it is done on the low level. Also, rather than get sidetracked in chapters by explaining every processor attribute or software package, the author suggests external sources mid-text and in the "Suggestions for Additional Reading" at the end of each chapter.
For the first edition of a book, Embedded Linux Primer is rather complete, with the only exception being chapter 8, Device Driver Basics, which is...well, rather basic. I started the chapter expecting to finish with a detailed understanding of how the Linux kernel processes driver requests and a look into some common drivers. This is not the case; for a second edition of this text I would suggest beefing up this chapter to provide more of an insight into kernel-driver interaction.
Overall Embedded Linux Primer is an excellent source of information for both the seasoned professional and aspiring embedded engineer. I know that when I dive fully into the world of embedded Linux this book will have a permanent place on the bench right next to the spec sheets.
s1axter is the main poster for Geeksinside.com, which is a hardware hacking, technology blog that showcases projects, reviews and technical links.
You can purchase Embedded Linux Primer from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Sounds promising. (Score:2)
Re: (Score:3, Funny)
And NetBSD isn't Linux, but you did mention running things on toasters.
Re: (Score:1)
Looks like a good book. I've dabbled in embedded systems before. For anyone who has had reflashed their router with DD-WRT or think programming your toaster could be fun, this could be a good read.
i've always expected embedded linux to require a lot of kernel experience. i chatted to someone at the linux expo a few years ago, and they were mainly interested in the porting of the kernel to a risc processor. i'm not sure what their end goal was once they could get their risc system to work, but i'm sure it's got a lot of applications.
personally i've wanted to make a huge port router, something like a 48 port beast, but getting that on a system with enough irqs is hard. the best i can get is 8, and
Re: (Score:1)
Re: (Score:1)
I must be missing some important detail here: how is a 48-port router any different from, say, a regular router with a 48-port switch ? Do you really need an IRQ for each port ? Don't they use "switch fabric" for those things ? Hypercube-style topology or the like.
yes it's possible, no, but it's something i've wanted to do for a long time... i just want to make a single, all contained device that has proper dedicated ports. the switch fabric has a single point of contention, using dedicated ports means the hardware at the card can handle the buffers and all the magic.
Re:Engineers doing it? Yeah, plenty of them. (Score:3, Interesting)
I will probably buy a book like this one to help me un
I bet! (Score:3, Funny)
I bet! Do you get a lot of zombie processes?
And how many chickens do you guys kill per port?
primer (Score:1, Funny)
Why worry about embedded driver development? (Score:5, Insightful)
For the first edition of a book, Embedded Linux Primer is rather complete, with the only exception being chapter 8, Device Driver Basics, which is...well, rather basic. I started the chapter expecting to finish with a detailed understanding of how the Linux kernel processes driver requests and a look into some common drivers. This is not the case; for a second edition of this text I would suggest beefing up this chapter to provide more of an insight into kernel-driver interaction.
Embedded or not, Linux uses the same driver structure. Most often, the same drivers as well. That's the main advantage of "embedded" Linux - it's no different than any other Linux. Just smaller. Try running a Windows XP program on Windows CE to see what I mean.
If you want to chase driver development, read Linux Device Drivers [oreilly.com], by O'Reilly. It's IMHO the definitive book, and works just the same for embedded Linux. A single chapter in an embedded how-to book could hardly be expected to capture everything you'd need.
Re:Why worry about embedded driver development? (Score:4, Informative)
If you want to chase driver development, read Linux Device Drivers, by O'Reilly. It's IMHO the definitive book, and works just the same for embedded Linux. A single chapter in an embedded how-to book could hardly be expected to capture everything you'd need.
I didn't like this book; it stuck to basic network, char and block devices, and while it provided a good deal of detail on these, it completely avoided actual hardware interfacing: PCI (e/x too), PCMCIA, USB, basic memory/interrupt allocation, etc. Unfortunately, those are the trickier bits to driver writing.
Re: (Score:2)
Re: (Score:2)
That's what I ended up doing, and I got it to work, although I can't say I fully understand all of the details yet. the PCMCIA system is in an enormous state of flux, and the code is the only place you can really look. I spent a lot of time going through lxr.linux.no, but some documentation would have been helpful.
Embedded (Score:4, Interesting)
Re: (Score:2)
Re: (Score:3, Informative)
Routers, Phones, Now What? (Score:1)
@yg
Re: (Score:1)
Re: (Score:2)
Me too, although I wouldn't be suprised if there isn't some Postscript, network printer out there that runs embedded Linux...
Well here it is, a quick Scroogle search finds: Red Hat's Open Source Embedded OS to Power Post-PC Printer Device From Brother [findarticles.com].
Re: (Score:2)
Re: (Score:3)
Just a reminder.
Re: (Score:1)
Re: (Score:1)
Re: (Score:2)
Device Drivers issue (Score:4, Informative)
Detailed understanding requires a whole bookshelf, and several years hacking away at a couple of drivers, but here is a good start.
http://lwn.net/Kernel/LDD3/ [lwn.net]
Re: (Score:2, Interesting)
I've been programming for a good 25 years now, and the one thing that goes through my head all the time is "Why is this stuff as baroque as it was 25 years ago?" It comes out in various forms, like "Why do I have to write yet another business app that's 99% identical to the last" and "Why in god's name did some Web 2.0 idiot have to invent yet another Smalltalk dialect?", but the underlying sentiment is the same.
The hardware has evolve
Re: (Score:2)
You are welcome to use any standard you like, its not so complicated. Serial Data over rs232 still works great. Hell zigbee wireless emulates rs232 behavior even over usb. It's not as complicated as it sounds. Now you want to talk in the kernel. Then you have to think "in the kernel". And that can be complicated, it is documented, but you cannot expect to just get it.
elinux.org (Score:4, Informative)
HW recommendations? (Score:3, Interesting)
I've seen a lot of embedded developer kits but I don't know where to start as none really list what kind of OS they'll support.
Any suggestions on HW would be welcome!
Re: (Score:3, Informative)
Re: (Score:3, Informative)
It uses U-Boot and the whole uClibc [uclibc.org] BusyBox [busybox.net] Buildroot [uclibc.org] stack for development.
It is rather slick to work with. They even added support for the rt patch not too long ago which was a big bonus for me.
I've been working with it for about a year now and I have to say it's really the best solution for embedded Linux beginners.
Re: (Score:1)
Here you go (Score:2)
click on the AVRfreaks wiki link for advice on exactly what to do to get started.
at 75 bucks, it is one of the cheapest kits you can get. If I am not mistaken you can download all the software for free.
Or find a embedded engineers PUG and talk to them. Someone might set you up with something they don't use anymore.
Re: (Score:2)
What is an embedded system? (Score:5, Interesting)
I do embedded systems for a living, and was asked this question during my intervuiew. My answer: "a system that is the brains of something else, and is not necessarily visible as a computer". They thought that was an interesting answer, and I got the job.
I think embedded systems are interesting. The challenge is obvious: it's easy to make a system with a multi-GHz processor, gigabytes of RAM and terabytes of disk do something interesting and/or useful. Can you make a computer the size of a stick of gum do something interesting and/or useful? That is the challenge.
The other challenge is that your embedded system must be reliable. People will not tolerate toasters that won't boot. The testing requirements can be interesting, and nerve-wracking too. How do you report "I'm broken" when all you can do is flash an LED?
This is where you get to find creative new abuses for mmap(), learn what those MTD device drivers in the kernel do, find just what JFFS2 will (and won't) do, and so on.
...laura, embedded Linux on 68k and StrongARM
Re: (Score:3, Interesting)
It's sometimes also stressful, if you made a bug it can cause the machine to break. I once was bug-hunting with half a factory looking over my shoulders because production had halted. You have to be able to stay calm then.
PS: to answer your qu
Re: (Score:2)
In a current project I found myself with a sufficiently flexible LED interface (because I designed it :-) that I could do exactly that. And that's what it does.
It's not Linux, but Brew is so bizarrely idiosyncratic that it must count for something.
The other thing with embedded stuff is you have to get it right, because the code is going to be burned in to lots of devices that are going to go out in the field, and you can't get them back if you goof.
...la
Re: (Score:2)
The idea has been nagging me for ages
BTW, I've never heard of brew before, so I looked it up. Is it any good? My gut feeling tells me it's more marketing than software, but that's just by looking at the website.. I could be completely wrong.
Re: (Score:2)
Brew suffers from the usual cell network security paranoia, and specifications written by lawyers. It's really one for the pros - Qualcomm make it just about impossible for a hobbyist to do anything with Brew on real hardware. Any schmuck can download the SDK and play with the emulator, but that's as far as you can go unless you're a company.
At runtime, Brew apps are reminiscent of really old Windows apps (i.e. completely event driven), but with non-blocking I/O to make things interesting. What looks lik
Re: (Score:1)
Good Embedded Linux Starter Kit (Score:2, Informative)
Am reading the book now (Score:3, Informative)
This book is uneven, but largely its a good book. The bootloader chapters are a very good intro - it even has a porting section going into the ppc assembly part of u-boot. The init sections of the kernel are also a good intro. The chapter describing gdb and kernel debugging is good, as I learned several tricks using macros with gdb that I think will help me a lot. Lots of tools like cpp are explained that I didn't know about.
However, where it comes short is that I still really need help with early debugging the bootloader and kernel init using the bdi-2000 (a hardware debugger that connects to the jtag interface that most boards have). It barely mentions the bdi-2000, which is a fundamental tool as its pretty much the only way to debug very early booting problems when porting.
I also think the flash section has too much of a jffs2 focus, and not ext2 focused to match most users. The driver section is very module focused and so bare it could be omitted.
Overall, I'm happy with the book in that it does have a lot of info that I haven't found elsewhere. It really convinced me I need to read the manuals of my hardware more as there is no alternative. The book has helped, and I think its a great intro.
First hand experience: Books not enough (Score:1)
That said, neither is the "linux is the same embedded or not" argument all that good. I sure wish it was. Most information out there is about the x86 system, which embedded app