Easy answer - the majority of the intricate register-level work is done by the firmware, rather than by the driver. This is how we've been able to reconcile the legitimate interests of Broadcom in keeping the fine detail of the implementation private, while also providing a workable FOSS driver suitable for use in (for example) porting other operating systems to the Pi.

That's my hope. My issue with the purists is that it's not obviously clear why they want to see the microcode running on a proprietary RISC core inside the GPU, but not for example the Verilog. Stallman is one of the few people who has a self-consistent model of what he wants to be able to see, arguing that code which is "equivalent to a circuit" (i.e. in ROM) need not be made visible. Now we don't meet this criterion as our microcode lives on the SD card, but that's largely a cost and flexibility issue and we may yet go there to get the FSF endorsement.

I should have kept some of my notes from those meetings :)

While I can't commit to this, I'm certainly a very vigorous advocate for this position, from a commercial and a community relations standpoint. Fingers crossed.

Absolutely agree with the sentiment here. Hopefully one day someone will produce a decent GPU that's free down to the Verilog level, but until then we'll have to keep taking one step at a time.

Actually, if you look at Broadcom's recent behaviour around Bluetooth drivers, I think there's good (public) evidence of a sea change in the attitude towards open source.

That is correct. Like many other pieces of hardware with open-source drivers, when you get down to it there's a chunk of microcode in ROM or RAM (ours lives on the SD card) which makes the hardware spring into life and talk to the open source stuff. The codec licensing stuff lives in there.

Bwahahaha? Making thing people want to buy considered devious plan to make people buy thing.

You're correct. The VideoCore GPU exposes a fairly high-level interface to the ARM side, so passing messages *is* the interface. We're lucky that VideoCore provides for a good tradeoff between the Broadcom's legitimate desire to maintain a degree of secrecy around the register-level operation of the hardware (read concern about competitors and patent trolls) and FOSS users' need for source code access and control.

Sorry - slightly loose use of language in the post on the blog. I wouldn't consider the DaVinci to be a "multimedia SoC" because it doesn't have a 3d accelerator. YMMV however, and there are certainly several examples of video-only ARM SoCs with FOSS driver stacks.

That was our feeling. This model is an order of magnitude easier to sell to the chip vendor, and provides all the benefits normally associated with open source drivers (provided the interface is adequately documented, which it will be in the near future).

That's a fair observation. We're lucky that, with firmware installed, the VideoCore GPU exposes a much higher-level interface to the ARM side than some other architectures. This has allowed us to provide a viable, useful open source stack while also addressing Broadcom's (completely legitimate) interest in protecting the fine detail of the underlying IP from competitors and patent trolls.

To help people get the most out of this, we hope to sponsor some efforts to formally document the interface exposed by the GPU over the next few months.

Off the top of my head, we save around a buck at 10K-off through a combination of 6 layer, coarser T&G and limited HDI. Figures for UK manufacture; YMMV in elsewhere, particularly in the far east (where cutting edge volume manufacturing is much easier).

The particular stack-up we've chosen is only one possible cost minimum; I've heard it suggested that 8 layers with zero HDI is quite competitive for 0.65mm BGA.

As I understand it, the biggest challenge was escaping a 0.65mm BGA without using significant amounts of HDI on a 6-layer board, while keeping good solid power and ground planes and large (i.e. cheap) track and gap specs. Relax more or more of those and it is indeed trivial - our alpha boards were done in about four days by doing exactly that.

Would be great to get all the components on the top side. Unfortunately, you pay for that in extra track length between the SoC decoupling caps and the BGA balls. I believe Beagle and Panda both do this with their OMAPs, and (mostly) get away with it, and we may investigate it in a later revision; in general departing from datasheet recommendations makes me queasy, even for a chip I worked on...

I completely understand the concerns around availability of datasheets and TRMs. For people who want this, Raspberry Pi may well not be a suitable platform; I'd suggest these people consider the many other small-board computers that are available *today*.

What I don't understand is why the OP feels he needs to say "probably the real reason is that easy physical access to the ports would more rapidly piss off those who buy it and realize the BCM2835 datasheet isn't available unless you're a megacorporation or an ex-employee like Eben is". That's just random hate.

Eben Upton
Raspberry Pi Foundation

Good question. We know the Beagleboard went through quite a long revision period before it got completely stable, though we've paid a bit more attention to things like ground plane configuration up front so hopefully we should converge a bit faster. Eyeballing it, probably a few layout tweaks in each production batch for the first six months.