4 years ago

Boot Loader 101

Bootloader is a piece of software important to an embedded system

The following write up will explain the basic concepts of boot loader all in one page

Since this is a 101 to boot loader,It will merely give you an overview on boot loaders.

What is a BOOT LOADER?

  • The first and foremost would be to understand what the boot loader is. A boot loader is a piece of software like any other software module with an intended purpose. This piece of software in particular is used at the start-up of any computing or embedded device. It plays a vital role in the booting up of the entire system. It is used for other purposes which will be discussed in the course of this post.
  • The boot loader is primarily used for boot strapping. This term is a commonly used term to identify the process of booting in a computer device (Just take this definition at phase value; as this concept is quite detailed in itself).
  • The firmware; in a nutshell is again a piece of software that communicates with the hardware peripherals telling them how to work and communicate with its surroundings. This would be the top level definition and it is primarily stored in the flash ROM of the device. The firmware is usually among the first software components that start running and depending on the architecture of the system; the firmware will find a way to transfer control to the boot loader.

Where exactly does a BL sit?

  • The boot loader can be stored in different parts of the memory; it can either have a dedicated section of the memory for its components or it can be stored in the first address space of the memory. This is entirely up to the system architect to place it an appropriate place.  The only thing that really matters is, in what sequence this piece of software is invoked and what responsibilities it holds at that instance of time.
  • There is also a concept of multi-stage boot loader; wherein the most critical section of the BL is stored in the main memory. The remaining is made to be fetched in run time from other parts of the memory. This may be used in cases where a more complex boot loader is to be designed and the space it consumes is more than dispensable flash or RAM memory.

Let us look further into embedded boot loaders..

  • The first and foremost concept to understand would be; the dedicated role of an embedded boot loader is versatile. Its primary purpose in an embedded system is largely dependent on the nature and use cases of the product itself. This would be the first thing to keep in mind before diving deeper into the subject. Like any other blog or article you read on boot loader; it is a vast topic; but a generic overview is a good thing to have before diving deeper into the subject.
  • Let’s look at this logically; in an embedded system where the hardware peripherals and the software components interact with each other; it is imperative that there is a sequence for things to start up and the entire system to be synchronous. Usually; the BL takes the responsibility to initialize all the hardware peripherals, registers and in general get the system to a state after which the init code (main function) of the developer can start to execute. Note in Embedded Systems; the BL is not the same as the operating System; if the system has an OS the BL starts up even before the OS initializes.  In this context OS is referred to as the kernel init. Depending on the nature of the kernel and RTOS used; the system can be using a monolithic kernel, a micro kernel a hybrid or any one of the other types available. The baton is handed to the kernel init after BL initializes whatever it has to, as mentioned earlier. This is typically how an industry grade Embedded system would start up; with a few exceptions of course.
  • Typically the complexity of the BL is dependent on the use for it in the entire system. It can be as simple as a piece of code that brings the system up and start executing the user code; to a multi layered code that takes the user input to perform the next step.
  • At this point; it would also make sense to talk about something called the BOOT Manager; this term is used quite liberally because of the versatile nature of the boot loader itself. But to explain; the boot manager decides whether to continue to stay in BL mode of operations or to jump into the application space. This code is usually embedded along with the BL itself; this BM concept simply gives the user, a control on what needs to happen. Most often the boot loader is often referred to as the boot manager.
  • The boot loader is critical in many aspects which will be discussed further and hence there is a need to protect it from rest of the software components. The system architect usually employs the concepts of MPU (Memory Protection Units); the BL would be placed in parts of the MPU wherein not every component has access to modify this part of the memory. It is still very much possible that this is corrupted by a simple overflow; but it is usually protected and restrictive in the access. The application layer need not be bothered by such low layer software component and hence need have direct access to this. Concepts like this are in place to avoid unnecessary corruptions of the BL and to ensure a more robust and secure software architecture.  
  • Few applications and uses of the BL will be
    • To update the system (Firmware Update).
    • To check the software that is flashed into the system (Flash).
    • Error Handling in case of a system update.
    • Booting as discussed earlier.
    • To initialize RAM and Flash.
    • Initialize the GPIOs (Also part of booting; mostly).
    • Moving the kernel to RAM.
    • A few more depending on the system architect and the need.
  • Although the boot loader is known to do a lot of things; the main and most critical role it plays in an embedded system is to facilitate software upgrade and system init.

Concepts of using the BL for software update

  • The BL is usually the only software module that is open to receiving any software components from the external world.
  • This can be via any protocol from CAN, LIN to Ethernet, USB or SPI. (In case you are not aware of these communication protocols; I can write up another post specifically focusing on this.)
  • This provision eliminates an appropriate JTAG programmer to be hooked into the micro controller sitting inside the system. Once the product is out in the market; it is impossible for a technician to carry around a JTAG programmer to his customers.
  • The boot loader checks for the firmware version each time it boots up. If there is a trigger for newer software or for existing software in the memory for flashing; then it will reflash the newer program before jumping into the application space. The majority of the steps mentioned would be strictly dependent on the architects of the system .There is no right way to do this; it’s just the best way to do it given the system and the constraints it brings (ex-Memory, size of SW, etc.).
  • The newer data can be flashed as and when it comes into the system or it can be stored in a place at the memory and then flashed from there. This is again entirely dependent on how the system functions or the requirement as such.
  • It is utmost critical that the BL of the system should not be corrupted while this software upgrade is happening; to ensure this the architects take a backup of the BL image and SW image before  the update so as to revert to the original version if so it has to fail due to any number of reasons. This is the usual procedure any system designer would keep in mind while devising the use case of Remote Software Upgrade.

The basic detrimental factors while deciding or designing of your own boot loader

  • The layout of the systems memory map. As mentioned earlier; it is imperative to have a good visual image of the memory map of one’s embedded system. In the memory map, one needs to allocate a specific memory location for the BL and the rest for the application.
  • This obviously follows the linker scripts; which tells your c compiler on where to find the definitions for your BL bring up.
  • Determine if there is a necessity for a Reset Handler. Again, reset handler is a piece of code that has numerous functionalities; depending on how it is used and programmed. It typically ensures to init the static and global variables at start up before passing on the functionality to the ‘c’ main function. The design of the reset handler is taken into consideration while the BL is designed. (Again this 101; so let’s not get into these details).

Hope this write up gives you a clue on what the functionalities of a boot loader are on a high level. Feel free to write to me in case of any queries.

Written by BootUP

A Technology enthusiast eager to learn and teach!

Categories Technical ContentTags

Comments are closed.

9 Thoughts on “Boot Loader 101”

  1. This blog about BL is great for beginners as it has a good blend of generic and technical attributes. And YES, would love to read about communication protocols!

  2. The information on bootloader is very intuitive and better understanding for the novice..
    Keep guiding with more contents…

  3. Plz take us through a virtual tour of a Car transitioning from an Idle condition to a Running condition in layman’s understanding