User: Password:
Subscribe / Log in / New account

Broadcom releases SoC graphics driver source

Broadcom has announced the release of the source and documentation for its VideoCore IV graphics subsystem. This subsystem is found in the Raspberry Pi processor, among others. "The trend over the last decade has leaned towards greater openness in desktop graphics, and the same is happening in the mobile space. Broadcom — a long-time leader in graphics processors — is a frontrunner in this movement and aims to contribute to its momentum."
(Log in to post comments)

Broadcom releases SoC graphics driver source

Posted Feb 28, 2014 23:50 UTC (Fri) by jhoblitt (subscriber, #77733) [Link]

Pinch me? I must be...

Broadcom releases SoC graphics driver source

Posted Mar 1, 2014 16:37 UTC (Sat) by NAR (subscriber, #1313) [Link]

I guess now we know why we didn't have much of a winter here - Hell froze instead :-)

Broadcom releases SoC graphics driver source

Posted Mar 1, 2014 0:29 UTC (Sat) by pabs (subscriber, #43278) [Link]

This sentence is interesting: "To mark the Raspberry Pi’s second anniversary, the Foundation has put challenge up to the community: It’s offering $10,000 to the first person that can port Broadcom’s VideoCore drivers to run on the Pi."

Right, with that kind of money...

Posted Mar 1, 2014 3:40 UTC (Sat) by gwolf (subscriber, #14632) [Link]

10,000 dollars can buy approximately 250 Raspberries. Which can in turn become a massive graphics farm!

(Hummmm... How powerful is this Broadcom thingy next to, say, a decent nVidia with Noveau?)

Right, with that kind of money...

Posted Mar 1, 2014 3:50 UTC (Sat) by pabs (subscriber, #43278) [Link]

I expect it is much slower than a discrete NVIDIA GPU, even with nouveau drivers.

Right, with that kind of money...

Posted Mar 1, 2014 11:42 UTC (Sat) by excors (subscriber, #95769) [Link]

It claims 24 GFLOPS. (Per the just-released documentation, the architecture is based on a QPU (a 4-way SIMD processor that does one multiply and one non-multiply instruction per cycle), at 250MHz. There are 4 QPUs per slice, and 3 slices in the chip, and 4*2*250M*4*3 = 24G.)

So $10K will get you 6 TFLOPS. That's apparently the same as about 3 GeForce GTX 760, which will cost about $750 (and which have far more flexible GPGPU support). If you have the money and power and want raw compute performance, you should probably stick with NVIDIA.

Of course the GTX 760 doesn't scale down to the cost and power requirements that the RPi's chip was designed for. And if you want to learn how to hack around on graphics drivers, the RPi is probably a pretty good place to start now, since the hardware looks much simpler than modern desktop GPUs.

Given the amount of effort many people have put into reverse-engineering other mobile GPU architectures, I think it would be great if this release of documentation and code led to serious work from the open source community on decent RPi Linux drivers, to demonstrate to Broadcom and other vendors that releasing this kind of information is going to be worthwhile for them and that they should do more of it.

Broadcom releases SoC graphics driver source

Posted Mar 1, 2014 3:41 UTC (Sat) by pehjota (guest, #91496) [Link]

I'm not an expert on the VideoCore SoCs, but I took a quick look at the code dump to see if it was just the OS drivers or if it included the previously non-free GPU firmware, which is needed even just to boot the CPU. (VideoCore is an unusual architecture in which an RTOS named "VideoCore OS" running on the GPU boots an OS like GNU/Linux on the CPU.)

Under brcm_usrlib/dag/vmcsx/vcfw/ I found what seems to be the complete vcos (VideoCore OS) firmware. So by my inexpert assessment, this appears to be everything needed to boot a VideoCore SoC! (Verification by someone more knowledgeable in VideoCore and/or in possession of a supported SoC for testing would be nice.)

However, I noticed that twelve files under brcm_usrlib/dag/vmcsx/vcfw/rtos/common/ are copyright ARC International: fread.c, fwrite.c, hl_bios.c, hl_bios.h, hl_data.c, hl_data.h, hostcom.h, metaware_internal_headers/fio.h, metaware_internal_headers/libhdr.h, metaware_internal_headers/thread.h, mutexg.c, and setvbuf.c. None of these files refer to a public license, but seven of them contain the following ominous confidentiality notice:

(C) Copyright 2002-2007 ARC International (ARC);  Santa Cruz, CA 95060
This program is the unpublished property and trade secret of ARC.   It
is to be  utilized  solely  under  license  from  ARC  and it is to be
maintained on a confidential basis for internal company use only.  The
security  and  protection  of  the program is paramount to maintenance
of the trade secret status.  It is to  be  protected  from  disclosure
to unauthorized parties, both within the Licensee company and outside,
in a manner  not less stringent than  that utilized for Licensee's own
proprietary internal information.  No  copies of  the source or Object
Code are to leave the premises of Licensee's business except in strict
accordance with the license agreement signed by Licensee with ARC.

I wonder if Broadcom ever got a license from ARC (rather, the company that acquired the company that acquired ARC) to publish this code. I'd hesitate to distribute or modify these files unless Broadcom clarifies this. Some of the files are short or fairly generic and probably wouldn't be too hard to replace with clearly licensed code, if that proves necessary.

All of the other source files under brcm_usrlib/dag/vmcsx/vcfw/ have Broadcom's copyright notices and 3-clause BSD license text. One file (brcm_usrlib/dag/vmcsx/vcfw/drivers/chip/vciv/2708/v3d_linux.h) also has an oddly written GPLv2-only license notice.

Broadcom releases SoC graphics driver source

Posted Mar 1, 2014 8:05 UTC (Sat) by pabs (subscriber, #43278) [Link]

Also based on the analysis here there are some source files missing, some headers are generated from them.

Broadcom releases SoC graphics driver source

Posted Mar 1, 2014 10:56 UTC (Sat) by slp (guest, #95767) [Link]

I'm no expert on RPi internals, but looking at the sources, I think the vast majority of the ThreadX based RTOS which is running on the VPU is missing. In fact, only a few headers for some interfaces seem to be present.

This means this source release will be very helpful for projects like which are working on reverse engineering VideoCore and building assemblers for its instruction set.

But to being able to run a 3D program without making use of any binary blobs, you'll still need to develop replacement for the RTOS, including the initialization code, all subsystems and an OpenGLES implementation (!). All of this without an architectural simulator or a proper toolchain.

On the bright side, ignoring the whole "replace the firmware" stuff, it's very probably that in a near future we'll be able to use the VPU for running custom code, which would be really useful for moving some heavy computing tasks there, relieving the burden of the little RPi's ARM core.

Broadcom releases SoC graphics driver source

Posted Mar 1, 2014 12:43 UTC (Sat) by excors (subscriber, #95769) [Link]

The term "VideoCore" is a bit confusing. In the RPi, it refers to the VPU (the dual-core multimedia-optimised processor, running the proprietary firmware on an RTOS), the 3D hardware block, codecs, display, camera/ISP, etc. The chip was originally a fairly high-end design, so it has a lot of hardware-accelerated features. All that hardware was controlled by the firmware, and the firmware exposed a very high-level API to the ARM (e.g. the whole GLSL shader compiler was inside the firmware).

In contrast, BCM21553 was a low-end design - it uses the same VideoCore name and has essentially the same 3D hardware block (though with far fewer QPUs, i.e. much lower performance), but as far as I'm aware it has very little else. In particular there is no VPU, so the 3D hardware had to be controlled directly from the ARM. I believe the 3D stack was originally written for the VPU without much consideration for platform-independence, and then got ported to the ARM, and that's what got released now. Any references in the code to VPU and RTOS are remnants of that porting that never got cleaned up properly.

Those remnants should be interesting to people reverse-engineering the VPU - e.g. there's a load of VPU vector assembly (which is a fun 16-way 2D-register-file SIMD design), and definitions of a lot of non-3D hardware registers - but you certainly couldn't compile any useful firmware from them.

If you port that BCM21553 code back to the RPi, then you'll still be relying on the binary blob to control the non-3D hardware, but the entire OpenGL ES stack (everything from and the shader compiler to the register poking) will be on the ARM.

Broadcom releases SoC graphics driver source

Posted Mar 1, 2014 13:21 UTC (Sat) by robclark (subscriber, #74945) [Link]

ahh, that explanation about the rtos remnants makes a lot more sense..

btw, do you know if anyone has confirmed that you can access/control the gpu from the ARM? It sorta seems this whole exercise would be pointless if not, but wasn't sure if you would be relying on r-pi foundation or someone to provide a special boot-but-no-gpu firmware blob?

Broadcom releases SoC graphics driver source

Posted Mar 1, 2014 14:14 UTC (Sat) by sperl (subscriber, #5657) [Link]

Well - all the gpu registers are available starting at bus-address at 0x7ec00000 (see page 110 of the document).
Similar to the dma registers being accessible starting from: 0x7e007000 or spi at: 0x7e204000.

So you just have to iomap the range into your process range (kernel/user) and then you can start making use of it by poking values to it.

Actually the arm and vPU both make use of the same memory - so there can be an easy means to communicate between the two via memory access..

The full list of documented/undocumented registers can get found at:
(Note that the gpu registers are not listed yet as they have not been discovered so far...)

This GitHub page contains a lot of other valuable information as well - including an assembler and links to development of other tool chain components...

Broadcom releases SoC graphics driver source

Posted Mar 1, 2014 15:01 UTC (Sat) by excors (subscriber, #95769) [Link]

I'm not certain about the details, but I'd expect the most likely conflicts are over interrupts (the V3D interrupts need to be directed to the ARM and not the VPU), power/clock management (which is currently controlled by the VPU; the V3D block is on a separate power domain so it will probably be off by default), and non-OpenGL firmware features that try to use the V3D hardware directly (probably just the camera). I think it should be possible to deal with those issues from the ARM side with the current blob, given that the ARM has access to every hardware register, though it might be a bit hacky and fragile without some extra cooperation from the firmware (but it shouldn't be hard to get that cooperation).

Broadcom releases SoC graphics driver source

Posted Mar 1, 2014 15:36 UTC (Sat) by sperl (subscriber, #5657) [Link]

There are separate interrupt registers for arm and vPU - and for the same interrupt source either or both May may trigger. As for access to the registers these need to get arbitrated.
But some - like the gpio set/reset are accessible without synchronization, but others - like setting input/output direction or alternative modes are not free of potential races when accessed from both sides

So some scheme will need to get used for access to the clocks and memory...
That is also why only about half the dma channels are available to the arm (see the dma mask command line argument to the kernel when booting the arm - also available via mailbox commands)

Seems as if the vPU has some semaphore/synchronization asm-commands - but know how these would play together with synchronization with the arm side.

But it could be in principle be possible to run the vPU side with a minimal linux system and use ballooning to give/return memory between those two linux systems...

And then run on this linux the gpu handling code but with communication with the arm...
(Not sure if there is a mmu on the vPU...)

The biggest problem seems to be still the issue of not knowing how to setup SRAM access during the boot-phase, as the vPU is starting up the arm, so it needs to configure the memory prior to kick starting the arm side - from then on both sides need to work together - similar to what they do right now via those mailbox mechanism.

As soon as the SRAM issue is understood - uboot might be the first step in the direction of a dual linux system with a total of 3 cores...

Broadcom releases SoC graphics driver source

Posted Mar 2, 2014 4:12 UTC (Sun) by gdt (subscriber, #6284) [Link]

Yep, it looks like that to me too. Not too surprising, since ThreadX is a commercial program.

I rather view the Android source as part of the specification: as if they said "here are the specifications written by our technical writers, and here's known-good source code for another operating system to answer further questions".

Broadcom as frontrunner?

Posted Mar 1, 2014 11:13 UTC (Sat) by sebas (subscriber, #51660) [Link]

Did anyone else wonder when the meaning of the word "frontrunner" changed?

Broadcom as frontrunner?

Posted Mar 1, 2014 21:32 UTC (Sat) by speedster1 (subscriber, #8143) [Link]

> Did anyone else wonder when the meaning of the word "frontrunner" changed?

While Broadcom is far from a frontrunner in the *general* category of hardware companies releasing information useful for Free Software drivers, this release puts them ahead of their competitors in this *specific* field of ARM graphics. So far the other ARM graphic driver projects I've seen are all reverse-engineering efforts without the benefit of any vendor support:

Broadcom as frontrunner?

Posted Mar 2, 2014 15:13 UTC (Sun) by alison (subscriber, #63752) [Link]

Certainly the release vaults BCM past Imagination Technologies and Vivante, whom AFAIK have released nothing to date. ImagTech's plans are a particularly intriguing question now that they control MIPS.

Are we to understand that ThreadX on the VPU acts as a shim boot loader for another bootloader that brings up Linux? Or did we decide that there's no VPU at all?

I wonder if coin miners will find the Pi attractive if it can be made to perform GPGPU quickly. That would be too bad for students and hobbyist s. Apparently many Radeon boards are in short supply.

Broadcom as frontrunner?

Posted Mar 2, 2014 22:04 UTC (Sun) by excors (subscriber, #95769) [Link]

Imagination did release some high-level architecture information last week (, which is a good step towards openness compared to the industry's previous secrecy, but none of the detail needed to write a driver without major reverse-engineering.

On Raspberry Pi, the VPU starts executing code from ROM when powered on. That code tells it to load bootcode.bin (which is about 16KB) from the SD card into the L2 cache and the VPU jumps into it. bootcode.bin sets up the SDRAM and clocks, then loads start.elf (about 2.5MB) from the SD card into SDRAM and the VPU jumps into it. start.elf loads kernel.img from the SD card and turns on the ARM, which will then boot the Linux kernel. start.elf also implements the various services that the ARM can call over an RPC mechanism (including the service for OpenGL ES).

The ROM code and bootcode.bin don't have any kind of operating system at all. start.elf uses ThreadX.

Since you can't change the ROM, you're always going to need some software on the VPU to start the ARM. But with the code and documentation released now, you don't need to use the OpenGL service provided by start.elf - instead the ARM can talk to the 3D hardware directly (or at least that's the goal; it's going to take some non-trivial porting of the released code). If you don't need any of the VPU's other services, then in theory you could get away with a very minimal start.elf.

Boot linux on the VPU?

Posted Mar 3, 2014 11:42 UTC (Mon) by alex (subscriber, #1355) [Link]

Given the VPU code can evidently load a file from a SD card partition could you not port Linux to boot directly on the VPU? Would it be too slow even compared to the weedy ARM11 because of the VPUs parallel GPU orientated architecture?

Boot linux on the VPU?

Posted Mar 3, 2014 12:01 UTC (Mon) by smurf (subscriber, #17840) [Link]

I suppose you could, but let the VPU do what it does best: process graphics.

Another laudable goal would be to get it to act as a crypto coprocessor.

Boot linux on the VPU?

Posted Mar 3, 2014 13:11 UTC (Mon) by sperl (subscriber, #5657) [Link]

At least the basic Peripheral Document states in the diagram on page 5 that there are 2 MMUs. The VC/ARM MMU and the ARM MMU.
So there must be a possibility to make use of it - unfortunately this is possibly not documented and might be only corse-grained (as hinted on page 4)

I would like to see a dual linux system as well - the GPU part could then be a simple process on the VCPU and other processes could also run if the RPI is used headless for encryption, camera, or other tasks,...

If Linux is not possible due to MMU restrictions, then at least moving to FreeRTOS would allow for better integration of such tasks for all who want to make use of it...

Boot linux on the VPU?

Posted Mar 3, 2014 12:46 UTC (Mon) by the.wrong.christian (guest, #73127) [Link]

> Given the VPU code can evidently load a file from a SD card partition could you not port Linux to boot directly on the VPU? Would it be too slow even compared to the weedy ARM11 because of the VPUs parallel GPU orientated architecture?

I don't know, but I'd suspect the VPU wouldn't have a sufficiently capable MMU. No MMU, no process isolation, but fine for an RTOS or uCLinux.

I suspect also that while the GPU has impressive (for it's size/price) GFLOPS, it achieves that using SIMD parallelism inherent in graphical operations. For scalar code like OS kernels, performance would probably stink as the clock rate is quite low.

Boot linux on the VPU?

Posted Mar 3, 2014 20:00 UTC (Mon) by dlang (subscriber, #313) [Link]

how much of a MMU does uboot or coreboot need?

Broadcom as frontrunner?

Posted Mar 3, 2014 14:29 UTC (Mon) by Felix.Braun (subscriber, #3032) [Link]

Doesn't nVidia's recent contribution to nouveau (link) count as vendor support?

Broadcom as frontrunner?

Posted Mar 4, 2014 7:52 UTC (Tue) by speedster1 (subscriber, #8143) [Link]

> Doesn't nVidia's recent contribution to nouveau (link) count as vendor support?

Nope, not relevant to the currently discussed topic of ARM graphics drivers, where proprietary blobs have thus far been the norm.

For the broader field of graphics hardware in general, there are way better examples of vendor support for open source drivers -- ATI and Intel are still far ahead of nVidia in that respect.

Broadcom as frontrunner?

Posted Mar 4, 2014 8:55 UTC (Tue) by khim (subscriber, #9252) [Link]

You mean: there are an ARM and there are ARM? What's the difference between Tegra and other ARM chips? Why do you explude it's support from consideration?

I'm not big fan of nVidia in general, but this time they were most definitely first. No offence to the Broadcom.

Broadcom as frontrunner?

Posted Mar 4, 2014 18:00 UTC (Tue) by speedster1 (subscriber, #8143) [Link]

Apologies, I skimmed too fast (thanks to Khim for pointing it out). This was a different announcement than the initial boring ones, and nVidia actually did provide code towards basic support for some of their (hardware-not-yet-released) ARM graphics. I suspect the Tegra K1 will be released before the RPi driver port gets as far, which would put Broadcom in 2nd place after all :-)

Copyright © 2014, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds