The media on which the bootable image is stored, and how it is stored (compressed or not compressed) determine what the IPL must do with the image.
The type of removable media used to store the IPL and the IFS affects many aspects of the IPL design. One of the most significant factors is whether the storage media is linearly-mapped (e.g., NOR FLASH), or non-linearly-mapped (e.g., eMMC, SD card), because it determines if the IPL can use XIP.
Other important factors include how the image is stored (compressed on not compressed), and the device on which it is stored (eMMC, SD card, hard disk, etc.; see Image storage methods).
With a linearly-mapped device (e.g., a ROM device) the entire image is in directly-addressable storage that maps its entire address space into the processor's address space. The processor can address any location in the OS image, so the IPL needs to copy only the startup code (and not the entire image) into RAM.
If the removable media is linearly-mapped, the IPL can use eXecute In Place (XIP). If XIP is used, the .text section of the IPL (the code) in the linker file (e.g., mx6sx-sabre-sdb.lnk or vayu-evm.lnk) must be in the linearly-mapped address space.
All the IPL assembly code can run before the image is copied into RAM.
With non-linearly-mapped devices (e.g., an eMMC, SD card, or SPI NOR device), the image is in storage that can't be mapped directly into the processor's address space. The processor can't address the OS image, so the IPL needs to copy the entire image (including the startup code) into RAM.
If a bootable image is too large to store on the removable media in its original form, or if hardware limitations (e.g., slow bus) make copying and extracting the image more efficient that copying the image in its original format, the bootable image may be compressed on either a linearly-mapped or a non-linearly mapped removable storage device.
When it builds the OS image, the mkifs utility checks for the +compress attribute in the build file. If the attribute is set (e.g., [virtual = x86_64, bios +compress boot = { ), mkifs compresses the image (see the OS Image Buildfiles chapter).
If the image is compressed, it must be copied to RAM and extracted before the main() function in the IPL's second stage calls the image_scan() functions. When you write an IPL or update a system that uses a compressed image, watch out for the following:
Leave enough room for the entire uncompressed image between the location where you copy the compressed image and the address to which you will extract it.
For examples of different storage options and how they are used, see Image storage methods in this chapter.
The IPL loads the OS image from different types of devices, or over a network, dependent on what the board supports. The more common locations where bootable images are stored include:
With ARM boards, booting from disk requires at least:
As well as supporting a primary method for loading the OS image, the IPL code may also need to support an alternate method for loading the OS image (e.g., an .altboot in the case of a disk boot on x86 boards). This method may also have to be an automatic fallback in the event that the primary image is corrupt. You can use a .boot directory with a list of fallback IFSs that can be loaded from read-only media.
To validate a bootable image, use the checksum() function to perform a checksum over the entire image. A call to validate an image looks like this:
checksum (image_paddr, startup_size); checksum (image_paddr + startup_size, stored_size - startup_size);