Broadcom releases SoC graphics driver source

Posted Mar 1, 2014 3:41 UTC (Sat) by pehjota (guest, #91496)
Parent article: Broadcom releases SoC graphics driver source

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] (7 responses)

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

http://www.freelists.org/post/raspi-internals/Hey-look-QP...

Broadcom releases SoC graphics driver source

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

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 https://github.com/hermanhermitage/videocoreiv 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] (4 responses)

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 libGLESv2.so 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] (3 responses)

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:
https://github.com/hermanhermitage/videocoreiv/wiki/Regis...
(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] (1 responses)

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".