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?
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.
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.
The Raspberry Pi boot process begins with the GPU (Graphics Processing Unit) rather than the CPU (Central Processing Unit) because the GPU is responsible for initializing and configuring the system before the CPU takes over.
The GPU is also responsible for loading the firmware and bootloader, which are then used to boot the operating system and hand over control to the CPU. This allows the Raspberry Pi to boot quickly and efficiently, as the GPU can perform many tasks in parallel while the CPU is still starting up.
The concept of the GPU initializing and configuring the system before the CPU takes over in the Raspberry Pi boot process is similar to the idea of parallel computing.
In parallel computing, multiple tasks are executed simultaneously on different processors or cores in order to speed up the overall computation.
In the case of the Raspberry Pi, the GPU can perform many tasks simultaneously while the CPU is still starting up.
For example, the GPU can initialize the memory, configure the peripherals, load the firmware and bootloader, and display the boot messages on the screen, all at the same time. This allows the Raspberry Pi to boot quickly and efficiently.
In general, GPUs are designed to handle many tasks simultaneously, this is why they are commonly used for parallel computing tasks such as scientific simulations, machine learning, and image and video processing.
