It's really not quite fair to describe videocore as a GPU, it's a proprietary SIMD DSP architecture with a really awesome 2D register file.
I've joked before that the arm core on the rpi is really just there for power management ... and considering its share of the transistor budget, that joke almost sounds credible.
Correct. But this is just the first stage bootloader; the GPU boot ROM loads a second stage loader from the SD card, which then loads the kernel and launches the ARM straight into it. None of this is encrypted or signed as is usual on Android devices.
The license conditions do, however, forbid you from using the first-stage bootloader on anything other a Raspberry Pi. That is, if you somehow manage to get hold of another board with the same Broadcom SoC that's somehow compatible with the bootloader, you're not allowed to boot that with it.
The Raspberry Pi GPU has been fully and openly documented now, so it should in theory be possible to boot it without a binary blob. You just have to reimplement enough of the graphics stack to make the CPU happy (?)
While your avoidance is understandable, given Broadcom's thoroughly disreputable history with regard to free software, it's not justified in this case. The Pi GPU is apparently fully enough documented that you can write your own software for it.
I could care less about the state of the GPU driver source and the typical complaints of RPi developers. Open, closed, whatever.
I'm more skeptical of a SoC architecture that has the CPU dependent on the GPU for its startup sequence. Or is this a matter of the GPU controlling the ARM's clock tree?
Most "bigger" SoCs have a secondary processor for SoC bringup/boot. (It's not uncommon to see a tiny ARM7 or something in this role). Since Broadcom succeeded in making a particularly general purpose core for their GPU (it seems that the GPU runs a full RTOS written in C), it only makes sense (well, to me at least) that it could take over that role as well to save on the transistor budget.
