Boot sequence for an ARM based embedded system -2

DMApril 6, 201213 comments

In the last post, we discussed about the startup execution sequence on an ARM based embedded system in broader terms. In this post, we are going to cover the details of a startup code.These details are also available through various ARM resources , however for the sake of completion of our discussion , here is - 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


[ - ]
Comment by Sachin TiwariMay 29, 2012
You should write a book on basics of ARM... Your explanations are good for fresh engineers... You always touch the very upper layer of the subject and its good for a basic intro...
[ - ]
Comment by weidongyaoMarch 5, 2013
hello,Recnetly I have developed by CYCLONE-III & AT91RM9200.(China)
[ - ]
Comment by vishnuchittan.mJune 5, 2012
HI Deeksha am very new to this field.Now am working on 8051.I am very much passionate to work on ARM.Can you help me ....
[ - ]
Comment by Sachin TiwariJune 6, 2012
vishnuchittan.m You can buy a board and make sure you have appropriate tutorials available with codes and kick start your learning process. I suggest you start with LPC2148. Its a ARM7 based controller. Its a good start for ARM beginner. You can get various options from I had like to believe that you get the ARM boards at cheapest possible price here (for India). All the best with your learning.
[ - ]
Comment by February 18, 2013
Brilliant article. Explanation in Step 3 completed the puzzle. Looking forward to more such articles. A sample code would help a lot if it is available.
[ - ]
Comment by CryptomanSeptember 5, 2012
This is a nice overview in a nutshell. It is a good starting point I think. However, my suggestion is to get an ARM platform and work with it to fully understand what is explained in this article. One will need a more thorough reference on the side to make good progress with such a hands on learning approach.
[ - ]
Comment by Raghu31October 9, 2012
Thanks for the article... good information..
Could you elaborate little more on the mapping/re-mapping concept between ROM and RAM.. and NOR and NAND flash connection with RAM.. I am unable to understand it..I want to know it in broder way...
Thanks in advance...
[ - ]
Comment by March 6, 2013
Thank you so much!
[ - ]
Comment by Pavan24April 16, 2014
Step3 says that "if the vector table is present in ROM, it cannot be modified by code."
I really did not understand what is the necessity to modify the vector table by code.

Pleas explain.
[ - ]
Comment by sen49September 13, 2014
Great explanation Deeksha.........Cleared lot of my doubts....Thanks a lot.... \m/
[ - ]
Comment by Devi9June 5, 2015
Deeksha, This is an excellent article for beginners.. Well explained.
[ - ]
Comment by Vishal55July 11, 2015
Hi Deeksha,
Its a very nice article. Good job!
[ - ]
Comment by tilak1May 22, 2018

Thanks for the detailed explanation. I would be great to anyone if they could show me a practical implementation. 

To post reply to a comment, click on the 'reply' button attached to each comment. To post a new comment (not a reply to a comment) check out the 'Write a Comment' tab at the top of the comments.

Please login (on the right) if you already have an account on this platform.

Otherwise, please use this form to register (free) an join one of the largest online community for Electrical/Embedded/DSP/FPGA/ML engineers: