Well, seems they might make margin on accessory and postage etc, however, the math seems pretty clear -- they /can't/ sell it at $9 and break even, so there has to be a trick...
Personally, I'd rather give my money to guys like Olimex anyway -- a notch more expensive, however these guys are /spotless/ at making everything as open as they can, and in fact, they probably 'suffer' for it as many companies seem to use their (open) designs commercially...
I'm glad to have helped fund the kickstarter. It was advertised to come with a linux distro but at the time but they didn't have many details about that. Glad to see that they're becoming part of the mainline kernel. Developments like this are going to increase the popularity of linux and smaller computing devices.
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.
Most embedded shops release u-boot source, just not in a very usable state, eg. based on old versions, zip package instead of version control, not following any of the development practices or internal organization of the original project... Same thing with the kernel. Excited to see mainline support!
Source: working in embedded, trying to fix how we release exactly these things.
I think the first time I started pushing for real version control and semi-reproducible builds in embedded device development was in 1991, when I was working on medical diagnostic devices. I really can not believe that in 2015 there are still places the still don't adhere to simple practises like that...many places unfortunately.
I mean it's like wearing pants. It's fine if you do not want to wear pants at home but once you're at work and doing something in a professional context it seems like a reasonable minimum bar to expect everyone to live up to.
Kind of amusing that the article explains how to set up the development environment using VirtualBox. I doubt many Linux kernel hackers use or want to use VirtualBox. At least, many ones working with mainline.
I'd imagine a lot of kernel developers use virtualisation during development so that they can still boot their machine (though they probably aren't running Macs).
I think he was referring to VirtualBox in particular - its kernel modules are endless sources of problems. KVM has its modules in mainline, so it's a more popular choice for kernel development.
Not ARM developers; my workstation reboots every few months, my ARM boards every few minutes :-)
That is, unless you have a qemu port for the SoC in question.
That's also why my host /sbin/reboot is "echo Wrong terminal, you idiot"
https://olimex.wordpress.com/2015/06/05/how-to-get-in-the-ne...