Raspberry Pi boot process


13 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: 8
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: 4865
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: 638
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: 3625
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: 876
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: 8
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: 3625
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: 1421
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
by MADSAM » Mon Jul 25, 2016 8:34 pm
I don't believe that is the truth, i think they are lieing about the whole boot process. it has to do something with the sd card and the rom. their has got to be some thing stored on the rom that flips a bit on the sd cards possessor (yes the sd card literally has a possessor on it) and the sd card then sends those restricting .bin and .elf files to the cpu and it then tells the prossessor to read the kernel. I am trying to make a REAL bare metal program from scratch (not from that program), not their stupid arm functions. the sd card also uses the FAT file system just like windows :lol: . and i am currently trying to read the raw binary stored on it. if only it was easy as reading and accessing a floppy.

anyway watch the video on this website it will help you out of a lot of frustrating bull@#$% that makes you want to tear out your eyes and feed em to the dog... https://www.bunniestudios.com/blog/?p=3554
Posts: 2
Joined: Sun Jul 24, 2016 4:55 pm
by ghans » Mon Jul 25, 2016 9:50 pm
The facts that SD cards contain microcontrollers
and normally "invisible" secret firmware does not contradict the
first two posts of this thread. Note that on the Pi , the
secret "GPU" (VPU) does indeed boot first from a inbuilt
bootrom only to load more secret VPU code from the SD
card.

ghans
• Don't like the board ? Missing features ? Change to the prosilver theme ! You can find it in your settings.
• Don't like to search the forum BEFORE posting 'cos it's useless ? Try googling : yoursearchtermshere site:raspberrypi.org
Posts: 6795
Joined: Mon Dec 12, 2011 8:30 pm
Location: Germany
by MADSAM » Sun Jul 31, 2016 12:54 pm
I guess ill have to find where they are starting at memory. is there some kind of device that like, reads data from sd card as it is being booted with the pi. i know it is possible. sorry i know this is someone elses thread but im just tired of looking, literaly been looking all summer. :|
Posts: 2
Joined: Sun Jul 24, 2016 4:55 pm
by Heater » Sun Jul 31, 2016 1:50 pm
MADSAM,

Where do you get all that nonsense from?

Sure SD cards have processors, we all know that.

Sure some people of hacked them. So?

The SD card does not use FAT. The SD card, like floppy disks or any other media knows nothing of file systems, it only knows about blocks to be stored and retrieved.

Reading and writing an SD card is much easier than those old floppy drives. I can do it from a micro-controller and a few dozen lines of code. I have done that to implement a CP/M file system on SD for a Z80 emulator running on a micro-controller. http://hackaday.com/2009/12/27/zilog-in-a-matchbox/

If you really want to check what happens between the Pi and the SD card at boot get yourself an FPGA board or a micro-controller. Hook a few of it's pins to the SD card lines and sniff what happens.

Do report back if you find anything untoward.
Posts: 5208
Joined: Tue Jul 17, 2012 3:02 pm