5

According to the answers to this question and other sources, the GPU of the Raspberry Pi's BCM2835 SoC is responsible for the first stages of the boot process, including enabling the ARM CPU. Until Broadcom open-sourced the GPU drivers, this was an issue for the open-source community, because it required a closed-source binary-blob to boot.

Why would the designers choose to implement the SoC like this, rather than having the main CPU control the whole process like in a Intel PC?

  • 1
    On a PC, it's the chipset that does the initialization (-: – Gerben Mar 31 '14 at 14:28
  • 2
    I don't think that's true. According to this (en.wikipedia.org/w/…), at boot an Intel processor will start executing code at a hardcoded memory location, which is where the BIOS program is placed on a PC. The BIOS program (executed by the processor) does the initialization. – Kaypro II Mar 31 '14 at 19:39
3

The GPU is the main processor :) The ARM CPU is an addition to the GPU but the SoC is like a BIOS/EFI on standard PC computers.

SoC - System on Chip

The SoC binary is possible closed source because it might reveal allot of technological patents to do with the technology it self. So Broadcom most likely don't just want to open source it to everybody to reuse. It has no impact on the usability of the Pi any way, just like it doesn't matter what kind of BIOS you have in your PC.

The SoC initializes and test "its basic stuff" and passes control over to the GPU, which initializes the graphics engine and RAM allocation GPU/CPU (Because it makes sense the GPU has direct access to RAM for speed optimization) This is were the API also initializes and only selected people can view the source to develop drivers and interfaces.I think only some of the API sub code has been made open source, since its used across the world, in mobile devices - So letting the community play with code will only create more apps that run on this API "OpenGL ES". They most likely hide specific code in other binaries to protect intellectual property.

Then the CPU starts and loads the Operating System, and here the user has full choice over the what he want to load there, and it work as long as it has the drivers and is capable of running on ARM architecture.

  • 1
    I'm not really following your answer. You appear to be using "SoC" to refer to a distinct component of the chip, but my understanding is that "SoC" refers to chips that integrate several distinct components (e.g. CPU, GPU, memory) into one package that were once typically in separate packages. Broadcom has also recently open-sourced the GPU firmware (see the link in my question). The question I want answered is "Why have the GPU control the first stages of the boot process?" – Kaypro II Mar 31 '14 at 19:29
  • I refer to SoC in an abstract element. All SoC means is that you can flash it with a system and it can run standalone. You can even write your own SoC code for your own application. You can get chips like this that are not SoC and you need to use and MCU to work with it. The reason GPU starts first, is simply because the BCM2835 is a GPU. Not an CPU or MCU. You can get Wireless chips like the TI CC235 that is SoC. So you write the code in the way you need to interface with it. The same chip but older package isn't SoC and you must write the code an a dedicated MCU. – Piotr Kula Mar 31 '14 at 19:36
  • You can run the BCM2835 without ever initialises the ARM CPU, if you just need it to transcode video or use the HDMI capabilities to render x264 bits streams or other compatible bit streams. But you need to write your own SoC firmware in order to create your own interface for that. The Pi firmware is designed to use the chip with ALL its features.A satellite tuner might use the chip in such a way, since video from sats/digital TV is MPEG. They might even use the GPU purely for GUI and never use the ARM. If the price is right, the vendor will do that. – Piotr Kula Mar 31 '14 at 19:38
  • 1
    Essentially, the BCM2835 predecessors might have started out as a GPU only until they figured out how to attach an ARM CPU. Since the GPU already works there is not much reason to redesign the silicon die complete, just create a way for the CPU to interface with the GPU. The other reasons, like I mentioned is that the GPU directly accesses the RAM for low latency. You should visit some sites and read about other GPU/CPU and see how the firmware and boot loaders work. – Piotr Kula Mar 31 '14 at 19:45
1

The GPU copies a 32K block to the L2 cache and executes it. It saves the cost of a CPU BIOS chip - the 32K code loads it from an SD card The reference manual doesn't say if that 32K is rewritable. If it is, cross-compiling & real-time debugging with profiling and watch-windows would be fast. PDS,SNASM & SN systems are good examples. Trustzone could be used to catch errors.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.