On 16/12/16 15:00, Johan Hovold wrote:
But in a static setup, you control what firmware you load, so you don't need it to be self-describing.
That depends.
Right now I don't see a good method for kernel and a firmware to agree on ownership of GPIOs (and other shared resources) for example. I know virtio/rproc (or some combination of the two) is supposed to be able to do this.
Just transmitting a manifest over an RPC link seems much simpler than what I've seen of virtio/rproc so far - and I'm not convinced the two together can describe as much as a manifest file.
On some platforms (taking Edison as an example) you load a firmware that basically just assumes it owns some pins. There's exactly zero synchronisation between the two AMP processors (no type of message passing to negotiate) between kernel and firmware (that I know of).
So it's pretty easy to mess that type of setup up. Whereas if the firmware returned a descriptor (or made requests for certain shared resources) it would be a lot less brittle.
Greybus (or another protocol) could be used to request allocation of a GPIO from Linux to firmware, same with UART, i2c or another piece of hardware that both sides of the message bus can own - but only one of them should own at any one time.
That's at least part of the problem I was looking at greybus to solve.
Perhaps though I have a hammer and so everything looks like a nail
http://www.urbandictionary.com/define.php?term=Irish%20Screwdriver
The operations themselves could work as an RPC (e.g. using the raw protocol), but using Greybus in a setup like this seems like a very inefficient way to get things done.
Maybe. Most of what's out there to talk to co-processors is pretty horrific as far as I can see - with almost no real synchronisation of resources.
Maybe virtio and rproc will make more sense as I try use it more but right now my greybus hammer looks like a very handy tool... (hammer)