what is the need of second stage boot loader ? why different bootloaders like first stage and second stage?

Question

I know the first stage boot loader will make basic hardware initializations and calls the second stage boot loader like u-boot. But I still do not understand for why we need multiple stages of boot loaders.

Why can't we have only one boot loader, where we flash a single image to initialize the hardware? What would be the disadvantages going with only one stage of boot-loaders loading the kernel image directly? to make it more clear am using ARM CORTEX A8 for beagle bone black where I place MLO,U boot and kernel image in a boot Portion,as far as my knowledge first stage boot loader initializes your external RAM, where U-boot is copied,which initializes some more peripherals,why I cannot go picking up the kernel image directly instead of second stage boot loader

Answer 1

There could be several reasons.

Maybe your platform has size restrictions on how large the bootloader can be? It's a tradeoff between time and flexibility. You'd want a very basic bootloader to load a more complex one.

For example, you might want to load your operating system from a filesystem. Code to handle a filesystem might not fit in your first bootloader but code to load a second bootloader does fit. You would put all your filesystem code in the second bootloader where you have more flexibility and get your first bootloader to load it instead.

The other reason is probably upgradability of the bootloader. Bootloaders aren't perfect and there could be bugs. You could have your first bootloader configured to load a second bootloader and maybe some recovery utilities. Then you could chuck the first bootloader onto a ROM and never touch it again. If you find a bug, you can just upgrade the second stage bootloader. If you brick your system, you still have the first bootloader for recovery.

This will also let you include new features into your second bootloader later if you wanted.

Answer 2

In the case of the AM3359 used in the Beaglebone Black, the first stage is actually being performed by the internal 64KiB boot ROM. Depending of the value being read from the SYSBOOT configuration bits, it will attempt to load the MLO from various possible sources and start executing it - see chapter 26 of the AM335x Technical Reference Manual.

From this point, if you don't want to use the de facto standard u-boot bootloader, nothing does prevent you to write your own equivalent of the MLO/u-boot-spl that would initialize the SDRAM and load the kernel, provided that both code and data would fit in the internal 128KiB SRAM.

This can probably be done by re-using the minimal amount of u-boot code required to do so,or if this is still too much code, by writing functionnaly equivalent code in C using the AM3359 Starterware library, or ultimately in ARM assembly code if desesperately needed.

Using the thumb2 instruction set would help reducing further the size of this bootloader.

But because this would require a lot of time, most people find more convenient to reuse the excellent u-boot bootloader, even though it has to be split into MLO/u-boot-spl and u-boot parts in order to be usable on the AM3359 and its 128KiB internal SRAM.

In conclusion, you are right, having a three stages boot process (boot ROM+MLO+u-boot) on the Beaglebone Black is not a technical constraint - two (boot ROM + MLO) could be enough, if you can afford the luxury of not re-using existing, proven, free and widely used bootloader code.