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