User: Password:
|
|
Subscribe / Log in / New account

Raspberry Pi VideoCore driver code released

Raspberry Pi VideoCore driver code released

Posted Oct 24, 2012 15:32 UTC (Wed) by tialaramex (subscriber, #21167)
In reply to: Raspberry Pi VideoCore driver code released by cthart
Parent article: Raspberry Pi VideoCore driver code released

Well, it depends.

At one end of the scale it's no different. I've owned devices where they shipped with a CD containing some version of the firmware that had passed their internal QA and they never released any other version. That firmware might just as well be on a ROM welded to the board and I don't feel at all uncomfortable owning such hardware even though the FSF don't like it.

At the other end of the scale you've got systems where the "firmware" is very much a constantly developing independent software project whose source code you can't see and which is capable of operating somewhat independently of the CPU. Newer drivers (which get pushed into the Linus source tree) may require a newer firmware, leaving you with little choice but to update as the vendor desires. If you do something the hardware manufacturer doesn't like, a newer "firmware" can retaliate, you are not really in control of your own hardware after all.

The Raspberry Pi GPU firmware is definitely leaning over toward the second category, this is actively developed code, if somebody figures out how to, say, reverse engineer a RPi into doing something Broadcom wish it not to do you can expect to see updated firmware to resist that, albeit the foundation would probably try to spin that as a bug fix or something.


(Log in to post comments)

Raspberry Pi VideoCore driver code released

Posted Oct 24, 2012 15:48 UTC (Wed) by njwhite (guest, #51848) [Link]

Thanks for this clear explanation; it's very useful for somebody like me who doesn't know a great deal about how video drivers / firmwares work.

Presumably getting them to open up their firmware will be an even more difficult challenge. Still, this strikes me as progress, though as you say, we aren't yet at the point of having complete control over your device.

Raspberry Pi VideoCore driver code released

Posted Oct 24, 2012 17:19 UTC (Wed) by robert_s (subscriber, #42402) [Link]

I also don't quite get what level of control this gives us over the graphics. i.e. will an RPi using this be able to do all the clever things DRI2 drivers can do?

Would wayland ever run on it? (not that you should peg me as a wayland fanboy, it's just serving as a good example)

Raspberry Pi VideoCore driver code released

Posted Oct 24, 2012 17:21 UTC (Wed) by robert_s (subscriber, #42402) [Link]

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

Raspberry Pi VideoCore driver code released

Posted Oct 25, 2012 7:58 UTC (Thu) by ebassi (subscriber, #54855) [Link]

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

Raspberry Pi VideoCore driver code released

Posted Oct 25, 2012 8:10 UTC (Thu) by dlang (subscriber, #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 (guest, #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.

Raspberry Pi VideoCore driver code released

Posted Oct 24, 2012 17:32 UTC (Wed) by daniels (subscriber, #16193) [Link]

Actually, Pekka (one of the other Collaborans) already has Wayland/Weston running on RPi, albeit only for software-rendered clients. We should have more on that shortly. :)


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