0% found this document useful (0 votes)
295 views7 pages

Embedded Linux Booting

The boot sequence for an ARM-based embedded system begins with the processor jumping to the reset vector located at address 0x0 after a power-on reset. The code stored here is the boot ROM, which performs initial system setup and initialization. The boot ROM then loads and transfers control to the software bootloader, which further initializes the system and loads the operating system. The bootloader then passes control to the operating system.

Uploaded by

Rajeev Rao Battu
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as ODT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
295 views7 pages

Embedded Linux Booting

The boot sequence for an ARM-based embedded system begins with the processor jumping to the reset vector located at address 0x0 after a power-on reset. The code stored here is the boot ROM, which performs initial system setup and initialization. The boot ROM then loads and transfers control to the software bootloader, which further initializes the system and loads the operating system. The bootloader then passes control to the operating system.

Uploaded by

Rajeev Rao Battu
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as ODT, PDF, TXT or read online on Scribd
You are on page 1/ 7

Boot Sequence for an ARM based embedded system

Boot sequence for a Boot ROM based embedded system. It is based on my experiences with an
ARM processor based embedded system, but the concept of an integrated Boot ROM is used by
other modern CPUs and microcontrollers as well.
In an ARM embedded system, at the time of power on, CPU is uninitialized and a basic clock setup,
system specifics' setup is required before proceeding to the bigger and complex tasks. A piece of
code is required at power on which does the basic system setup before handing over the control to
the bootloader present in flash(already programmed) or to support the download tool for
programming the flash and then handing over the control to the bootloader present in flash.
For this purpose, a hardware bootloader generally called as Boot Rom is provided by vendor (pre-
loaded into the processors’ internal ROM).This is hardwired at the manufacturing time. After a
power on reset, that causes the processor core to jump to the reset vector, Boot Rom is the first code
to execute in the processor.
Responsibilities of Bootrom
 Bootrom performs the essential initialization including programming the clocks, stacks,
interrupt set up etc.
 Bootrom will detect the boot media using a system register. This is to determine where to
find the software bootloader. A particular sequence of probing for boot media is followed as
defined by the manufacturer. This includes the order of looking for bootloader in external
NOR/NAND flash, or probing for some specific characters on UART /USB for establishing
connection with downloader to download the binary in flash. If no bootloader is found in
any external memory, bootrom listens for a download request on UART/USB port to start
the download process.
 Thus during the probing process, if the flash has already been programmed, software
bootloader will be detected to be available in flash , if not so –it will be downloaded to the
flash by bootrom.(This probing sequence will generally assign higher priority to external
memory , so if bootloader is detected to be present in memory, it won't proceed to
downloading the image again)
 For platforms using NAND flash , the bootrom will load this boot loader to internal RAM
and set the program counter at the load address of the SW bootloader in RAM.
 For platforms using NOR flash, control is transferred to the external flash (NOR flash is
XiP- Execute in Place).
There is another point to be noted here regarding bad block management support in Boot ROM. If
sw bootloader is residing only in block 0 of flash, no Bad block Management is required in Boot
ROM as block 0 is guaranteed to be good by the manufacturer but if sw bootloader resides in block
1 onwards or is large enough to span multiple blocks, then ,Boot ROM needs to include bad block
handling. Bad block management will include relocating the contents of the block in flash that goes
bad in the process of accessing the block to a new block and updating the bad block/relocation table
of the platform.
Software Bootloader
The main task of S/W bootloader is to load the OS and pass over the execution to it after setting up
necessary environment for its setup. For this, the bootloader must first initialize the DDR memory
(this includes setting uBoot Sequence for an ARM based embedded system
This post is going to explore the boot sequence for a Boot ROM based embedded system. It is based
on my experiences with an ARM processor based embedded system, but the concept of an
integrated Boot ROM is used by other modern CPUs and microcontrollers as well.
In an ARM embedded system, at the time of power on, CPU is uninitialized and a basic clock setup,
system specifics' setup is required before proceeding to the bigger and complex tasks. A piece of
code is required at power on which does the basic system setup before handing over the control to
the bootloader present in flash(already programmed) or to support the download tool for
programming the flash and then handing over the control to the bootloader present in flash.
For this purpose, a hardware bootloader generally called as Boot Rom is provided by vendor (pre-
loaded into the processors’ internal ROM).This is hardwired at the manufacturing time. After a
power on reset, that causes the processor core to jump to the reset vector, Boot Rom is the first code
to execute in the processor.
Responsibilities of Bootrom
 Bootrom performs the essential initialization including programming the clocks, stacks,
interrupt set up etc.
 Bootrom will detect the boot media using a system register. This is to determine where to
find the software bootloader. A particular sequence of probing for boot media is followed as
defined by the manufacturer. This includes the order of looking for bootloader in external
NOR/NAND flash, or probing for some specific characters on UART /USB for establishing
connection with downloader to download the binary in flash. If no bootloader is found in
any external memory, bootrom listens for a download request on UART/USB port to start
the download process.
 Thus during the probing process, if the flash has already been programmed, software
bootloader will be detected to be available in flash , if not so –it will be downloaded to the
flash by bootrom.(This probing sequence will generally assign higher priority to external
memory , so if bootloader is detected to be present in memory, it won't proceed to
downloading the image again)
 For platforms using NAND flash , the bootrom will load this boot loader to internal RAM
and set the program counter at the load address of the SW bootloader in RAM.
 For platforms using NOR flash, control is transferred to the external flash (NOR flash is
XiP- Execute in Place).
There is another point to be noted here regarding bad block management support in Boot ROM. If
sw bootloader is residing only in block 0 of flash, no Bad block Management is required in Boot
ROM as block 0 is guaranteed to be good by the manufacturer but if sw bootloader resides in block
1 onwards or is large enough to span multiple blocks, then ,Boot ROM needs to include bad block
handling. Bad block management will include relocating the contents of the block in flash that goes
bad in the process of accessing the block to a new block and updating the bad block/relocation table
of the platform.
Software Bootloader
The main task of S/W bootloader is to load the OS and pass over the execution to it after setting up
necessary environment for its setup. For this, the bootloader must first initialize the DDR memory
(this includes setting up the controller, refresh rate etc).It must also perform bad block management
while accessing the flash memory.
After the system setup, bootloader’s responsibility would be to look for an OS to boot. Again, like
Boot Rom, if OS is not already loaded to flash, it will load this from the boot media in flash and
execute-in-place in case of NOR flash, or place it in RAM in case of NAND flash. It will also place
some boot parameters in memory for the OS to read when it starts up if required.
After all the necessary system setup, bootloader will pass over the execution to OS and go out of
scope.
p the controller, refresh rate etc).It must also perform bad block management while accessing the
flash memory.
After the system setup, bootloader’s responsibility would be to look for an OS to boot. Again, like
Boot Rom, if OS is not already loaded to flash, it will load this from the boot media in flash and
execute-in-place in case of NOR flash, or place it in RAM in case of NAND flash. It will also place
some boot parameters in memory for the OS to read when it starts up if required.
After all the necessary system setup, bootloader will pass over the execution to OS and go out of
scope.

the flow the startup code for an ARM based embedded system.
Step 1: The reset
On startup, the processor will jump to fixed location ,(most ARM cores support two vector locations
0x0 or 0xFFFF0000, controlled via a signal sampled at reset and a bit in CP15. Lets say that the
core is configured to have its vectors at 0x0 ). This address should contain the reset vector and the
default vector table. Reset vector is always the first instruction to be executed.The reset vector in
this table will contain a branch to an address which will contain the reset code. Normally, at this
stage, the rest of the vector table contains just the dummy handler- a branch instruction that causes
an infinite loop(this is because this vector table is used very briefly and later on replaced by vector
table in RAM after memory remap operation-explained in step 3) .
This article is available in PDF format for easy printing
Step 2: The reset code
This reset code to which the jump has been executed from the reset vector will do the following
tasks:
->Set up system registers and memory environment
->Set up MMU
->Setup stack pointers : initialize stack pointers for all ARM modes
->Set up bss section : zeroing the ZI data region, copying initialization values for initialized
variables from ROM to RAM
->Set up hw : CPU clock initialization , external bus interface configuration,low level peripheral
initialization etc

Step 3: Remap Memory


One of the job of the initial reset code will be memory remapping.At the time of power up, the
processor jumps at fixed location 0x0.So, this is important to ensure there is some executable code
present at this location at the time of power up. And to ensure this, some non volatile memory
should be mapped to this address.
So, at the time of power up, ROM is mapped to 0×0 location which contains the reset exception and
default vector table. However, later on, during the s/w execution, on every interrupt, the processor
needs to jump to the vector table which starts from 0×0 location. If this vector table is located in
ROM, the execution of interrupts will become very slow as ROM is slower than RAM (ROM
requires more wait states as well as more power consumption for access as compared to
RAM).Also, if the vector table is present in ROM, it cannot be modified by code.
Therefore for faster and more efficient execution of interrupts , it is better if interrupt handlers and
vector table is located in RAM at address 0×0.However, if RAM was mapped to address 0×0 at the
power on of processor, being a volatile memory , it won’t contain any executable code. Thus, it
becomes important that at the time of start up, ROM is located at 0×0 address and then during
normal execution RAM is re-mapped to this location.Memory remapping can be achieved through
hardware remapping, that is changing the address map of the bus. This can also be acheived through
MMU.
Step 4: Jumping to C code (main function for eg)
After the execution environment has been setup (setting up the vector table (handlers for each entry
in the vector table), stack, critical I/Os etc., copying initialization values for initialized variables
from ROM to RAM and resetting all other variables to zero.), assembly code can give way to C the
flow the startup code for an ARM based embedded system.
Step 1: The reset
On startup, the processor will jump to fixed location ,(most ARM cores support two vector locations
0x0 or 0xFFFF0000, controlled via a signal sampled at reset and a bit in CP15. Lets say that the
core is configured to have its vectors at 0x0 ). This address should contain the reset vector and the
default vector table. Reset vector is always the first instruction to be executed.The reset vector in
this table will contain a branch to an address which will contain the reset code. Normally, at this
stage, the rest of the vector table contains just the dummy handler- a branch instruction that causes
an infinite loop(this is because this vector table is used very briefly and later on replaced by vector
table in RAM after memory remap operation-explained in step 3) .
This article is available in PDF format for easy printing
Step 2: The reset code
This reset code to which the jump has been executed from the reset vector will do the following
tasks:
->Set up system registers and memory environment
->Set up MMU
->Setup stack pointers : initialize stack pointers for all ARM modes
->Set up bss section : zeroing the ZI data region, copying initialization values for initialized
variables from ROM to RAM
->Set up hw : CPU clock initialization , external bus interface configuration,low level peripheral
initialization etc

Step 3: Remap Memory


One of the job of the initial reset code will be memory remapping.At the time of power up, the
processor jumps at fixed location 0x0.So, this is important to ensure there is some executable code
present at this location at the time of power up. And to ensure this, some non volatile memory
should be mapped to this address.
So, at the time of power up, ROM is mapped to 0×0 location which contains the reset exception and
default vector table. However, later on, during the s/w execution, on every interrupt, the processor
needs to jump to the vector table which starts from 0×0 location. If this vector table is located in
ROM, the execution of interrupts will become very slow as ROM is slower than RAM (ROM
requires more wait states as well as more power consumption for access as compared to
RAM).Also, if the vector table is present in ROM, it cannot be modified by code.
Therefore for faster and more efficient execution of interrupts , it is better if interrupt handlers and
vector table is located in RAM at address 0×0.However, if RAM was mapped to address 0×0 at the
power on of processor, being a volatile memory , it won’t contain any executable code. Thus, it
becomes important that at the time of start up, ROM is located at 0×0 address and then during
normal execution RAM is re-mapped to this location.Memory remapping can be achieved through
hardware remapping, that is changing the address map of the bus. This can also be acheived through
MMU.
Step 4: Jumping to C code (main function for eg)
After the execution environment has been setup (setting up the vector table (handlers for each entry
in the vector table), stack, critical I/Os etc., copying initialization values for initialized variables
from ROM to RAM and resetting all other variables to zero.), assembly code can give way to C
Code.
Step 5: Setting up the external memory, loading and executing the OS image
External memory should be setup before loading an image to it (Refresh rate, clock etc),OS image
can then be loaded from flash(assuming its NAND flash) to RAM.The OS image may be
compressed in which case it needs to be decompressed before PC can be modified to point to the
operating system entry point address.
References :
(You can also refer them as "good" ARM study material for development)
1)ARM System Developer's guide(Andrew N.Sloss,Dominic Symes,Chris Wright)
2)Building Bare-metal ARM systems with GNU
3)ARM Developer's Suite Developer Guide
Code.
Step 5: Setting up the external memory, loading and executing the OS image
External memory should be setup before loading an image to it (Refresh rate, clock etc),OS image
can then be loaded from flash(assuming its NAND flash) to RAM.The OS image may be the flow
the startup code for an ARM based embedded system.
Step 1: The reset
On startup, the processor will jump to fixed location ,(most ARM cores support two vector locations
0x0 or 0xFFFF0000, controlled via a signal sampled at reset and a bit in CP15. Lets say that the
core is configured to have its vectors at 0x0 ). This address should contain the reset vector and the
default vector table. Reset vector is always the first instruction to be executed.The reset vector in
this table will contain a branch to an address which will contain the reset code. Normally, at this
stage, the rest of the vector table contains just the dummy handler- a branch instruction that causes
an infinite loop(this is because this vector table is used very briefly and later on replaced by vector
table in RAM after memory remap operation-explained in step 3) .
This article is available in PDF format for easy printing
Step 2: The reset code
This reset code to which the jump has been executed from the reset vector will do the following
tasks:
->Set up system registers and memory environment
->Set up MMU
->Setup stack pointers : initialize stack pointers for all ARM modes
->Set up bss section : zeroing the ZI data region, copying initialization values for initialized
variables from ROM to RAM
->Set up hw : CPU clock initialization , external bus interface configuration,low level peripheral
initialization etc

Step 3: Remap Memory


One of the job of the initial reset code will be memory remapping.At the time of power up, the
processor jumps at fixed location 0x0.So, this is important to ensure there is some executable code
present at this location at the time of power up. And to ensure this, some non volatile memory
should be mapped to this address.
So, at the time of power up, ROM is mapped to 0×0 location which contains the reset exception and
default vector table. However, later on, during the s/w execution, on every interrupt, the processor
needs to jump to the vector table which starts from 0×0 location. If this vector table is located in
ROM, the execution of interrupts will become very slow as ROM is slower than RAM (ROM
requires more wait states as well as more power consumption for access as compared to
RAM).Also, if the vector table is present in ROM, it cannot be modified by code.
Therefore for faster and more efficient execution of interrupts , it is better if interrupt handlers and
vector table is located in RAM at address 0×0.However, if RAM was mapped to address 0×0 at the
power on of processor, being a volatile memory , it won’t contain any executable code. Thus, it
becomes important that at the time of start up, ROM is located at 0×0 address and then during
normal execution RAM is re-mapped to this location.Memory remapping can be achieved through
hardware remapping, that is changing the address map of the bus. This can also be acheived through
MMU.
Step 4: Jumping to C code (main function for eg)
After the execution environment has been setup (setting up the vector table (handlers for each entry
in the vector table), stack, critical I/Os etc., copying initialization values for initialized variables
from ROM to RAM and resetting all other variables to zero.), assembly code can give way to C
Code.
Step 5: Setting up the external memory, loading and executing the OS image
External memory should be setup before loading an image to it (Refresh rate, clock etc),OS image
can then be loaded from flash(assuming its NAND flash) to RAM.The OS image may be
compressed in which case it needs to be decompressed before PC can be modified to point to the
operating system entry point address.
References :
(You can also refer them as "good" ARM study material for development)
1)ARM System Developer's guide(Andrew N.Sloss,Dominic Symes,Chris Wright)
2)Building Bare-metal ARM systems with GNU
3)ARM Developer's Suite Developer Guide
compressed in which case it needs to be decompressed before PC can be modified to point to the
operating system entry point address.
References :
(You can also refer them as "good" ARM study material for development)
1)ARM System Developer's guide(Andrew N.Sloss,Dominic Symes,Chris Wright)
2)Building Bare-metal ARM systems with GNU
3)ARM Developer's Suite Developer Guide

You might also like