Broadcom as frontrunner?

Posted Mar 2, 2014 22:04 UTC (Sun) by excors (subscriber, #95769)
In reply to: Broadcom as frontrunner? by alison
Parent article: Broadcom releases SoC graphics driver source

Imagination did release some high-level architecture information last week (http://anandtech.com/show/7793/imaginations-powervr-rogue...), 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.

to post comments

Boot linux on the VPU?

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

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

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

> 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 (guest, #313) [Link]

how much of a MMU does uboot or coreboot need?