I wonder what kind of "license issues" are present in the current software?
"U-boot/Kernel/Linux source code will be released 15-Dec-2014. Android source code will be published in February after cleaning some license issues."
Looks like the biggest problem with most of these ARM boards (raspberry pi included) is the dependency on some closed-source binary blobs, at least for boot, and sometimes even the entire kernel is a closed branch off some old release.
I've never dealt with an ARM core that needed some magic object-only blob to boot. They're almost all using Denx U-Boot.
If the GPU needs an object loaded to boot, like the RPi, that's another story. But a decent SoC should be able to start without the GPU getting in the way.
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.
"U-boot/Kernel/Linux source code will be released 15-Dec-2014. Android source code will be published in February after cleaning some license issues."
Looks like the biggest problem with most of these ARM boards (raspberry pi included) is the dependency on some closed-source binary blobs, at least for boot, and sometimes even the entire kernel is a closed branch off some old release.