How does Raspberry Pi's boot loader work?

Question

Recently I started to study about Embedded System and Embedded Linux. I know that in an embedded system, the operating system is stored on Flash or ROM. When it's turned on, the bootloader loads the operating system into main memory, and with a Raspberry Pi, that “flash or ROM” is an SD card.

So, I was searching for Raspberry Pi because I want to start practicing with one, and I was confused about concept of “booting” a Raspberry Pi. My question is what bootloader does Raspberry Pi use and how does it work? (Namely, what processes occur before the kernel? head.o? main.c? (start kernel))

Answer 1

This process has been described to death, you should have had no problems finding it on the net.

The raspberry pi contains a GPU and an ARM processor, two separate processors. The GPU comes up first, I assume driven by an on chip rom or hardware that reads the sd card looking for the first boot file bootcode.bin. That GPU bootloader is undocumented as far as we are concerned, it brings up the chip to a point, and then loads start.elf another GPU program. That gpu program finishes up bringing up the chip (ddr init) and eventually loads kernel.img which is the ARM application (not arm bootloader but application as in linux), it loads that directly into ram and does what a normal bootloader would do to prepare the arm to boot linux (which is generally almost nothing) and then the arm boots.

A traditional bootloader is when you have only one processor and that is the processor that will also run the application/operating system. names like redboot and uboot, but these have become grossly overcomplicated, operating systems themselves. it takes very little to boot linux, put a few ATAGs in ram and set a couple of registers and that is it (after of course you have brought up the system/ram, etc which doesnt take too much code, but is delecate/difficult code for ddr for example), the newer linuxes have a bit more stuff to setup but not too much.

The raspberry pi startup is elegant in its simplicity as well as the feature of removable non volatile storage (the sd card), which takes you way back to the pre-bootloader days where you would pop the roms off and erase them, it has some of those pains, but there are ways around that. by now there are likely third party complicated (uboot, etc) bootloaders available. Having the removable flash means you dont need a complcated bootloader, you dont have to worry about bricking the system with a broken application, you can recover by simply removing the flash and changing it. Bootloaders have grown up from avoiding removing the media to avoiding having to unsolder a flash and resolder after programming or using a socket on a board destined to have a soldered down part.

The kernel.img as it stands now (at one point it was loaded to 0x00000000) loads to 0x8000. And that is about all you need to know, it is a normal kernal image you would use with a bootloader. You can then write whatever bare metal or other program/application you want so long as you link it for address 0x8000 as the beginning of the binary and the start point. If you want to use exceptions you need to then write the exception table somehow (There are various ways to do this). An alternative to this is there is a legacy mode setting you can use an optional file config.txt to configure and that will load the kernel.img to 0x0000 like the early days of the rpi. Personally I go with the now default 0x8000, other bare metal folks take the other path...

I have a very simple xmodem bootloader and one that sets up the jtag pins so you can use jtag (both cases to avoid having to do the sd card dance hundreds to thousands of times as you develop your application). There are others, some more complicated, perhaps even one that has the usb up to the point the network works.