Hardware Reference
In-Depth Information
•
The third mode should be all too familiar to everyone. This is the shutdown mode. In this
mode there is no power. The best example of this power mode is that you have pulled the
power cable.
•
The last power mode is the dormant mode. In this mode the core is powered down and all
caches are left powered on. This mode is only partiality supported in the ARM1176JZF-S core
at the moment and I do not suggest you use it.
Performance per Watt
So what's with the block diagram before? Well, now that you know all the detail and effort that has gone into the
ARM11 processor you can look back at the block diagram and appreciate that while the Raspberry Pi is a very cheap
system this CPU is no toy. For the performance and feature set per watt the ARM11 is nothing short of amazing.
Performance per watt is king in major data centers now.
So the next time you hear someone complain “oh, it's only 700 MHz!” you can retort with “Why, the ARM11's
700 MHz will handle a whole lot more than you think it can.” Now that you understand the architecture you can make
better use of it. You can use the additional instructions or you can rely on the ARM11 to act in a certain way. Go forth
and optimize your code and your hardware around this amazingly cheap SoC device.
There is always a negative to every positive. One unusable function at the moment on the ARM1176JZF-S is the
dedicated DSP core: currently there is no publicly documented API to access this core inside the ARM11 CPU, and this
is unfortunate because our media projects could have made good use of this core.
Pi Eyes
I have talked about the AMR11 side of the Broadcom BCM2835. Now let's talk about the Broadcom VideoCore IV
side of the SoC. This part of the Broadcom BCM2835 is protected by non-disclosure agreements, making it hard for
the open source community to optimize its code and better utilize the VideoCore. This all comes back to the fact
that the driver is supplied as a binary blob. For example, if the VideoCore code were open source it would be allowed
into the Linux kernel, or end users could patch and fix bugs that they come across. Given that the VideoCore's main
audience is the highly competitive mobile phone market it's no surprise that there is an NDA on the design and on
the APIs for this part of the Broadcom BCM2835. What we do know is that the VideoCore can in fact run by itself and
execute limited amounts of ARM code at the moment. Normally the VideoCore chip is paired with an ARM processor
and is just used to accelerate media playback and capture, as is the case with our Pi. The VideoCore supports 1080p
playback and should be able to handle all of our playback requirements quite nicely. You can set how much memory
is assigned as video memory (also known as VRAM) by using different executable and linkable file formats. These files
will have the extension of elf boot files.
The foundation provides three elf files to boot the Raspberry Pi: they control the system/VRAM split. They
are
arm128_start.elf
,
arm192_start.elf
, and
arm224_start.elf
. The number in each of the file names
determines how much system memory you have, and whatever is left is allocated to the VRAM. So in the case of
arm128_start.elf
you have 128 MB of system memory and 128 MB of VRAM. This file needs to be copied to
/boot
and must be called
start.elf
, otherwise the GPU will not read it when the system starts and your whole system will
fail to boot.
Hang on, you said the GPU reads that? This seems a little confusing: why is the GPU reading a boot file?
Remember when I talked about how the VideoCore GPU can run code? Well, the Raspberry Pi uses the GPU to
initialize the SD card slot and read the
config.txt
and
start.elf
files from the SD card. It then hands off the boot
process to the CPU.
