Christopher Hallinan - Embedded Linux Primer - A Practical, Real-World Approach

42 Internal registers self-test: passed.

43 ROM checksum self-test: passed (0x8b51f404).

44 IXP4XX-Flash.0: Found 1 x16 devices at 0x0 in 16-bit bank

45 Intel/Sharp Extended Query Table at 0x0031

46 Using buffer write method

47 cfi_cmdset_0001: Erase suspend on write enabled

48 Searching for RedBoot partition table in IXP4XX-Flash.0 at offset 0xfe0000

49 5 RedBoot partitions found on MTD device IXP4XX-Flash.0

50 Creating 5 MTD partitions on "IXP4XX-Flash.0":

51 0x00000000-0x00060000 : "RedBoot"

52 0x00100000-0x00260000 : "MyKernel"

53 0x00300000-0x00900000 : "RootFS"

54 0x00fc0000-0x00fc1000 : "RedBoot config"

55 mtd: partition "RedBoot config" doesn't end on an erase block -- force read-only0x00fe0000-0x01000000 : "FIS directory"

56 NET: Registered protocol family 2

57 IP route cache hash table entries: 1024 (order: 0, 4096 bytes)

58 TCP established hash table entries: 4096 (order: 2, 16384 bytes)

59 TCP bind hash table entries: 4096 (order: 2, 16384 bytes)

60 TCP: Hash tables configured (established 4096 bind 4096)

61 TCP reno registered

62 TCP bic registered

63 NET: Registered protocol family 1

64 Sending BOOTP requests . OK

65 IP-Config: Got BOOTP answer from 192.168.1.10, my address is 192.168.1.141

66 IP-Config: Complete:

67 device=eth0, addr=192.168.1.141, mask=255.255.255.0, gw=255.255.25 5.255,

68 host=192.168.1.141, domain=, nis-domain=(none),

69 bootserver=192.168.1.10, rootserver=192.168.1.10, rootpath=/home/chris/sandbox/coyote-target

70 Looking up port of RPC 100003/2 on 192.168.1.10

71 Looking up port of RPC 100005/1 on 192.168.1.10

72 VFS: Mounted root (nfs filesystem).

73 Freeing init memory: 112K

74 Mounting proc

75 Starting system loggers

76 Configuring lo

77 Starting inetd

78 / #

The kernel produces much useful information during startup, as shown in Listing 5-3. We study this output in some detail in the next few sections. Line 1 is produced by the bootstrap loader we presented earlier in this chapter. This message was produced by the decompression loader found in …/arch/arm/boot/compressed/misc.c.

Line 2 of Listing 5-3 is the kernel version string. It is the first line of output from the kernel itself. One of the first lines of C code executed by the kernel (in .../init/main.c) upon entering start_kernel() is as follows:

printk(linux_banner);

This line produces the output just describedthe kernel version string, Line 2 of Listing 5-3. This version string contains a number of pertinent data points related to the kernel image:

• Kernel version: Linux version 2.6.10-clh

• Username/machine name where kernel was compiled

• Toolchain info: gcc version 3.4.3, supplied by MontaVista Software

• Build number

• Date and time compiled

This is useful information both during development and later in production. All but one of the entries are self-explanatory. The build number is simply a tool that the developers added to the version string to indicate that something more substantial than the date and time changed from one build to the next. It is a way for developers to keep track of the build in a generic and automatic fashion. You will notice in this example that this was the eleventh build in this series, as indicated by the #11 on line 2 of Listing 5-3. The version string is stored in a hidden file in the top-level Linux directory and is called .version. It is automatically incremented by a build script found in .../scripts/mkversion and by the top-level makefile. In short, it is a version string that is automatically incremented whenever anything substantial in the kernel is rebuilt.

Now that we have an understanding of the structure and components of the composite kernel image, let's examine the flow of control from the bootloader to the kernel in a complete boot cycle. As we discussed in Chapter 2, "Your First Embedded Experience," the bootloader is the low-level component resident in system nonvolatile memory (Flash or ROM) that takes control immediately after the power has been applied. It is typically a small, simple set of routines designed primarily to do low-level initialization, boot image loading, and system diagnostics. It might contain memory dump and fill routines for examining and modifying the contents of memory. It might also contain low-level board self-test routines, including memory and I/O tests. Finally, a bootloader contains logic for loading and passing control to another program, usually an operating system such as Linux.

The ARM XScale platform used as a basis for the examples in this chapter contains the Redboot bootloader. When power is first applied, this bootloader is invoked and proceeds to load the operating system (OS). When the bootloader locates and loads the OS image (which could be resident locally in Flash, on a hard drive, or via a local area network or other device), control is passed to that image.

On this particular XScale platform, the bootloader passes control to our head.o module at the label Start in the bootstrap loader. This is illustrated in Figure 5-3.

Figure 5-3. ARM boot control flow

As detailed earlier, the bootstrap loader prepended to the kernel image has a single primary responsibility: to create the proper environment to decompress and relocate the kernel, and pass control to it. Control is passed from the bootstrap loader directly to the kernel proper, to a module called head.o for most architectures. It is an unfortunate historical artifact that both the bootstrap loader and the kernel proper contain a module called head.o because it is a source of confusion to the new embedded Linux developer. The head.o module in the bootstrap loader might be more appropriately called kernel_bootstrap_loader_head.o, although I doubt that the kernel developers would accept this patch. In fact, a recent Linux 2.6 source tree contains no fewer than 37 source files named head.S. This is another reason why you need to know your way around the kernel source tree.

Refer back to Figure 5-3 for a graphical view of the flow of control. When the bootstraploader has completed its job, control is passed to the kernel proper's head.o, and from there to start_kernel() in main.c.

The intention of the kernel developers was to keep the architecture-specific head.o module very generic, without any specific machine [39] The term machine as used here refers to a specific hardware reference platform. dependencies. This module, derived from the assembly language file head.S, is located at .../arch//kernel/head.S, where is replaced by the given architecture. The examples in this chapter are based on the ARM/XScale, as you have seen, with =arm.

The head.o module performs architecture- and often CPU-specific initialization in preparation for the main body of the kernel. CPU-specific tasks are kept as generic as possible across processor families. Machine-specific initialization is performed elsewhere, as you will discover shortly. Among other low-level tasks, head.o performs the following tasks: