EmbeddedRelated.com
Blogs

Boot Sequence for an ARM based embedded system

DMJanuary 16, 201231 comments

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.

This article is available in PDF format for easy printing

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

  • 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.

In my upcoming posts, I plan to move on to the details that constitute a bootloader.An ARM bootloader specifically.Till then , happy booting!

 



[ - ]
Comment by Sachin TiwariJanuary 29, 2012
First of all congratulation for you first blog. I am might impressed to see women showing such core interest on firmware designs. For you blog, i believe it gives very basic details of boot rom and bootloader. The boot sequence is not always a part on nand, nor or flash. There are a lot of other option. Its not just serial or USB that the sequence waits for binary data and infact the there are various aspects for program data that can be transferred. You dont need to have OS always. Even if you have, the kernal config var The boot rom can decide not to load the actual firmware code at all. you can configure in for digital signatures. Meanwhile whenever you power ON the system, there is always a first level boot (ROM SOC), a second level boot (flash nand, etc) and then finally the real code. The I n D cache memory needs to be enabled when external memory is used rather than I-TCM. Since the address mapping is turned off until the MMU is enabled, this code is cached with its virtual address equal to its physical address. As soon as the MMU is enabled, these flat-mapped addresses will become invalid as the cache is now looking for virtual addresses as defined in the MMU page table, so it is important to remember to invalidate the I-Cache when enabling the MMU. The code which enables the MMU should be placed in an area whose virtual address is the same as its physical address to avoid issues with a discontinuity of the virtual addresses between consecutive instructions when the MMU becomes active.
[ - ]
Comment by Sachin TiwariJanuary 29, 2012
Some spelling mistakes here and there probably bec i was trying to type in too fast
[ - ]
Comment by DeekshaJanuary 31, 2012
@Sachin :Thanks for the encouraging words,Sachin :).You are right, I covered very basics of boot sequence keeping in mind it is understandable to beginners also.So , tried to give just a broad outline taking some specific cases.
[ - ]
Comment by mmuazzamSeptember 8, 2019

Hi Deeksha,

     I have worked on PPC board booting, found your article very good and helping in understanding basics of booting. According to me if basics are clear then, i think complex things can be achieved easily. Thanks a lot and look forward to see such artiles in future.

[ - ]
Comment by billp37January 16, 2012
Is a FIG forth availble for the ARM-based system you are working with? Which system are you workin with? Google 'embedded controller forth for the 8051 family' for my interest.
[ - ]
Comment by DeekshaJanuary 17, 2012
@billp37 : Thanks for visiting.I am not aware of that currently, but I'll update the space soon after educating myself on it.
[ - ]
Comment by RoshSeptember 28, 2014
Really nice article. Helped me a lot to clear my several doubts regarding bootloader and booting process.
Waiting for your other articles.
[ - ]
Comment by kirti_sonawaneJanuary 16, 2012
It is really helpful for me, as an embedded fresher. Thank you.
[ - ]
Comment by DeekshaJanuary 17, 2012
Thanks Kirti,it feels great to know it helped :)
[ - ]
Comment by karthik.sJanuary 17, 2012
I am an embedded engineer and it did add value to my knowledge base.Very crisp and neat.Looking forward for more such articles from you.Thanks :)
[ - ]
Comment by DeekshaJanuary 17, 2012
Thanks Karthik.Sins, this is my first blogpost ,so your comments are an encouragement.I plan to write another post catering to the details of operations required during a bootloader.And I hope to keep it as simple and uncomplicated.
[ - ]
Comment by karthik.sJanuary 17, 2012
Honestly,i never read such a nice article on bootloaders.Shows how much clarity you have on the subject.I wanted to get some tips on device drivers and such.Do you care to exchange information via emails?
[ - ]
Comment by DeekshaJanuary 19, 2012
@Karthik : What I'll suggest is for any information you require on device drivers ,you can start a thread in discussion groups on this site or discuss through comments..Information-sharing in this way is going to help other visitors also. @ImranM : Thanks!
[ - ]
Comment by karthik.sJanuary 19, 2012
I would like to know a good place to start learning about how to develop device drivers using C.There is a lot of information online but they did not help me so much in getting started.Any video tutorials or other such resources?
[ - ]
Comment by DeekshaJanuary 22, 2012
@Karthik : I don't know much about video tutorials,or online resources for that matter.I found a few books really helpful - one is "Designing Embedded Hardware" by O reilly.Hailing from computer background, this book helped me build concepts from hardware point of view. It will help understand the device for which you are writing a driver.For embedded programming in C, I think I referred to Programming Embedded systems by O reilly.You can also refer to example codes on your toolkit vendor's site for references.After this, the resources will vary according to your needs - whether its OSless or Linux device driver, the architecture is ARM based or not etc.
[ - ]
Comment by karthik.sJanuary 23, 2012
Thanks for the info.I did refer to those books in the past.To be precise,i want to start with developing device drivers on a linux box.
[ - ]
Comment by DeekshaJanuary 31, 2012
@Karthik : You can refer to Linux Device drivers (LDD3).E-book is easily available across the net.( i guess you might have gone through it by now)Also, a very good book is Embedded Linux Primer by Hallinan
[ - ]
Comment by karthik.sFebruary 1, 2012
Thanks :)
[ - ]
Comment by ImranMJanuary 18, 2012
Well written article.
[ - ]
Comment by sarankFebruary 4, 2012
I am using ARM9260 with IAR PowerPac RTOS, when I tried sending the serial data out, that I received in PC was bit shifted or corrupted. Without powerpac RTOS same serial port configuration works fine. Serial Configuration : 115200, N, 8, 1. Any idea about this issue? For example data send and receive 0x01 -> 0x03 0x02 -> 0x04 0x03 -> 0x07 0x04 -> 0x08 0x05 -> 0x0b 0x06 -> 0x0c 0x07 -> 0x0f 0x08 -> 0x10 0x80 -> 0x00 Always shift byte by 1 bit, but Whenever bit 1 is set, it shift data an bit 1 remain high.(0x01 -> 0x03) Also I tried with parity Even or ODD, at different BPS , but the data received is same Thanks
[ - ]
Comment by DeekshaFebruary 8, 2012
Hello Sarank, You can try checking the contents of the UART data register in case of your os-less driver and OS driver.In case of OS api, you can add a print just before the data gets written to the h/w register and compare it with the case of your os-less driver ( adding a print a step before the data is to be written to the register).If they are same, then you can check the uart config registers in both the cases at that point.Let know whether you find some clue here.Also, I guess you should post it in the discussion group for a complete discussion on it.
[ - ]
Comment by Harshal35September 21, 2012
Check in the oscilloscope, what difference you were getting.
you will have a clue from it.
I had similiar problem, which got solved by tuning baudrate. Compare EXACTLY bit width.
(but note that I was getting shifting of bits in only few characters....)
[ - ]
Comment by shabbirkhanJuly 1, 2012
thank you,it helped me a lot
[ - ]
Comment by Kannan43December 30, 2012
Looks good 4 me as a beginner in ARM , but i fount it bit similar to our conventional booting process in PC u've put "bootrom" in place of PC's BIOS, where two stage bootloading is involved, but in case of LPC Controllers they just have single bootloader in ROM(serial bootloader)for reprogramming the flash section,
[ - ]
Comment by Sagar9October 31, 2013
thank you for such a nice article. i am into the x86 from last two years and i always wanted to start with ARM architecture. This is really a very nice start to beginners .
[ - ]
Comment by anjisticJuly 15, 2014
Its a great place to start for a fresher on ARM booting process. Thanks a lot.
Even after 2 years, i couldn't find an article as good as this.
[ - ]
Comment by DMSeptember 29, 2014
Thanks anjistic :)
[ - ]
Comment by Matt40October 28, 2014
Thanks, good article.

-Matt
[ - ]
Comment by sonicreationsDecember 21, 2014
Hi Deeksha,
First of all I would like to congratulate you for your first blog,I am amazed to know the fact though as the article is quite informative and structured. I will wait for more from you side. Thanks for sharing !!
[ - ]
Comment by Hariprasad80December 16, 2015
I found it really helpful as I am a newbie to ARM. The content being very simple and neat I could understand it well.. Thanks Deeksha...
[ - ]
Comment by morkelMay 12, 2016
extremely helpful. please publish more similar posts in embedded systems field.

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: