Getting started with Embedded Linux: Part Two

October 01, 2013

mike_eager-October 01, 2013

In the first part of this series, I outlined an approach to getting started with Embedded Linux for people with experience using non-Linux embedded systems. This starts with learning Linux in a desktop environment, running on a VMware or VirtualBox environment. One advantage that Linux has over other embedded OSes is that the same kernel is used on all systems, from smallest to largest, and many of the same utilities and libraries are available for both embedded and desktop environments.

Teaching Linux is far beyond the scope of a short article, but we can outline a road map to becoming acquainted with Linux on the desktop and talk about how this relates to Linux in an embedded environment. There are many good books which will introduce you to Linux. The important basic principles to familiarize yourself with are the command line, file system, directory structure, and process organization.

Most Linux system configuration and management is performed from the command line. On a desktop system, this means opening a terminal window and using the Bash shell. Commands start with the command name and usually accept options (generally preceded by a hyphen) followed by file names. Many command names are terse (like ls or cp), and can take a number of options, most of which you will rarely use. If you are familiar with the Windows CMD shell (or the MSDOS shell from which it evolved), a number of the commands are similar (like cd) but there frequently are subtle differences. At a minimum, you will need to know how to list files (cat, less, file), list and move between directories (ls, cd, pwd), and how to get help (man, info, apropos). My desktop Linux system has thousands of commands. You don't need to know more than a small number, but if there is something you want to do, it's likely there is a command to do it. The apropos command is a good way to find commands which might do what you want to do. Try running "man apropos" in from the command line. You will also need to become familiar with an editor, such as vi, which can be used in a command shell.

On an Embedded Linux system, most likely you will not have a windowing system. Instead you will be interacting with BusyBox and the Ash shell, a small command line interpreter. BusyBox packages about 200 commands into a single executable program.

One of the design philosophies of Unix and Linux is its organization around a hierarchical file system. The root of this file system is named "/" and everything in the file system can be found starting here. Naturally, the file system holds regular files containing text or data, as well as programs. Additionally, it contains a variety of special "files" which may represent physical devices (like hard drives), interfaces created by drivers (such as virtual terminals), network connections, and more. Where other OSes may provide a programmatic interface to internal information about processes or memory, Linux provides a much simple interface to by representing this information as text files. The /proc directory, for example, contains a sub-directory for each currently running process which describes almost everything you might want to know about the process.

The common directories are /boot, containing the boot program; /bin and /sbin, containing programs usually run by the system administrator, root; /dev, containing devices (both real and virtual); /etc, containing system configuration files; /home, containing user files; /proc and /sys, with system information; /lib, containing libraries; /usr, containing not user files, but programs which may be run by users; /tmp, containing temporary files, and finally, /var, containing system logs. An Embedded Linux system will have the same organization, although occasionally some directories may be combined. It will have far fewer files than a desktop system.

Linux (and Unix) has a hierarchical process structure. The first process, init, has process ID (PID) one and is created by the Linux kernel when the system starts. Init, in turn, creates child processes which allow you to log into the system. These in turn start windowing systems or command shells, which in turn will spawn other processes. If you type "ps" into a command window, you will see a brief listing of the top level processes running in that window, usually just the ps command itself and the bash command line interpreter. Typing "ps -l", will give you more information, including process ID of each process's parent (PPID), the user ID (UID) of the person running the program, and more information. The "ps l" command will also print background processes. (A very few older commands inherited from Unix, like ps and tar, optionally omit the hyphen that precedes options. Unfortunately, for historical reasons, ps gives different output depending on whether you specify an option with or without the hyphen.) The "ps alx" command will give you a long list of every process running on your system, way more than you really want to know. (You might want to pipe this through less to page through the listing: "ps alx | less".) You can also look through the /proc directory to see a different view of the processes on your system.

An Embedded Linux system has exactly the same process organization as your desktop system. The differences will be that there are far fewer processes running on an embedded system than on a desktop system.

Wander around your Linux system running on the VM. Try listing files and running commands. Don't be afraid that you might break something; Linux is very robust. But you might take a snapshot of the system so that you can get back to a known stable system just in case.

Our next installment will talk about program development for Linux and Embedded Linux.

Michael Eager is principal consultant at Eager Consulting in Palo Alto, Calif. He has over four decades experience developing compilers, debuggers, and simulators for a wide range of processor architectures used in embedded systems. His current and former clients include major semiconductor companies and systems developers. Michael has been a member of the ISO C++ Standard Committee and ABI Committees for several processor architectures. He is chair of the Debugging Standards Committee for DWARF, a widely used debug data format. He is active in the open-source and Linux communities.

Related links:

Loading comments...