Raspberry Pi boot process


9 posts
by mdr86 » Sun May 27, 2012 2:40 pm
I've been trying to make sure I properly understand the Raspberry Pi boot process. What I understand so far, mostly from the config.txt thread, is this:

  • When the Raspberry Pi is first turned on, the ARM core is off, and the GPU core is on. At this point the SDRAM is disabled.
  • The GPU starts executing the first stage bootloader, which is stored in ROM on the SoC. The first stage bootloader reads the SD card, and loads the second stage bootloader (bootcode.bin) into the L2 cache, and runs it.
  • bootcode.bin enables SDRAM, and reads the third stage bootloader (loader.bin) from the SD card into RAM, and runs it.
  • loader.bin reads the GPU firmware (start.elf).
  • Not 100% sure what happens next

I have a few questions: is this all correct? If so, what loads kernel.img, cmdline.txt and config.txt - loader.bin or start.elf? What else do the different stages do that I've missed?

Thanks!
Posts: 7
Joined: Tue Dec 27, 2011 10:46 am
by dom » Sun May 27, 2012 2:53 pm
All you have written is correct.
start.elf reads config.txt, cmdline.txt and kernel.img

loader.bin doesn't do much. It can handle elf files, and so is needed to load start.elf at the top of memory (ARM uses SDRAM from address zero).
There is a plan to add elf loading support to bootcode.bin, which would make loader.bin unnecessary, but it's a low priority (I guess it might save you 100ms on boot).
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4105
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by dwelch67 » Sun May 27, 2012 2:55 pm
From what I understand and have confirmed the GPU then loads kernel.img, a binary image of ARM memory starting at physical address 0 from the ARM's perspective. And releases reset on the ARM.

The downloads have a kernel.img which is basically linux, so there is a branch to 0x8000 (typical for linux) and it goes from there, also the reason for the filename I would assume. You dont have to have it branch to 0x8000, at least so far I have not had any problems using the ARM memory space. My hope/guess is the other files are read by the ARM linux or bootloader and used to adjust the boot process. It is certainly possible that the GPU reads those files and modifies the ARM memory space before releasing reset on the ARM, but so far I have not had any collisions with modified memory.

See http://github.com/dwelch67/raspberrypi for some bare metal ARM programs.
Posts: 438
Joined: Sat May 26, 2012 5:32 pm
by AndrewS » Sun May 27, 2012 3:33 pm
dwelch67 wrote:My hope/guess is the other files are read by the ARM linux or bootloader and used to adjust the boot process. It is certainly possible that the GPU reads those files and modifies the ARM memory space before releasing reset on the ARM, but so far I have not had any collisions with modified memory.

It's mostly over my head, but I believe this kind of low-level stuff is explained in e.g. https://github.com/raspberrypi/firmware/issues/22 and https://github.com/raspberrypi/linux/issues/16 :?:
User avatar
Posts: 3626
Joined: Sun Apr 22, 2012 4:50 pm
Location: Cambridge, UK
by DexOS » Sun May 27, 2012 5:04 pm
dwelch67 wrote:From what I understand and have confirmed the GPU then loads kernel.img, a binary image of ARM memory starting at physical address 0 from the ARM's perspective. And releases reset on the ARM.

The downloads have a kernel.img which is basically linux, so there is a branch to 0x8000 (typical for linux) and it goes from there, also the reason for the filename I would assume. You dont have to have it branch to 0x8000, at least so far I have not had any problems using the ARM memory space. My hope/guess is the other files are read by the ARM linux or bootloader and used to adjust the boot process. It is certainly possible that the GPU reads those files and modifies the ARM memory space before releasing reset on the ARM, but so far I have not had any collisions with modified memory.

See http://github.com/dwelch67/raspberrypi for some bare metal ARM programs.

I like you am unsure if the 0x8000 is needed, but i have read about problem when you come to use GPU without it.
Batteries not included, Some assembly required.
User avatar
Posts: 869
Joined: Wed May 16, 2012 6:32 pm
by mdr86 » Thu May 31, 2012 12:14 pm
Re the 0x8000 thing - I believe the contents of cmdline.txt is loaded in the section between 0x0000 and 0x8000 (specifically, at 0x100). If you don't have a cmdline.txt, that's probably why it's been working! I don't know if anything else is written in that area though.

Another boot process question from me: Presumably bootcode.bin, loader.bin and start.elf are all closed source (as they all run on the proprietary GPU RISC core)? (And then everything else open source?)
Posts: 7
Joined: Tue Dec 27, 2011 10:46 am
by AndrewS » Thu May 31, 2012 5:43 pm
mdr86 wrote:Another boot process question from me: Presumably bootcode.bin, loader.bin and start.elf are all closed source (as they all run on the proprietary GPU RISC core)? (And then everything else open source?)

Yup :)
https://github.com/raspberrypi/firmware
User avatar
Posts: 3626
Joined: Sun Apr 22, 2012 4:50 pm
Location: Cambridge, UK
by tufty » Thu May 31, 2012 7:27 pm
mdr86 wrote:Re the 0x8000 thing - I believe the contents of cmdline.txt is loaded in the section between 0x0000 and 0x8000 (specifically, at 0x100). If you don't have a cmdline.txt, that's probably why it's been working! I don't know if anything else is written in that area though.

It's a bit more than that, or at least should be. There should be a bunch of atags describing, amongst other things, the memory you have to play with, plus the commandline. These can go up to, but no further than, 0x4000. Space from 0x4000 to 0x8000 is used /by linux only/ for its initial mmu mapping page.

So.

From 0x4000 onwards, you are guaranteed safe. With the atags turned off in config.txt, it's all yours, but you need another way of working out how much memory you have.

A description of linux/arm booting in general, with acdetailed description of atag format, can be found here : http://www.simtec.co.uk/products/SWLINU ... ticle.html

Simon
Posts: 1376
Joined: Sun Sep 11, 2011 2:32 pm
by ACP_ » Sun Nov 25, 2012 11:26 pm
Apparently with recent firmware revisions the loader.bin has been removed and I'm guessing from previous posts that its functionality has been integrated into bootcode.bin.

Here is the link to the git repository if anyone is willing to take a peek into it:
https://github.com/raspberrypi/firmware/commit/1a7fbe8113ffadfde24863f6fcb50ff8be9265c6#boot
Posts: 33
Joined: Sat Aug 18, 2012 10:40 pm