Broadcom releases SoC graphics driver source

Posted Mar 1, 2014 8:05 UTC (Sat) by pabs (subscriber, #43278)
In reply to: Broadcom releases SoC graphics driver source by pehjota
Parent article: Broadcom releases SoC graphics driver source

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