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

gzip -f -9 < Image > piggy.gz

This creates a new file called piggy.gz, which is simply a compressed version of the binary kernel Image. You can see this graphically in Figure 5-1. What follows next is rather interesting. An assembly language file called piggy.S is assembled, which contains a reference to the compressed piggy.gz. In essence, the binary kernel image is being piggybacked into a low-level assembly language bootstrap loader . [38] Not to be confused with the bootloader, a bootstrap loader can be considered a second-stage loader, where the bootloader itself can be thought of as a first-stage loader. This bootstrap loader initializes the processor and required memory regions, decompresses the binary kernel image, and loads it into the proper place in system memory before passing control to it. Listing 5-2 reproduces .../arch/arm/boot/compressed/piggy.S in its entirety.

Listing 5-2. Assembly File Piggy.S

.section .piggydata,#alloc

.globl input_data

input_data:

.incbin "arch/arm/boot/compressed/piggy.gz"

.globl input_data_end

input_data_end:This small assembly language file is simple yet produces a complexity that is not immediately obvious. The purpose of this file is to cause the compressed, binary kernel image to be emitted by the assembler as an ELF section called .piggydata. It is triggered by the .incbin assembler preprocessor directive, which can be viewed as the assembler's version of a #include file. In summary, the net result of this assembly language file is to contain the compressed binary kernel image as a payload within another imagethe bootstrap loader. Notice the labels input_data and input_data_end. The bootstrap loader uses these to identify the boundaries of the binary payload, the kernel image.

Not to be confused with a bootloader, many architectures use a bootstrap loader (or second-stage loader) to load the Linux kernel image into memory. Some bootstrap loaders perform checksum verification of the kernel image, and most perform decompression and relocation of the kernel image. The difference between a bootloader and a bootstrap loader in this context is simple: The bootloader controls the board upon power-up and does not rely on the Linux kernel in any way. In contrast, the bootstrap loader's primary purpose in life is to act as the glue between a board-level bootloader and the Linux kernel. It is the bootstrap loader's responsibility to provide a proper context for the kernel to run in, as well as perform the necessary steps to decompress and relocate the kernel binary image. It is similar to the concept of a primary and secondary loader found in the PC architecture.

Figure 5-2 makes this concept clear. The bootstrap loader is concatenated to the kernel image for loading.

Figure 5-2. Composite kernel image for ARM XScale

In the example we have been studying, the bootstrap loader consists of the binary images shown in Figure 5-2. The functions performed by this bootstrap loader include the following:

• Low-level assembly processor initialization, which includes support for enabling the processor's internal instruction and data caches, disabling interrupts, and setting up a C runtime environment. These include head.o and head-xscale.o.

• Decompression and relocation code, embodied in misc.o.

• Other processor-specific initialization, such as big-endian.o, which enables the big endian mode for this particular processor.

It is worth noting that the details we have been examining in the preceding sections are specific to the ARM/XScale kernel implementation. Each architecture has different details, although the concepts are similar. Using a similar analysis to that presented here, you can learn the requirements of your own architecture.

Perhaps you've seen a PC workstation booting a desktop Linux distribution such as Red Hat or SUSE Linux. After the PC's own BIOS messages, you see a flurry of console messages being displayed by Linux as it initializes the various kernel subsystems. Significant portions of the output are common across disparate architectures and machines. Two of the more interesting early boot messages are the kernel version string and the kernel command line , which is detailed shortly. Listing 5-3 reproduces the kernel boot messages for the ADI Engineering Coyote Reference Platform booting Linux on the Intel XScale IXP425 processor. The listing has been formatted with line numbers for easy reference.

Listing 5-3. Linux Boot Messages on IPX425

1 Uncompressing Linux... done, booting the kernel.

2 Linux version 2.6.14-clh (chris@pluto) (gcc version 3.4.3 (MontaVista 3.4.3-25.0.30 .0501131 2005-07-23)) #11 Sat Mar 25 11:16:33 EST 2006

3 CPU: XScale-IXP42x Family [690541c1] revision 1 (ARMv5TE)

4 Machine: ADI Engineering Coyote

5 Memory policy: ECC disabled, Data cache writeback

6 CPU0: D VIVT undefined 5 cache

7 CPU0: I cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets

8 CPU0: D cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets

9 Built 1 zonelists

10 Kernel command line: console=ttyS0,115200 ip=bootp root=/dev/nfs

11 PID hash table entries: 512 (order: 9, 8192 bytes)

12 Console: colour dummy device 80x30

13 Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)

14 Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)

15 Memory: 64MB = 64MB total

16 Memory: 62592KB available (1727K code, 339K data, 112K init)

17 Mount-cache hash table entries: 512

18 CPU: Testing write buffer coherency: ok

19 softlockup thread 0 started up.

20 NET: Registered protocol family 16

21 PCI: IXP4xx is host

22 PCI: IXP4xx Using direct access for memory space

23 PCI: bus0: Fast back to back transfers enabled

24 dmabounce: registered device 0000:00:0f.0 on pci bus

25 NetWinder Floating Point Emulator V0.97 (double precision)

26 JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc.

27 Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing disabled

28 ttyS0 at MMIO 0xc8001000 (irq = 13) is a XScale

29 io scheduler noop registered

30 io scheduler anticipatory registered

31 io scheduler deadline registered

32 io scheduler cfq registered

33 RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize

34 loop: loaded (max 8 devices)

35 eepro100.c:v1.09j-t 9/29/99 Donald Becker http://www.scyld.com/network/eepro100.html

36 eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin .com.sg> and others

37 eth0: 0000:00:0f.0, 00:0E:0C:00:82:F8, IRQ 28.

38 Board assembly 741462-016, Physical connectors present: RJ45

39 Primary interface chip i82555 PHY #1.

40 General self-test: passed.

41 Serial sub-system self-test: passed.