Simple Embedded Linux System
Simple Embedded Linux Systemby Vincent Sanders and Daniel Silverstone
Introduction
Constructingan embedded system with Linux is often seen as a complex undertaking.This article is the first in a series which will show the fundamentalaspects of constructing such systems and enable the reader to applythis knowledge to their specific situation.
This first articlecovers the construction of the most basic system possible, which willprovide a command shell on the console. Along with the rest of theseries, it assumes a basic understanding of a Linux-based operatingsystem. While discussing concepts and general approaches, theseconcepts are demonstrated with extensive practical examples. All thepractical examples are based upon a Debian- or Ubuntu-baseddistribution.
What is an embedded system?
The term"Embedded System" has been applied to such a large number of systemsthat its meaning has become somewhat ill-defined. The term has beenapplied to everything from 4-bit microcontroller systems to hugeindustrial control systems.
The context in which we are usingthe term here is to refer to systems where the user is limited to aspecific range of interaction with a limited number of applications(typically one). Thus, from the whole spectrum of applications which ageneral purpose computer can run, a very narrow selection is made bythe creator of the embedded system software.
It should berealized that the limits of interaction with a system may involvehardware as well as software. For example, if a system is limited to akeypad with only the digits 0 to 9, user interaction will be moreconstrained than if the user had access to a full 102-key keyboard.
Inaddition to the limiting of user interaction, there may also be limitson the system resources available. Such limits are typically imposed bya system's cost, size, or environment. However, wherever possible,these limits should be arrived at with as much knowledge of the systemrequirements as possible. Many projects fail unnecessarily because anarbitrary limit has been set which makes a workable solutionunachievable. An example of this would be the selection of a system'smain memory size before the application's memory requirements have beendetermined.
What do you want to achieve?
A project must have a clearly defined goal.
Thismay be viewed as a statement of the obvious, but it bears repeating asfor some unfortunately inexplicable reason, embedded systems seem tosuffer from poorly-defined goals.
An "embedded" project, likeany other, should have a clear statement of what must be achieved to bedeclared a success. The project brief must contain all therequirements, as well as a list of "desirable properties." It isessential that the two should not be confused; e.g., if the productmust fit inside a 100mm by 80mm enclosure, that is a requirement.However, a statement that the lowest cost should be achieved is adesirable item, whereas a fixed upper cost would be a requirement.
Ifinformation necessary to formulate a requirement is not known, then itshould be kept as a "desirable item" couched in terms of that unknowninformation. It may be possible that once that information isdetermined, a requirement can be added.
It is, again,self-evident that any project plan must be flexible enough to cope withchanges to requirements, but it must be appreciated that such changesmay have a huge impact on the whole project and, indeed, may invalidatecentral decisions which have already been made.
General IT project management is outside the scope of this article. Fortunately there exist many good references on this topic.
Requirements which might be added to a project brief based on the assumptions of this article are:
[*]The system software will be based upon a Linux kernel.
[*]The system software will use standard Unix-like tools and layout.
Theimplications of these statements mean the chosen hardware should have aLinux kernel port available, and must have sufficient resources to runthe chosen programs.
Another important consideration is whatkind of OS the project warrants. For example, if you have a projectrequirement of in-field updates, then you may want to use a full OSwith package management, such as Debian GNU/Linux or Fedora. Such arequirement would, however, imply a need for a non-flash-based storagemedium such as a hard disc for storing the OS, as these kinds ofsystems are typically very large (even in minimal installations), andnot designed with the constraints of flash-based storage in mind.However, given that additional wrinkle, using an extant operatingsystem can reduce software development costs significantly.
Anatomy of a Linux-based system
Muchhas been written on how Linux-based systems are put together; however abrief review is in order, to ensure that basic concepts are understood.
Tobe strictly correct the term "Linux" refers only to the kernel. Variousarguments have been made as to whether the kernel constitutes anoperating system (OS) in its entirety, or whether the term should referto the whole assemblage of software that makes up the system. We usethe latter interpretation here.
The general steps when any modern computer is turned on or reset is:
[*]The CPU (or designated boot CPU on multi-core/processor systems) initializes its internal hardware state, loads microcode etc.
[*]The CPU commences execution of the initial boot code, e.g., the BIOS on x86 or the boot-loader on ARM.
[*]The boot code loads and executes the kernel. However, it is worthnoting that x86 systems generally use the BIOS to load an intermediateloader such as GRUB or syslinux, which then fetches and starts thekernel.
[*]The kernel configures the hardware and executes the init process.
[*]The init process executes other processes to get all the required software running.
Thekernel's role in the system is to provide a generic interface toprograms, and arbitrate access to resources. Each program running onthe system is called a process. Each operates as if it were the onlyprocess running. The kernel completely insulates a program from theimplementation details of physical memory layout, peripheral access,networking, etc.
The first process executed is special in thatit is not expected to exit, and is expected to perform some basichousekeeping tasks to keep a system running. Except in very specificcircumstances, this process is provided by a program named /sbin/init.The init process typically starts a shell script at boot to executeadditional programs.
Some projects have chosen to run theirprimary application as the init process. While this is possible, it isnot recommended, as such a program is exceptionally difficult to debugand control. A programming bug in the application halts the system, andthere is no way to debug the issue.
One feature of almost allUnix-like systems is the shell, an interactive command parser. Mostcommon shells have the Bourne shell syntax.
A simple beginning
Weshall now consider creating a minimal system. The approach taken hererequires no additional hardware beyond the host PC, and the absoluteminimum of additional software.
As already mentioned, theseexamples assume a Debian or Ubuntu host system. To use the QEMUemulator for testing, the host system must be supported by QEMU as atarget. An example where this might not be the case is where the targetsystem is x86-64, which QEMU does not support.
To ease construction of the examples, we will use the kernel's initramfssupport. An initramfs is a gzip-compressed cpio archive of a filesystem. It is unpacked into a RAM disk at kernel initialization. Aslight difference to normal system start-up is that while the firstprocess executed must still be called init, it must be in the root ofthe file system. We will use the /init script to create some symboliclinks and device nodes before executing the more-typical /sbin/initprogram.
This example system will use a program called Busybox,which provides a large number of utilities in a single executable,including a shell and an init process. Busybox is used extensively tobuild embedded systems of many types.
The busybox-static package is required to obtain pre-built copy of the Busybox binary and the qemu package is required to test the constructed images. These may be obtained by executing:
$ sudo apt-get install busybox-static qemu
Asmentioned, our initramfs-based approach requires a small /init script.This configures some basic device nodes and directories, mounts thespecial /sys and /proc file systems, and starts the processing ofhotplug events using mdev.
#!/bin/sh# Create all the busybox symbolic links/bin/busybox --install -s# Create base directories[ -d /dev ] || mkdir -m 0755 /dev[ -d /root ] || mkdir --mode=0700 /root[ -d /sys ] || mkdir /sys[ -d /proc ] || mkdir /proc[ -d /tmp ] || mkdir /tmpmkdir -p /var/lock# Mount essential filesystemsmount -t sysfs none /sys -onodev,noexec,nosuidmount -t proc none /proc -onodev,noexec,nosuid# Create essential filesystem nodesmknod /dev/zero c 1 5mknod /dev/null c 1 3mknod /dev/tty c 5 0mknod /dev/console c 5 1mknod /dev/ptmx c 5 2mknod /dev/tty0 c 4 0mknod /dev/tty1 c 4 1echo "/sbin/mdev" > /proc/sys/kernel/hotplugecho "Creating devices"/sbin/mdev -sexec /sbin/init
Toconstruct the cpio archive, the following commands should be executedin a shell. Note, however, that INITSCRIPT should be replaced with thelocation of the above script.
$ mkdir simple$ cd simple$ mkdir -p bin sbin usr/bin usr/sbin$ cp /bin/busybox bin/busybox$ ln -s busybox bin/sh$ cp INITSCRIPT init$ chmod a+x init$ find . | cpio --quiet -o -H newc | gzip >../simple.gz$ cd ..
To test the constructed image use a command like:
$ qemu -kernel /boot/vmlinuz-2.6.26-1-686 -initrd simple.gz \ -append "root=/dev/ram" /dev/zero
Thisshould present a QEMU window where the OS you just constructed bootsand displays the message "Please press Enter to activate this console."Press enter and you should be presented with an interactive shell fromwhich you can experiment with the commands Busybox provides. Thisenvironment is executing entirely from a RAM disc and is completelyvolatile. As such, any changes you make will not persist when theemulator is stopped.
Booting a real system
Startingthe image under emulation proves the image ought to work on a realsystem, but there is no substitute for testing on real hardware. The syslinux package allows us to construct bootable systems for standard PCs on DOS-formatted storage.
Asuitable medium should be chosen to boot from, e.g., a DOS-formattedfloppy disk or a DOS-formatted USB stick. The DOS partition of the USBstick must be marked bootable. Some USB sticks might needrepartitioning and reformatting with the Linux tools in order to workcorrectly.
The syslinux program should be run on the device /dev/fd0 for a floppy disk, or something similar to /dev/sdx1 for a USB stick. Care must be taken, as selecting the wrong device name might overwrite your host system's hard drive.
The target device should then be mounted and the kernel and the simple.gz file copied on.
The syslinux loader can be configured using a file called syslinux.cfg which would look something like:
default simpletimeout 100prompt 1label simplekernel vmlinuzappend initrd=simple root=/dev/ram
The complete command sequence to perform these actions, substituting file locations as appropriate, is:
$ sudo syslinux -s /dev/sdd1$ sudo mount -t vfat -o shortname=mixed/dev/sdd1 /mnt/$ cd /mnt$ sudo cp /boot/vmlinuz-2.6.26-1-686 VMLINUZ$ sudo cp simple.gz SIMPLE$ sudo cp syslinux.cfg SYSLINUX.CFG$ cd /mnt$ sudo umount /mnt
Thedevice may now be removed and booted on an appropriate PC. The PCshould boot the image and present a prompt exactly the same way theemulator did.
What's next?
This first step, whilesimple, provides a complete OS, and demonstrates that constructing anembedded system can be a straightforward process.
The next step is to expand this simple example to encompass a specific application, which will be covered in the next article.
This article is copyrighted 2009, Simtec Electronics, and reproduced here with permission.
About the authors
http://www.linuxfordevices.com/files/misc/vincent_sanders-thm.jpgVincent Sanders is the senior software engineer at Simtec Electronics.He has extensive experience in the computer industry, having worked onprojects from large fault-tolerant systems through accounting softwareto programmable logic systems. He is an active developer for numerousopen source projects, including the Linux kernel, and is also a Debiandeveloper.
http://www.linuxfordevices.com/files/misc/daniel_silverstone-thm.jpgDaniel Silverstone is a software engineer at Simtec Electronics,and has experience in architecting robust systems. He develops softwarefor a large number of open source projects, contributes to the Linuxkernel, and is both an Ubuntu and Debian developer.
页:
[1]