Raspberry Pi boot process

[mdr86]

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!

[dom]

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).

[dwelch67]

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.

[AndrewS]

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

[DexOS]

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.

[mdr86]

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?)

[AndrewS]

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

[tufty]

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

[ACP_]

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 ... 265c6#boot

[MADSAM]

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 . 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

[ghans]

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

[MADSAM]

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.

[Heater]

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.