While there is no open source driver for Mali400 available, it has been partially reverse-engineered (lima). For the VideoCore IV there is an open source driver available, but the SoC on the RPi is special in the sense that when booting the VideoCore IV is the core to start, which later in the boot process starts the ARM core(s). On the VideoCore IV there runs a proprietary OS (probably RTOS) that is based on ThreadX. So most things the open source driver does are simply calls to this RTOS via a mailbox.
Nevertheless the RPI developers market the VideoCore IV GPU as the most open embedded GPU available. Indeed it is the only one, where an official open source driver is available and thus it is more friendly towards bare-metal programmers that want to write their own OS. On the other hand, the RTOS running on the VideoCore IV is a large blob in an instruction set that has not yet been deciphered.
That's not quite accurate anymore - there's an open-source OpenGL ES driver for the Pi that isn't just a wrapper around the binary blob on the VPU. However, you still need the proprietary blob in order to boot the Pi and actually enable the display outputs, and for accelerated video decoding. (Oh, and it has an interesting license that forbids you from using it on non-Raspberry Pi hardware.) On the Allwinner chips, it's the other way around - you can boot them, enable the display outputs and do modesetting and I think even hardware video decoding with open-source code, but OpenGL ES requires a proprietary blob. Though I think the Allwinner 2D graphics overlay hardware is fully documented, which may be enough for some applications.
>> Oh, and it has an interesting license that forbids you from using it on non-Raspberry Pi hardware.
Does that mean you can't use the Pi as a dev board for the SoC and then build a product based on that? Or I suppose you'd license the video driver when you go to buy the SoC for production?
It does, but chances are Broadcom won't sell you the SoC either so it matters less than you think. I expect it's mostly just aimed at anyone who attempts to re-purpose existing hardware based on the same Broadcom SoC.
First: What I wrote it only for the GPU, since you only asked about that part. I wrote nothing about the other parts of the SoC or Raspbian, though there are lots of things to say, for example:
No public documentation (without NDA) is available for the USB controller of the RPi (there is still an open source driver in the Linux kernel for it that is based on this non-public datasheets) made by Broadcom. I personally consider the action that the Linux developers also include drivers based on secret datasheets into the kernel as a violation of the spirit of open source, but I digress.
Also the Raspbian developers (from the Raspberry Pi foundation) include proprietary software into Raspbian, say, Mathematica. While probably useful, this surely isn't open source.
So there are more criteria on which to judge a SoC than whether it is open source, say, whether there are complete and free datasheets (no NDA) available or whether the SoC is also available in small amounts for hackers (Broadcom is said to be very compicated in this area). Or how much open-source the de-facto standard GNU/Linux distribution (since this is what you'll probably want to use) for the SoC is.
TLDR: Openness or open-sourceness is much more complicated.
Thanks again! Actually I asked about the size of the whole blob you mentioned to get some idea how hard would it be to disassemble it fully. What do you think?
It's a bootcode.bin which runs a simple shell via a serial terminal which allows you to do things like up and download data, examine memory, etc. No ARM code involved anywhere! It doesn't initialise the SDRAM yet (although I think I know how).
Right now it's built using a hacky port of the Amsterdam Compiler Kit, which generates lousy code. I've tried porting both gcc and LLVM and ran into a brick wall --- they're both vile. I'm hopefully going to have a go with libfirm soon, which looks more tractable. However, Volker Barthelmann's non-open-source vbcc has experimental (and apparently very good) VC4 support: http://www.compilers.de/vbcc.html
Where did you/they get the information on the VC4 instruction set from? According to some sources about reverse-engineering VC4 which I could recover if I wanted to, finding out the instruction set that the blob uses was a serious problem at least in the past.
I believe it was figured out from a combination of analysis of the blob, examining the patents (which contain quite a lot of information), trial-and-error, and careful examination of the fragments of VC4 source released by Broadcom (their big source release a year or so back contained quite a lot). I know that at least one person wrote a program which would run arbitrary instructions on the Pi and analyse the state of the registers afterwards, which is a neat trick.
The VC4 is a really nice processor, BTW. Dual core, lots of registers, efficient instruction packing, 64x64x8bit vector unit, integrated single-precision FPU using the integer registers (no double-precision, alas), 1kB on-chip lookup table... but, bizarrely, no adc or sbc instructions, so 64-bit arithmetic is hard. Very weird.
