Hardware Reference
In-Depth Information
What Happens at Power On?
This may seem a little out of place compared to the rest of the topics but given the Raspberry Pi's unique hardware
and odd boot sequence it seems very fitting. You may have noticed that there was no BIOS screen when you first
powered on the Raspberry Pi. That's because the Raspberry Pi has a very strange way of running the power-on self-
tests (POSTs). I am going to give you a quick overview of exactly how the Pi performs POSTs.
The following occurs in order once power is applied to the Raspberry Pi. The example will use Linux as the
operating system but the concept applies to all operating systems booted on the Raspberry Pi. Step 1 assumes that you
have just plugged in the power.
1.
The ARM core is not running, SDRAM access is disabled, and the GPU is on.
2.
The GPU starts executing the first-stage boot loader that is stored inside the SoC package.
This first-stage boot loader is programed into the SoC and cannot be edited or changed.
3.
The first-stage boot loader reads the second-stage boot loader into the L2 cache that's
mapped to the GPU: this is also known as the
bootcode.bin
.
The
bootcode.bin
enables access to the SDRAM. The
bootcode.bin
then loads the third-
stage bootloader, known as
loader.bin
. This is loaded from the SD card into the SDRAM.
4.
The
loader.bin
then reads the
start.elf
file from the SD card.
5.
The
start.elf
file then reads the
config.txt
,
cmdline.txt
, and the Linux
kernel.img
files from the first partition on the SD card.
6.
7.
The boot process is handed over to the Linux kernel.
The files mentioned in this boot process can be obtained from the foundation's GitHub site. The files can be obtained
for no cost and are licensed under the Broadcom Corporation license; please take a moment to read this license.
Also keep in mind that the Raspberry Pi can boot from only an SD card. The Linux kernel and the boot files that
I listed must be present on the SD card and not on an external drive.
Pi on Your Face
If all this sounds too good to be true, then some of it is. I am personally a big supporter of open source software
and hardware. Everything used to write this topic was performed with open source applications and open source
operating systems. I also would love to see hardware be more open but given how competitive some markets are
I cannot see this ever changing.
This is unfortunate and will somewhat limit us now and in the future if documents and APIs are never available
to the public. For example, to boot the Raspberry Pi we use a premade binary file that is placed on the SD card. End
users have no way to re-create this or change anything about it if they encounter a bug with it. If these files were to all
of a sudden stop working, the hardware we have would be rendered totally useless.
The Raspberry Pi also needs the binary blob file in order to drive the functions of the GPU; this has the
unfortunate effect of locking us out of the CSI and DSI buses. As end users, we cannot currently make use of them:
the foundation is hoping to provide us with a way to get access to the buses at a later stage. For the moment, don't
consider the CSI and DSI interfaces a selling point.
You will also notice the clear lack of any onboard battery or anywhere to set the date and time like you do on
your normal PC. The foundation expects that the Raspberry Pi will use NTP for the Model B and that the time will be
set manually on the Model A on each boot of the device. This is a little inconvenient but it makes perfect sense when
you think about the PCB space and component cost that would make up the real-time clock (RTC). This would have
pushed the cost and the size of the Raspberry Pi well above what it is now.
