Download Building Embedded Linux Systems

RedBoot
RedBoot is a bootloader based upon the Embedded Configurable Operating System
(eCos), originally written by Cygnus Solutions and later acquired by Red Hat. eCos
itself remains quite popular on some embedded devices that are too small to run a full
Linux kernel, but RedBoot has been extended to boot other operating systems, such
as Linux. RedBoot is extremely flexible and still preferred by some developers, although
we strongly recommend that you investigate U-Boot for your new embedded designs.
You can find out more about RedBoot by visiting http://sourceware.org/redboot.
Server Setup for Network Boot
As we saw in Chapter 2, setting up a target for network boot is ideal during the early
stages of development, because you can gradually modify the kernel and the root filesystem without having to update the target’s storage devices every time you make a
modification. Although not all bootloaders can use this setup to boot (especially when
no network hardware is present in the hardware design to begin with!), we recommend
that you use such a setup whenever possible, at least initially. Once you successfully
have a working base system, you should then customize it to be fully self-hosting, but
retain an optional network filesystem for ease of additional development and testing
as your embedded project progresses. Some systems make use of a special “flag” file,
environment variable, or other indicator that instructs the system whether to boot via
the network or the local filesystem. For example, one of the authors once designed a
system whose startup scripts would check for a file called /nfsboot and then attempt to
mount an NFS filesystem during bootup if this file was present.
As we said earlier, the simplest way to boot your target device from a network is to use
BOOTP/DHCP (DHCP replaces BOOTP, but most DHCP servers also contain support
for the legacy BOOTP protocol), TFTP (Trivial FTP), and NFS.
DHCP is the standard way to provide a network host with basic boot information,
including the location of other servers such as TFTP and NFS. But DHCP does not
actually transfer the kernel image to the target. This is the job of TFTP, the simplest
network protocol for downloading remote files. In the case of an embedded Linux
system, the target uses TFTP to obtain a kernel image from a TFTP server.
As for NFS, it’s the simplest protocol, and the standard on Unix-style systems, for
sharing entire directory trees between a client and a server. An embedded Linux target
can use NFS to mount its root filesystem from an NFS server. NFS cannot be used for
any earlier activity, because it requires a booted Linux kernel to operate.
Together, these three protocols provide a very efficient host/target development setup,
one that has not changed substantially in almost a decade of building embedded Linux
systems.
278 | Chapter 9: Setting Up the Bootloader