by the board-specific header file:
#define CONFIG_COMMANDS (CONFIG_CMD_DFL | CFG_CMD_DHCP)
Instead of typing out each individual CFG_* macro in your own board-specific configuration header, you can start from a default set of commands predefined in the U-Boot source. The macro CONFIG_CMD_DFL defines this default set of commands. CONFIG_CMD_DFL specifies a list of default U-Boot command sets such as tftpboot (boot an image from a tftpserver), bootm (boot an image from memory), memory utilities such as md (display memory), and so on. To enable your specific combination of commands, you can start with the default and add and subtract as necessary. The example from Listing 7-4 adds the DHCP command set to the default. You can subtract in a similar fashion:
#define CONFIG_COMMANDS (CONFIG_CMD_DFL & ~CFG_CMD_NFS)
Take a look at any board-configuration header file in .../include/configs/ for examples.
7.3.3. Network Operations
Many bootloaders include support for Ethernet interfaces. In a development environment, this is a huge time saver. Loading even a modest kernel image over a serial port can take minutes versus a few seconds over a 10Mbps Ethernet link. Furthermore, serial links are more prone to errors from poorly behaved serial terminals.
Some of the more important features to look for in a bootloader include support for the BOOTP, DHCP, and TFTP protocols. For those unfamiliar with these, BOOTP (Bootstrap Protocol) and DHCP (Dynamic Host Control Protocol) are protocols that enable a target device with an Ethernet port to obtain an IP address and other network-related configuration information from a central server. TFTP (Trivial File Transfer Protocol) allows the target device to download files (such as a Linux kernel image) from a TFTP server. References to these protocol specifications are listed at the end of this chapter. Servers for these services are described in Chapter 12, 'Embedded Development Environment.'
Figure 7-1 illustrates the flow of information between the target device and a BOOTP server. The client (U-Boot, in this case) initiates a broadcast packet searching for a BOOTP server. The server responds with a reply packet that includes the client's IP address and other information. The most useful data includes a filename used to download a kernel image.
Figure 7-1. BOOTP client/server handshake
In practice, dedicated BOOTP servers no longer exist as stand-alone servers. DHCP servers included with your favorite Linux distribution also support BOOTP protocol packets.
The DHCP protocol builds upon BOOTP. It can supply the target with a wide variety of configuration information. In practice, the information exchange is often limited by the target/bootloader DHCP client implementation. Listing 7-5 contains an example of a DHCP server configuration block identifying a single target device. This is a snippet from a DHCP configuration file from the Fedora Core 2 DHCP implementation.
Listing 7-5. DHCP Target Specification
host coyote {
hardware ethernet 00:0e:0c:00:82:f8;
netmask 255.255.255.0;
fixed-address 192.168.1.21;
server-name 192.168.1.9;
filename 'coyote-zImage';
option root-path '/home/chris/sandbox/coyote-target';
}
...
When this DHCP server receives a packet from a device matching the hardware Ethernet address contained in Listing 7-5, it responds by sending that device the parameters in this target specification. Table 7-1 describes the fields in the target specification.
Table 7-1. DHCP Target Parameters
| DHCP Target Parameter | Purpose | Comments |
|---|---|---|
| host | Hostname | Symbolic label from DHCP configuration file |
| hardware ethernet | Ethernet hardware address | Low-level Ethernet hardware address of the target's Ethernet interface |
| fixed-address | Target IP address | The IP address that the target will assume |
| netmask | Target netmask | The IP netmask that the target will assume |
| server-name | TFTP server IP address | The IP address to which the target will direct requests for file transfers, root file system, and so on |
| filename | TFTP filename | The filename that the bootloader can use to boot a secondary image (usually a Linux kernel) |
When the bootloader on the target board has completed the BOOTP or DHCP exchange, the parameters described previously are used for further configuration. For example, the bootloader uses the target IP address to bind its Ethernet port with this IP address. The bootloader then uses the server-name field as a destination IP address to request the file contained in the filename field, which, in most cases, represents a Linux kernel image. Although this is the most common use, this same scenario could be used to download and execute manufacturing
