Embedded Linux Primer

Christopher Hallinan

Mentioned 12

The #1 practical, hands-on guide to developing systems based on embedded Linux - fully updated with extensive new coverage * *Helps programmers rapidly climb the learning curve, maximize productivity, and handle today's most important development challenges. *Contains new chapters on PCI Subsystem, Hotplug and UDEV, USB, and reducing boot time. *Offers practical coverage of Flash-resident filesystem images, the Memory Technology Devices subsystem, and today's hot new multicore processors. Product manufacturers are increasingly turning to embedded Linux - and thousands of software and firmware engineers must now master it for the first time. Embedded Linux Primer has become their #1 resource. Christopher Hallinan offers practical solutions for the real-world challenges embedded developers face - whether they are experienced legacy embedded systems developers moving to Linux or experienced Linux developers moving to embedded systems. Hallinan introduces Linux in embedded environments, covers all major systems and development issues, and offers dozens of valuable tips, tools and problemsolving techniques. His extensive code examples have been assembled from operational hardware running current versions of embedded Linux using the latest development and debugging tools. This book's wide-ranging, practical coverage includes: Linux kernel initialization; the special role of bootloaders and U-Boot in embedded Linux; the use of embedded Linux file systems, including JFFS2; building Flash resident file systems; using the Memory Technology Devices (MTD) subsystem with today's popular flash memory devices; and much more. This Second Edition has been updated for the latest kernel versions, and contains new chapters on the PCI Subsystem, Hotplug and UDEV, USB, and Reducing Boot Time. Readers will also find a detailed introduction to multicore, one of the hottest trends in embedded computing.

More on Amazon.com

Mentioned in questions and answers.

I want to learn linux kernel programming.

What would be the starting points for that ? What could be some of the simpler problems to target ?

thanks in advance

**TODO** +editPic: Linux Kernel Developer -> (Ring Layer 0)
         +addSection: Kernel Virtualization Engine

KERN_WARN_CODING_STYLE: Do not Loop unless you absolutely have to.

Recommended Books for the Uninitialized void *i

"Men do not understand books until they have a certain amount of life, or at any rate no man understands a deep book, until he has seen and lived at least part of its contents". –Ezra Pound

A journey of a thousand code-miles must begin with a single step. If you are in confusion about which of the following books to start with, don't worry, pick any one of your choice. Not all those who wander are lost. As all roads ultimately connect to highway, you will explore new things in your kernel journey as the pages progress without meeting any dead ends, and ultimately connect to the code-set. Read with alert mind and remember: Code is not Literature.

What is left is not a thing or an emotion or an image or a mental picture or a memory or even an idea. It is a function. A process of some sort. An aspect of Life that could be described as a function of something "larger". And therefore, it appears that it is not really "separate" from that something else. Like the function of a knife - cutting something - is not, in fact, separate from the knife itself. The function may or may not be in use at the moment, but it is potentially NEVER separate.

Solovay Strassen Derandomized Algorithm for Primality Test:

Solovay Strassen Derandomized Algorithm for Primality Test

Read not to contradict and confute; nor to believe and take for granted; nor to find talk and discourse; but to weigh and consider. Some books are to be tasted, others to be swallowed, and some few to be chewed and digested: that is, some books are to be read only in parts, others to be read, but not curiously, and some few to be read wholly, and with diligence and attention.

static void tasklet_hi_action(struct softirq_action *a)
        struct tasklet_struct *list;

        list = __this_cpu_read(tasklet_hi_vec.head);
        __this_cpu_write(tasklet_hi_vec.head, NULL);
        __this_cpu_write(tasklet_hi_vec.tail, this_cpu_ptr(&tasklet_hi_vec.head));

        while (list) {
                struct tasklet_struct *t = list;

                list = list->next;

                if (tasklet_trylock(t)) {
                        if (!atomic_read(&t->count)) {
                                if (!test_and_clear_bit(TASKLET_STATE_SCHED,

                t->next = NULL;
                *__this_cpu_read(tasklet_hi_vec.tail) = t;
                __this_cpu_write(tasklet_hi_vec.tail, &(t->next));

Core Linux ( 5 -> 1 -> 3 -> 2 -> 7 -> 4 -> 6 )

“Nature has neither kernel nor shell; she is everything at once” -- Johann Wolfgang von Goethe

Reader should be well versed with operating system concepts; a fair understanding of long running processes and its differences with processes with short bursts of execution; fault tolerance while meeting soft and hard real time constraints. While reading, it's important to understand and n/ack the design choices made by the linux kernel source in the core subsystems.

Threads [and] signals [are] a platform-dependent trail of misery, despair, horror and madness (~Anthony Baxte). That being said you should be a self-evaluating C expert, before diving into the kernel. You should also have good experience with Linked Lists, Stacks, Queues, Red Blacks Trees, Hash Functions, et al.

volatile int i;
int main(void)
    int c;
    for (i=0; i<3; i++) {
        c = i&&&i;
        printf("%d\n", c);    /* find c */
    return 0;

The beauty and art of the Linux Kernel source lies in the deliberate code obfuscation used along. This is often necessitated as to convey the computational meaning involving two or more operations in a clean and elegant way. This is especially true when writing code for multi-core architecture.

Video Lectures on Real-Time Systems, Task Scheduling, Memory Compression, Memory Barriers, SMP

#ifdef __compiler_offsetof
#define offsetof(TYPE,MEMBER) __compiler_offsetof(TYPE,MEMBER)
#define offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER)
  1. Linux Kernel Development - Robert Love
  2. Understanding the Linux Kernel - Daniel P. Bovet, Marco Cesati
  3. The Art of Linux KerneL Design - Yang Lixiang
  4. Professional Linux Kernel Architecture - Wolfgang Mauerer
  5. Design of the UNIX Operating System - Maurice J. Bach
  6. Understanding the Linux Virtual Memory Manager - Mel Gorman
  7. Linux Kernel Internals - Tigran Aivazian
  8. Embedded Linux Primer - Christopher Hallinan

Linux Device Drivers ( 1 -> 2 -> 4 -> 3 -> 8 -> ... )

"Music does not carry you along. You have to carry it along strictly by your ability to really just focus on that little small kernel of emotion or story". -- Debbie Harry

Your task is basically to establish a high speed communication interface between the hardware device and the software kernel. You should read the hardware reference datasheet/manual to understand the behavior of the device and it's control and data states and provided physical channels. Knowledge of Assembly for your particular architecture and a fair knowledge of VLSI Hardware Description Languages like VHDL or Verilog will help you in the long run.

Q: But, why do I have to read the hardware specs?

A: Because, "There is a chasm of carbon and silicon the software can't bridge" - Rahul Sonnad

However, the above doesn't poses a problem for Computational Algorithms (Driver code - bottom-half processing), as it can be fully simulated on a Universal Turing Machine. If the computed result holds true in the mathematical domain, it's a certainty that it is also true in the physical domain.

Video Lectures on Linux Device Drivers (Lec. 17 & 18), Anatomy of an Embedded KMS Driver, Pin Control and GPIO Update, Common Clock Framework, Write a Real Linux Driver - Greg KH

static irqreturn_t phy_interrupt(int irq, void *phy_dat)
         struct phy_device *phydev = phy_dat;

         if (PHY_HALTED == phydev->state)
                 return IRQ_NONE;                /* It can't be ours.  */

         /* The MDIO bus is not allowed to be written in interrupt
          * context, so we need to disable the irq here.  A work
          * queue will write the PHY to disable and clear the
          * interrupt, and then reenable the irq line.

         queue_work(system_power_efficient_wq, &phydev->phy_queue);

         return IRQ_HANDLED;
  1. Linux Device Drivers - Jonathan Corbet, Alessandro Rubini, and Greg Kroah-Hartman
  2. Essential Linux Device Drivers - Sreekrishnan Venkateswaran
  3. Writing Linux Device Drivers - Jerry Cooperstein
  4. The Linux Kernel Module Programming Guide - Peter Jay Salzman, Michael Burian, Ori Pomerantz
  5. Linux PCMCIA Programmer's Guide - David Hinds
  6. Linux SCSI Programming Howto - Heiko Eibfeldt
  7. Serial Programming Guide for POSIX Operating Systems - Michael R. Sweet
  8. Linux Graphics Drivers: an Introduction - Stéphane Marchesin
  9. Programming Guide for Linux USB Device Drivers - Detlef Fliegl
  10. The Linux Kernel Device Model - Patrick Mochel

Kernel Networking ( 1 -> 2 -> 3 -> ... )

“Call it a clan, call it a network, call it a tribe, call it a family: Whatever you call it, whoever you are, you need one.” - Jane Howard

Understanding a packet walk-through in the kernel is a key to understanding kernel networking. Understanding it is a must if we want to understand Netfilter or IPSec internals, and more. The two most important structures of linux kernel network layer are: struct sk_buff and struct net_device

static inline int sk_hashed(const struct sock *sk)
        return !sk_unhashed(sk);
  1. Understanding Linux Network Internals - Christian Benvenuti
  2. Linux Kernel Networking: Implementation and Theory - Rami Rosen
  3. UNIX Network Programming - W. Richard Stevens
  4. The Definitive Guide to Linux Network Programming - Keir Davis, John W. Turner, Nathan Yocom
  5. The Linux TCP/IP Stack: Networking for Embedded Systems - Thomas F. Herbert
  6. Linux Socket Programming by Example - Warren W. Gay
  7. Linux Advanced Routing & Traffic Control HOWTO - Bert Hubert

Kernel Debugging ( 1 -> 4 -> 9 -> ... )

Unless in communicating with it one says exactly what one means, trouble is bound to result. ~Alan Turing, about computers

Brian W. Kernighan, in the paper Unix for Beginners (1979) said, "The most effective debugging tool is still careful thought, coupled with judiciously placed print statements". Knowing what to collect will help you to get the right data quickly for a fast diagnosis. The great computer scientist Edsger Dijkstra once said that testing can demonstrate the presence of bugs but not their absence. Good investigation practices should balance the need to solve problems quickly, the need to build your skills, and the effective use of subject matter experts.

There are times when you hit rock-bottom, nothing seems to work and you run out of all your options. Its then that the real debugging begins. A bug may provide the break you need to disengage from a fixation on the ineffective solution.

Video Lectures on Kernel Debug and Profiling, Core Dump Analysis, Multicore Debugging with GDB, Controlling Multi-Core Race Conditions, Debugging Electronics

/* Buggy Code -- Stack frame problem
 * If you require information, do not free memory containing the information
char *initialize() {
  char string[80];
  char* ptr = string;
  return ptr;

int main() {
  char *myval = initialize();
/*  “When debugging, novices insert corrective code; experts remove defective code.”
 *     – Richard Pattis
 printk("The above can be considered as Development and Review in Industrial Practises");
  1. Linux Debugging and Performance Tuning - Steve Best
  2. Linux Applications Debugging Techniques - Aurelian Melinte
  3. Debugging with GDB: The GNU Source-Level Debugger - Roland H. Pesch
  4. Debugging Embedded Linux - Christopher Hallinan
  5. The Art of Debugging with GDB, DDD, and Eclipse - Norman S. Matloff
  6. Why Programs Fail: A Guide to Systematic Debugging - Andreas Zeller
  7. Software Exorcism: A Handbook for Debugging and Optimizing Legacy Code - Bill Blunden
  8. Debugging: Finding most Elusive Software and Hardware Problems - David J. Agans
  9. Debugging by Thinking: A Multidisciplinary Approach - Robert Charles Metzger
  10. Find the Bug: A Book of Incorrect Programs - Adam Barr

File Systems ( 1 -> 2 -> 6 -> ... )

"I wanted to have virtual memory, at least as it's coupled with file systems". -- Ken Thompson

On a UNIX system, everything is a file; if something is not a file, it is a process, except for named pipes and sockets. In a file system, a file is represented by an inode, a kind of serial number containing information about the actual data that makes up the file. The Linux Virtual File System VFS caches information in memory from each file system as it is mounted and used. A lot of care must be taken to update the file system correctly as data within these caches is modified as files and directories are created, written to and deleted. The most important of these caches is the Buffer Cache, which is integrated into the way that the individual file systems access their underlying block storage devices.

Video Lectures on Storage Systems, Flash Friendly File System

long do_sys_open(int dfd, const char __user *filename, int flags, umode_t mode)
        struct open_flags op;
        int fd = build_open_flags(flags, mode, &op);
        struct filename *tmp;

        if (fd)
                return fd;

        tmp = getname(filename);
        if (IS_ERR(tmp))
                return PTR_ERR(tmp);

        fd = get_unused_fd_flags(flags);
        if (fd >= 0) {
                struct file *f = do_filp_open(dfd, tmp, &op);
                if (IS_ERR(f)) {
                        fd = PTR_ERR(f);
                } else {
                        fd_install(fd, f);
        return fd;

SYSCALL_DEFINE3(open, const char __user *, filename, int, flags, umode_t, mode)
        if (force_o_largefile())
                flags |= O_LARGEFILE;

        return do_sys_open(AT_FDCWD, filename, flags, mode);
  1. Linux File Systems - Moshe Bar
  2. Linux Filesystems - William Von Hagen
  3. UNIX Filesystems: Evolution, Design, and Implementation - Steve D. Pate
  4. Practical File System Design - Dominic Giampaolo
  5. File System Forensic Analysis - Brian Carrier
  6. Linux Filesystem Hierarchy - Binh Nguyen
  7. BTRFS: The Linux B-tree Filesystem - Ohad Rodeh
  8. StegFS: A Steganographic File System for Linux - Andrew D. McDonald, Markus G. Kuhn

Security ( 1 -> 2 -> 8 -> 4 -> 3 -> ... )

"UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things". — Doug Gwyn

No technique works if it isn't used. Ethics change with technology.

"F × S = k" the product of freedom and security is a constant. - Niven's Laws

Cryptography forms the basis of trust online. Hacking is exploiting security controls either in a technical, physical or a human-based element. Protecting the kernel from other running programs is a first step toward a secure and stable system, but this is obviously not enough: some degree of protection must exist between different user-land applications as well. Exploits can target local or remote services.

“You can't hack your destiny, brute force...you need a back door, a side channel into Life." ― Clyde Dsouza

Computers do not solve problems, they execute solutions. Behind every non-deterministic algorithmic code, there is a determined mind. -- /var/log/dmesg

Video Lectures on Cryptography and Network Security, Namespaces for Security, Protection Against Remote Attacks, Secure Embedded Linux

env x='() { :;}; echo vulnerable' bash -c "echo this is a test for Shellsock"
  1. Hacking: The Art of Exploitation - Jon Erickson
  2. The Rootkit Arsenal: Escape and Evasion in the Dark Corners of the System - Bill Blunden
  3. Hacking Exposed: Network Security Secrets - Stuart McClure, Joel Scambray, George Kurtz
  4. A Guide to Kernel Exploitation: Attacking the Core - Enrico Perla, Massimiliano Oldani
  5. The Art of Memory Forensics - Michael Hale Ligh, Andrew Case, Jamie Levy, AAron Walters
  6. Practical Reverse Engineering - Bruce Dang, Alexandre Gazet, Elias Bachaalany
  7. Practical Malware Analysis - Michael Sikorski, Andrew Honig
  8. Maximum Linux Security: A Hacker's Guide to Protecting Your Linux Server - Anonymous
  9. Linux Security - Craig Hunt
  10. Real World Linux Security - Bob Toxen

Kernel Source ( 0.11 -> 2.4 -> 2.6 -> 3.18 )

"Like wine, the mastery of kernel programming matures with time. But, unlike wine, it gets sweeter in the process". --Lawrence Mucheka

You might not think that programmers are artists, but programming is an extremely creative profession. It's logic-based creativity. Computer science education cannot make anybody an expert programmer any more than studying brushes and pigment can make somebody an expert painter. As you already know, there is a difference between knowing the path and walking the path; it is of utmost importance to roll up your sleeves and get your hands dirty with kernel source code. Finally, with your thus gained kernel knowledge, wherever you go, you will shine.

Immature coders imitate; mature coders steal; bad coders deface what they take, and good coders make it into something better, or at least something different. The good coder welds his theft into a whole of feeling which is unique, utterly different from that from which it was torn.

Video Lectures on Kernel Recipes

├── boot
│   ├── bootsect.s      head.s      setup.s
├── fs
│   ├── bitmap.c    block_dev.c buffer.c        char_dev.c  exec.c
│   ├── fcntl.c     file_dev.c  file_table.c    inode.c     ioctl.c
│   ├── namei.c     open.c      pipe.c          read_write.c
│   ├── stat.c      super.c     truncate.c
├── include
│   ├── a.out.h     const.h     ctype.h     errno.h     fcntl.h
│   ├── signal.h    stdarg.h    stddef.h    string.h    termios.h
│   ├── time.h      unistd.h    utime.h
│   ├── asm
│   │   ├── io.h    memory.h    segment.h   system.h
│   ├── linux
│   │   ├── config.h    fdreg.h fs.h    hdreg.h     head.h
│   │   ├── kernel.h    mm.h    sched.h sys.h       tty.h
│   ├── sys
│   │   ├── stat.h      times.h types.h utsname.h   wait.h
├── init
│   └── main.c
├── kernel
│   ├── asm.s       exit.c      fork.c      mktime.c    panic.c
│   ├── printk.c    sched.c     signal.c    sys.c       system_calls.s
│   ├── traps.c     vsprintf.c
│   ├── blk_drv
│   │   ├── blk.h   floppy.c    hd.c    ll_rw_blk.c     ramdisk.c
│   ├── chr_drv
│   │   ├── console.c   keyboard.S  rs_io.s
│   │   ├── serial.c    tty_io.c    tty_ioctl.c
│   ├── math
│   │   ├── math_emulate.c
├── lib
│   ├── close.c  ctype.c  dup.c     errno.c  execve.c  _exit.c
│   ├── malloc.c open.c   setsid.c  string.c wait.c    write.c
├── Makefile
├── mm
│   ├── memory.c page.s
└── tools
    └── build.c
  1. Beginner's start with Linux 0.11 source (less than 20,000 lines of source code). After 20 years of development, compared with Linux 0.11, Linux has become very huge, complex, and difficult to learn. But the design concept and main structure have no fundamental changes. Learning Linux 0.11 still has important practical significance.
  2. Mandatory Reading for Kernel Hackers => Linux_source_dir/Documentation/*
  3. You should be subscribed and active on at-least one kernel mailing list. Start with kernel newbies.
  4. You do not need to read the full source code. Once you are familiar with the kernel API's and its usage, directly start with the source code of the sub-system you are interested in. You can also start with writing your own plug-n-play modules to experiment with the kernel.
  5. Device Driver writers would benefit by having their own dedicated hardware. Start with Raspberry Pi.

I want to learn the basics of embedded linux. To do this I am assuming that I need to go and buy some sort of hardware board and have the linux kernel code.

I have no idea where to start with this and any tips/pointers would be most welcome. Ideally I would like people to point out a full system (e.g. this "board kit with linux" with these "manuals" are very good).

Also cost is a factor as I am doing this personally not as a business : )

Thanks very much, Code

You will need:

1 - Boards: I started with a beagleboard. A new beaglebone black is available now. There's a large support community for the beagles; many howto pages here and here, and ready to install images. You can also build the image yourself (step 3). These boards have most of the peripherals that you may need to play with, and can also be used as extra computer !

2 - Books: As Mali noted, Linux is a fast moving object, but in the early phases of learning you will need a solid reference. I'd suggest "Embedded Linux Primer: A Practical Real-World Approach" as it has many examples and takes you step-by-step. There's also "Building Embedded Linux Systems".

3 - The firmware: a) toolchain, b) root filesystem and c) kernel image. "Buildroot" is the easiest to start with. Openembedded and Yocto have a very steep learning curve. "Embedded Linux Primer: A Practical Real-World Approach" has some examples on how to use buildroot.

I just started on embedded linux. I just got a job where I work in firmware for a series of products.
I am reading this book "Embedded Linux Primer: A Practical Real-World Approach".
Whatever is implemented in the products is present in this book.
I strongly recommend this book. It is awesome.
For me, the first thing you should do before you dive in is read this book. The book is a goldmine.

I have a Tegra Ventana development kit, on which I want to run Linux. (NVIDIA only makes Android 2.3 and 2.2 images available for the Ventana: see "Ventana Specific Downloads" at the bottom of http://developer.nvidia.com/tegra-ventana-development-kit.)

I found an announcement of the release of Linux For Tegra (L4T), which predates the release of the Ventana. I also found notice that L4T has been removed from NVIDIA's downloads page. So I guess if I want to run Linux on the Ventana (before NVIDIA eventually re-releases it) I'm going to have to build it myself. (Though that might be made easier if I can follow the breadcrumbs left by the "many of the community have already taken various linux distributions and got them up and going..." mentioned in the L4T announcement.)

How do I go about learning how to build Linux for this board?

I haven't been able to find any blog posts or mailing list entries from those people who have brought up various Linux distributions.

I did find http://tjworld.net/wiki/Android/Tegra/Linux/SourceCodeRepositoriesAndPatches#Linux, which gives me the Git URL to the Tegra tree (and the name of the maintainer). Lower down on that same page is a pointer to the linux-tegra mailing list. But I didn't find anything like a link to "getting started" instructions in the mailing list.

I'm reading Building Embedded Linux Systems, Second Edition (and have skimmed through Embedded Linux Primer, Second Edition), and perhaps I'll be able to figure it out for myself. (Though I suspect I'm going to get stuck because of the lack of technical documentation on the Ventana.) But I'd appreciate any advice to save me time.

I'm porting/customizing linux kernel for our board. I will base on atmel evolution board configuration, and I need to overwrite some startup routines and add our drivers.

Is there any document, link, forum where I can get information how to make it in Linux way ? Which files can I overwrite, and which shall I create from scratch ? Is this a Board Support Package question ?

Thank you

I doubt that there is short and simple answer to your question. To accomplish this task you should more or less good understand Linux as distribution (kernel + boot scripts + user space software) work together and how make them be a friends.

I could recommend you book, which I found extremely useful as embedded Linux engineer: Embedded Linux Primer: A Practical Real-World Approach (2nd Edition) I am quite confident it will answer most of your questions.

I want to begin learning embedded linux development (i'm not beginner in C nor in Linux) and i choose this book : http://www.amazon.com/Embedded-Linux-Primer-Practical-Real-World/dp/0137017839

If you have a better choice let me know please.

I want to buy some hardware to do some practice, any suggestions?

Thanks for your help.

Linux programming is linux programming, even kernel level, so the question is what Luke asked. What is it that you really want to do? The computer you typed this question on may suffice for much of what you are interested in or none of it. Depends.

If you go beagleboard avoid the old one go for the xM, it is usable where the other just costs more money to make it usable. The raspberry pi should be out any time now but it is an unknown quanity. I didnt like the plug computer but did like the open-rd board, liked it much better than my beagleboard. I have one of the chinese clones of the beagleboard which I liked much better (because it was usable out of the box) the xM has bridged that gap though. embeddedarm.com has a number of boards. The hawkboard is fine as well, they have had that picture up about pcb design flaw forever but my boards so far are fine.

Oh the open-rd board has sata built in you can plug a laptop hard drive right into the board, all of the others use slow usb or flash based solutions (the open-rd might be a usb to sata though). there is a tegra2 based one out there with various flavors that did that usb to sata, pretty lame. The big problem with these arm based one is they use slow mass storage and you cant really take advantage of the instruction set or other things like that, they are also crippled with the amount of ram.

There is always qemu, its free and you can try different processors. I would make sure you put ARM on the list of things you want to try/learn but might be worth trying others as well, mips, ppc, etc.

@Greg - not a duplicate. Clearly this post is looking for advice on embedded linux, not general embedded.

@funnyCoder - What sorts of things are you wanting to do? Beagleboard is nice but might not fit your needs. Are you looking for:

  • Battery powered
  • Video display
  • USB host capability
  • Running a full desktop environment
  • Removable storage
  • Expansion ability
  • Ethernet
  • Wireless (Bluetooth or 802.11 or Zigbee)
  • Buttons, switches, LEDs
  • Touch screen interface
  • Audio

Also, processor speed and RAM have a big influence on what you will be able to do. There are low-end systems and very high-end systems and lots in between. Give us some requirements and we can direct you a little better. Or maybe someone has a link to a comparison guide.

A good book I'd recommend is the O'Riley book Building Embedded Linux Systems, but the one you've got is pretty good too.

As I understand, the address of code instructions are virtual addresses, but in order to access the various devices (e.g. RAM, Parallel NOR Flash) these virtual addresses need to be translated into physical addresses, this task is done by the MMU. The question is how this translation process behaves on system reset (on power up, I think that there is no entry in the MMU yet), so that the first instruction can be fetched from the Parallel NOR Flash and started executing. May anyone please explain this process (for any CPU architecture ARM, PowerPC, ..., I just guess this behavior is generic among architectures). Any recommendations are appreciated. Thanks in advanced!

At power-up, in effect the MMU will be disabled. That much is generic.

To access NOR flash, there would be a default mapping for (at least) some of the address space. First instruction would be typically fetched from 0xFFFF0000 (ARM) or 0xFFFFFFFC (Power PC) and vicinity. But there are pinstrap options that can affect this. Booting a processor is not really generic.

There are plenty of other options (NAND flash, SPI ROM, MMC) for storing boot code. For general concepts, Hallinan includes a chapter on booting. For details you'd have to look at the technical manual of a specific CPU, e.g. OMAP4 TRM is an example for ARM, then find sections describing boot process.

I am facing a task to introduce some custom yet to be written written 3D games into our embedded Linux board. Our system is a custom Linux distribution. Main application is running with Qt and the plan is for this application to run games as separate processes that will overtake the screen while active. The board is capable of OpenGL ES2 and is on par with modern phones.

What are my options for a good, performant 3D graphics engine on such a platform?

Preferably I would love to have Unity3D, but it only supports Android. (Maybe there is a possibility to skip Android by providing only basic dependencies instead?)

Since you've decided on Qt for your UI, you definitely want a graphics library that's compatible with Qt.

So it sounds like OpenGL ES is exactly what you're looking for:


Qt for Embedded Linux provides support for integrating OpenGL ES for drawing into a QGLWidget. The current implementation supports OpenGL and 2D painting within a QGLWidget.

Q: Exactly what's holding you back (you didn't specify the exact board or any details about your toolchain/library vendors)?

PS: You might also wish to look here:


The reference integration for OpenGL into Qt for Embedded Linux is for the PowerVR chipset from Imagination Technologies. It consists of two components: pvreglscreen, which provides the Qt for Embedded Linux screen driver, and QWSWSEGL, which implements a plug-in to the PowerVR EGL implementation to implement low-level OpenGL drawing surfaces.

PPS: This is a great, great book on Linux Embedded: satisfaction guaranteed:

Embedded Linux Primer, Christopher Hallinan:


I have an industrial computer (1Ghz processor, 1GB RAM) with linux embedded and I'm trying to figure out what's the best programming technology for the system we're going to develop.

System will have to read some data sent to the serial port, store it on a queue and send it back to the server, so we might need a relational embedded database...

I've read about C when you have very limited resources, but maybe this is not the case...

so far I have 2 prefered options: C or C# with Mono project.

it seems best embedded database is SQLLite.

What do you think?, any better alternative?

SqlLite3: Yes, definitely a good candidate

C or C++ (remember: they're different - VERY different): both strong candidates

Mono/C#: Not so much :)

Java: If there's a JVM readily available for your host, and assuming your CPU is 32 bit (or greater), then Java JME is also an option.

I'd vote either C or C++, depending on your preferences.

If you went with C++ and needed a GUI, I'd consider Qt.

I strongly recommend this book:

I have an inherited project/board based on the AT91SAM9261EK board that uses U-Boot and a BusyBox file system. I'm a newbie and trying to understand the relationship of these components to my application.

It appears thru experimentation that the setting of stdout as well as the serial port parameters are done in U-Boot and that this persists through to the application. Is this correct?

My base problems are: 1: The port setting is incorrect. The baud rate needs to be changed. 2. I would like to turn this port off (or at least make it transmit only) from my application.

How can I change the port parameters in U-Boot?
What component defines stdout: U-Boot, BusyBox, or my application?


Yes, U-Boot environment variables control these, both while U-Boot is running and after linux boots. There are plenty of basic references available. I recommend Embedded Linux Primer by Hallinan; your current questions would come under sec 5.3 and chap 7.

At U-boot prompt, do "printenv", you will find U-Boot has set these variables for itself: stderr=serial stdin=serial stdout=serial

As long as you do not do "saveenv", you can change stdin and stdout of U-Boot. Probably you will find those changes quite nonuseful. Reboot to get the previous settings back.

You can change baudrate very easily setenv baudrate 9600

Initial Linux console is set by an item within "bootargs" variable, e.g. ...console=ttyAMA0,115200n8... If you want different baudrate, try something like this at U-Boot coli: setenv bootargs console=ttyAMA0,9600n8 ... (copy what was previously there for other items) saveenv

After linux has come up, various other console options are possible but are somewhat advanced, good luck.

We have to enumerate usb devices on board. Can we build busybox with mdev instead of udev? Can we also use udevlib functions in case we have mdev on board.

Yes. Nice explanation in Hallinan, if you google "19.8.1 busybox mdev" you may get everything you need for this topic (but, also buy the book, it's really great). Yes, remove udev but keep hotplug and sysfs, refer also maybe to gentoo/mdev.