Forgot your password?
typodupeerror
Book Reviews Books Media

Embedded Linux Primer 59

Posted by samzenpus
from the read-all-about-it dept.
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.
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
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.

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.
This discussion has been archived. No new comments can be posted.

Embedded Linux Primer

Comments Filter:
  • 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.
    • Re: (Score:3, Funny)

      by jimstapleton (999106)
      I ran NetBSD on my toaster! But the edges of the windows started getting black and crispy, so I went back to just using it for toast...

      And NetBSD isn't Linux, but you did mention running things on toasters.
    • by eneville (745111)

      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

      • by billcopc (196330)
        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.
        • by eneville (745111)

          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.

  • primer (Score:1, Funny)

    by Anonymous Coward
    Sweet. I'll head down to Home Depot after work and see if they have any.
  • by Weaselmancer (533834) on Wednesday June 20, 2007 @03:19PM (#19584809)

    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.

    • by tzanger (1575) on Wednesday June 20, 2007 @03:47PM (#19585189) Homepage

      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.

      • by wellingj (1030460)
        Well you could look at someone else's code...
        • by tzanger (1575)

          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)

    by HomelessInLaJolla (1026842) <lajollahomeless@hotmail.com> on Wednesday June 20, 2007 @03:23PM (#19584863) Homepage Journal
    The smallest Linux computer in the world: Picotux! [picotux.com]
    • OMFG!! That is just adorable! Thanks!
    • Re: (Score:3, Informative)

      by belphegore (66832)
      The gumstix is smaller. At 80x20x6mm the gumstix is 9600 cubic mm. The picotux at 35x19x19mm is 12635 cubic mm, or more than 30% larger than a gumstix. It's also not a linux device, but rather a uclinux device, which is not the same thing.
  • Am I the only one that read that subject, initially, as "Embedded Linux Printer"? Not that that's a totally uncool idea, now that I'm thinking about it...

    @yg
  • Device Drivers issue (Score:4, Informative)

    by MrCopilot (871878) on Wednesday June 20, 2007 @04:27PM (#19585855) Homepage Journal
    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

    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)

      by billcopc (196330)
      I hope I'm not alone when I ask: Why does it have to be so complicated ?

      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
      • by MrCopilot (871878)
        OK, OK , OK. relax, deep breathe.

        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)

    by embill (551301) <`moc.liamg' `ta' `ronyartb'> on Wednesday June 20, 2007 @04:28PM (#19585877)
    Great review and great book. Just wanted to also point out that http://www.elinux.org/ [elinux.org] (a site I edit) is a fantastic wiki for information regarding embedded linux and it's only getting better. We recently merged content from elinux.org (the original) and the CELF Public Wiki. Also, the wiki will be relaunched officially at OLS.
  • HW recommendations? (Score:3, Interesting)

    by ChilyWily (162187) on Wednesday June 20, 2007 @04:40PM (#19586067) Homepage
    Does this book supply any HW recommendations? For me that has been one of the stumbling blocks... what architecture, what device, how much memory etc. to get going.

    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)

      by JustForMe (863749)
      You are better off the other way around. Pick your developer kit (based on the processor, memory, peripherals etc.). Then pick any RTOS that has support for the processor. This way, you can skip learning the boot code for the processor (or, what they call the board support package). If you plan to go with Embedded linux, I would recommend to go through a boot loader like U-BOOT. If U-BOOT supports the processor on your developer kit, you are good to go. Assuming you can get the cross compiler (build tools)
      • Re: (Score:3, Informative)

        by wellingj (1030460)
        I recommend Gumstix [gumstix.com] for beginners.
        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.
    • by j.boulton (661381)
      Can't go past a gumstix (http://gumstix.com/) for a open embedded linux platform.
    • http://www.atmel.com/dyn/products/tools_card.asp? t ool_id=4102 [atmel.com]

      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.
  • by spaceyhackerlady (462530) on Wednesday June 20, 2007 @06:05PM (#19587297)

    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)

      by Mr2cents (323101)
      I write embedded software for industrial machines. It is fascinating. When you run your software and see a machine come to life, it's thrilling. Also, I get to see the insides of lots of machinery, it's like hacking but with a direct line to the company's engineers :).

      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
      • PS: to answer your question: learn morse :).

        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

        • by Mr2cents (323101)
          I just spent the whole evening writing a morse translator :). It works with my keyboard led, tomorrow I'll compile it on an ARM.

          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.
          • 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

    • by s-gen (890660)
      I was asked "What is the embedded equivalent Hello World?" -- my answer "Hello LED" went down fine.
  • Atmel has put out a nice and cheap (80 bucks!!) kit called NGW100 for developing embedded linux devices on their AVR32 series. There is a lot of open community support around it and it seems like a great place to start. I've been thinking about getting into embedded linux for a while.
  • by iksrazal_br (614172) on Wednesday June 20, 2007 @08:31PM (#19588883) Homepage
    I'm on a project building a router using the freescale mpc8548e on a custom board - a pretty powerful processor for embedded work. This is my first embedded project, though I'm a long time linux user and had an early career doing primarily electronics work.

    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.
  • I recently began a coop at an embeded systems company, doing, whatelse, linux development for their platforms. I've read everything I could get my hands on about linux on embedded systems. For they most part, they're all redundant. Orielly's Understanding the Linux Kernel and Linux Device Drivers have been the two most useful books.

    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

Our business in life is not to succeed but to continue to fail in high spirits. -- Robert Louis Stevenson

Working...