Boot sequence for an ARM based embedded system -2
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) .
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
~~Deeksha
- Comments
- Write a Comment Select to add a comment
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...
I really did not understand what is the necessity to modify the vector table by code.
Pleas explain.
Its a very nice article. Good job!
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: