The start and end offsets can be used to determine the length of the compressed image (size = end -
start). This is used by several bootloaders to determine if any data is appended to the kernel image.
This data is typically used for an initial RAM disk (initrd). The start address is usually 0 as the zIm-
age code is position independent.
The zImage code is Position Independent Code (PIC) so may be loaded anywhere within the avail-
able address space. The maximum kernel size after decompression is 4Megabytes. This is a hard
limit and would include the initrd if a bootpImage target was used.
Note
Although the zImage may be located anywhere, care should be taken. Starting a com-
pressed kernel requires additional memory for the image to be uncompressed into. This
space has certain constraints.
The zImage decompression code will ensure it is not going to overwrite the compressed
data. If the kernel detects such a conflict it will uncompress the image immediately after
the compressed zImage data and relocate the kernel after decompression. This obviously
has the impact that the memory region the zImage is loaded into must have up to
4Megabytes of space after it (the maximum uncompressed kernel size), i.e. placing the zI-
mage in the same 4Megabyte bank as its ZRELADDR would probably not work as expec-
ted.
Despite the ability to place zImage anywhere within memory, convention has it that it is loaded at
the base of physical RAM plus an offset of 0x8000 (32K). This leaves space for the parameter block
usually placed at offset 0x100, zero page exception vectors and page tables. This convention is very
common.
6. Loading an initial RAM disk
An initial RAM disk is a common requirement on many systems. It provides a way to have a root
filesystem available without access to other drivers or configurations. Full details can be obtained
from linux/Documentation/initrd.txt
There are two methods available on ARM Linux to obtain an initial RAM disk. The first is a special
build target bootpImage which takes an initial RAM disk at build time and appends it to a zImage.
This method has the benefit that it needs no bootloader intervention, but requires the kernel build
process to have knowledge of the physical address to place the ramdisk (using the INITRD_PHYS
definition). The hard size limit for the uncompressed kernel and initrd of 4Megabytes applies. Be-
cause of these limitations this target is rarely used in practice.
The second and much more widely used method is for the bootloader to place a given initial ramdisk
image, obtained from whatever media, into memory at a set location. This location is passed to the
kernel using ATAG_INITRD2 and ATAG_RAMDISK.
Conventionally the initrd is placed 8Megabytes from the base of physical memory. Wherever it is
placed there must be sufficient memory after boot to decompress the initial ramdisk into a real ram-
disk i.e. enough memory for zImage + decompressed zImage + initrd + uncompressed ramdisk. The
compressed initial ramdisk memory will be freed after the decompression has happened. Limitations
to the position of the ramdisk are:
It must lie completely within a single memory region (must not cross between areas defined by dif-
ferent ATAG_MEM parameters)
It must be aligned to a page boundary (typically 4k)
It must not conflict with the memory the zImage head code uses to decompress the kernel or it will
be overwritten as no checking is performed.
7. Initialising a console
A console is highly recommended as a method to see what actions the kernel is performing when
initialising a system. This can be any input output device with a suitable driver, the most common