PROCESSOR BOOTING

Processor state after RESET

On reset event, processor starts executing instructions from a fixed Memory Address, called “Reset Vector Address”. The Reset Vector address for a given processor is fixed.

In a simple system, the Reset Vector Address is mapped to a "Non-Volatile" Memory (ROM) Device. After the Code (Program) for the system has been finalized, the final executable (machine code or instructions) file is fused (written) in to this non-volatile ROM. . After reset, Instruction Fetch Unit of the processor will start executing instruction from the start address of this non-volatile memory (which is the Reset Vector Address). Another variation to the above described scheme is possible wherein, the Reset Vector Address can have a "Jump Instruction". This Jump Instruction can take the instruction flow to the memory location where target application is stored.

Though the above mentioned schemes work fine of a very basic system, most advanced systems make use of advanced booting options. The need of advanced booting mechanism arise because of following reasons:

(a) The typical access time (read time) for ROM is much higher than the typical access time of RAMs (e.g. SDRAM). Hence executing code from ROM is not desirable in a system which employs high speed processor. The slow memory accesses will become bottle neck for the processor's control and execution unit (which would have been able to run faster in combination with a faster memory).

(b) ROMs are costlier (in terms of money) as compared to RAM and SDRAM. Using SDRAM (or RAM) instead of ROM, can reduce the overall system cost. This cost advantage is specially significant in complex (performing complex operations) systems, where code size is very high (because of huge and complex programming logics).

(c) Advanced application might involve self-modifying codes. Self modification (over-writing by itself) of non-volatile memories is not possible, becaues these device are Read Only. Hence the application code for such applications must reside in a RAM (or SDRAM).

Advanced Booting and Boot Loader

In advanced systems, a boot loader resides at the "Reset Vector Location" (instead of the application code). Boot Loader is a special purpose code which is responsible for loading the actual application in the system memory, after reset. The application to be loaded is generally available in a non-volatile memory in a "Loader File Format" (this file format is known to the Boot Loader).
The Loader file consists of different sections which needs to be loaded in to the memory. Each section has a header and a data section. Header section consists of "section_type", "section_size", "section_destination_address" (and some other information) tags. These tags are used by the boot loader for loading a particular section in to target memory.

Booting Options

Most modern embedded processors provide a variety of booting options. The booting can be done from a non-volatile memory (NOR Flash, NAND Flash, SPI Flash, I2C Flash or UART Flash), or it can be done via a host processor (over SPI, or UART, or Network interface or Parallel Interface). The later is called Slave boot. Boot Configuration of a processor is defined by the setting of BMODE[0..N] pins, which are available on the external interface of the processor. A particular boot mode can be selected using the proper boot configuration.

Primary and Secondary Boot loaders

Generally processors involve two stage boot loaders. The first boot loader, which resides at the Reset Vector Location, does some preliminary system initialization and then loads the secondary boot loader based on boot configuration settings. Secondary boot loader is boot configuration specific (different loaders for different boot modes). Secondary boot loader loads the main application (and in the end it generally over-write itself with the application code).

Boot compression

Some designers want to compress the loader file, in order to be able to fit it in to a smaller flash memory (to reduce cost). Some times compression is also needed, when the loader file is big enough to fit in to the maximum supported boot memory size. In such a scenario, the loader file can be compressed using a compression algorithm (the open source zlib compression standard is currently widely used). The secondary boot loader in this case does the additional task of uncompressing the loader file, before actual loading starts.

User Comments