Raspberry Pi VideoCore driver code released [LWN.net]

Raspberry Pi VideoCore driver code released

Posted Oct 25, 2012 7:58 UTC (Thu) by ebassi (subscriber, #54855)
In reply to: Raspberry Pi VideoCore driver code released by robert_s
Parent article: Raspberry Pi VideoCore driver code released

Ah I just RTFA in full which says wayland should be possible.

I honestly cannot see how that would follow: the shim driver does not allow adding required extensions, in case they are not present and exposed already; and it doesn't allow fixing bugs — which I just know are there because all GLES and EGL implementations for Linux on embedded hardware suck beyond belief.

this is the same exact situation we already have with nVidia and their proprietary blob, or with the IMG open source Linux driver (which was used, amongst other platforms, on the Intel "Poulsbo" netbooks).

(Log in to post comments)

Raspberry Pi VideoCore driver code released

Posted Oct 25, 2012 8:10 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]

> this is the same exact situation we already have with nVidia and their proprietary blob, or with the IMG open source Linux driver (which was used, amongst other platforms, on the Intel "Poulsbo" netbooks).

There is one difference that I see as being critical.

The binary blob doesn't run on the main CPU, and as a result, cannot affect or be effected by the rest of the code running on that CPU.

This means that changes in locking, changes in the kernel->driver API, and even changes in the X-> driver API (including making a Wayland or android driver) cannot be blocked because the vendor hasn't updated their driver for the new kernel yet.

It's much harder for bugs in the binary blob to break the kernel. locking problems in the binary blob cannot cause problems in the kernel, Other than DOS type problems, the only thing the binary blob can do to break the system is to start scribbling on memory that's not allocated to the CPU. this is still possible, but is a much, much smaller level of vunerability than when the binary blob is running in the same address space and on the same processor as the kernel.

I seem to remember a case a few years ago when Fedora didn't use the latest kernel that was out because NVIDIA hadn't updated their drivers to be compatible with it yet.

This sort of thing is not possible with everything that's running on the main CPU being open.

Raspberry Pi VideoCore driver code released

Posted Oct 25, 2012 8:20 UTC (Thu) by swetland (subscriber, #63414) [Link]

The big question I always ask about these designs is "can the peripheral processor access arbitrary memory"... if so, then you need to worry about bugs in the fw blob possibly splattering something you care about... on a number of the more modern ARM SoCs, the peripherals sit behind IOMMUs, so the kernel has final say in what exactly the fw can interact with. Not sure how things work in this particular BCM SoC.

Obviously, a completely open driver where you can fiddle with any part of it beats the implementation running on an embedded core, but I'll take the embedded core any day of the week over having to have random proprietary binaries in userspace or (shudder) the kernel.

All I ask is that the architecture give the kernel a way to protect the apps processor and main memory from the dedicated cores. Debugging memory corruption issues originating from blackbox coprocessor firmware: very not fun.

Raspberry Pi VideoCore driver code released

Posted Oct 25, 2012 11:09 UTC (Thu) by endecotp (guest, #36428) [Link]

> The big question I always ask about these designs is "can the
> peripheral processor access arbitrary memory"
> Not sure how things work in this particular BCM SoC.

I hear that when this chip powers on, it's the GPU that starts first; it autonomously loads its firmware from flash, sets up the world, and then enables the ARM. It is Linux that is, in effect, running on the "secondary" processor.

Raspberry Pi VideoCore driver code released

Posted Oct 28, 2012 16:52 UTC (Sun) by JanC_ (guest, #34940) [Link]

Which makes the ARM that you can run linux on a coprocessor that now can do callbacks to the main processor...

As if you would have an open source Arduino program send graphics commands over the USB/serial interface to your Windows PC, let a closed source program on the PC render stuff on its screen based on those commands, and then claim the Arduino has an open source GPU driver.