Would you like to be notified by email when DM publishes a new blog?
Hello all,
Allow me to introduce myself. I am Deeksha and I come from plains of North India. My tryst with embedded technologies has been 5 years long and every single day I am amazed with the vastness and learning involved. The thing with embedded technologies is either you are into it, or you aren't. You cannot just hang around half-heartedly (I guess that holds true for every field, for that matter).You have to keep the learning and sharing process going on. And that is the reason I am here. I look forward to the comments, feedback and questions so as the topics turn into an interesting voyage.
To start with, I plan to write a series of posts on boot sequence in an ARM based embedded system. And I hope to learn a few things as I write this.
Boot 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
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.
In my upcoming posts, I plan to move on to the details that constitute a bootloader.An ARM bootloader specifically.Till then , happy booting!