The worked examples in this book are intended to be generic, but to make them relevant and easy to follow, I have had to choose a specific device as an example. I have used two exemplar devices: the BeagleBone Black and QEMU. The first is a widely-available and cheap development board which can be used in serious embedded hardware. The second is a machine emulator that can be used to create a range of systems that are typical of embedded hardware. It was tempting to use QEMU exclusively, but, like all emulations, it is not quite the same as the real thing. Using a BeagleBone, you have the satisfaction of interacting with real hardware and seeing real LEDs flash. It was also tempting to select a more up-to-date board than the BeagleBone Black, which is several years old now, but I believe that its popularity gives it a degree of longevity and means that it will continue to be available for some years yet.
In any case, I encourage you to try out as many of the examples as you can using either of these two platforms, or indeed any embedded hardware you may have to hand.
The BeagleBone and the later BeagleBone Black are open hardware designs for a small, credit card sized development board produced by Circuitco LLC. The main repository of information is at www.beagleboard.org. The main points of the specification are:
In addition, there are two 46-pin expansion headers for which there are a great variety of daughter boards, known as capes, which allow you to adapt the board to do many different things. However, you do not need to fit any capes in the examples in this book.
In addition to the board itself, you will need:
QEMU is a machine emulator. It comes in a number of different flavors, each of which can emulate a processor architecture and a number of boards built using that architecture. For example, we have the following:
For each architecture, QEMU emulates a range of hardware, which you can see by using the option -machine help. Each machine emulates most of the hardware that would normally be found on that board. There are options to link hardware to local resources, such as using a local file for the emulated disk drive. Here is a concrete example:
$ qemu-system-arm -machine vexpress-a9 -m 256M -drive file=rootfs.ext4,sd -net nic -net use -kernel zImage -dtb vexpress-v2p-ca9.dtb -append "console=ttyAMA0,115200 root=/dev/mmcblk0" -serial stdio -net nic,model=lan9118 -net tap,ifname=tap0
The options used in the preceding command line are:
-machine vexpress-a9: creates an emulation of an ARM Versatile Express development board with a Cortex A-9 processor-m 256M: populates it with 256 MiB of RAM-drive file=rootfs.ext4,sd: connect the sd interface to the local file rootfs.ext4 (which contains a filesystem image)-kernel zImage: loads the Linux kernel from the local file named zImage-dtb vexpress-v2p-ca9.dtb: loads the device tree from the local file vexpress-v2p-ca9.dtb-append "...": supplies this string as the kernel command line-serial stdio: connects the serial port to the terminal that launched QEMU, usually so that you can log on to the emulated machine via the serial console-net nic,model=lan9118: creates a network interface-net tap,ifname=tap0: connects the network interface to the virtual network interface tap0To configure the host side of the network, you need the tunctl command from the User Mode Linux (UML) project; on Debian and Ubuntu the package is named uml-utilities. You use it to create a virtual network using the following command:
$ sudo tunctl -u $(whoami) -t tap0
This creates a network interface named tap0 which is connected to the network controller in the emulated QEMU machine. You configure tap0 in exactly the same way as any other interface.
All of these options are described in detail in the following chapters. I will be using Versatile Express for most of my examples, but it should be easy to use a different machine or architecture.