On Fri, Dec 16, 2016 at 03:55:07PM +0000, Bryan O'Donoghue wrote:
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.
But remember that manifests come *from* the firmware (remote entity, module), but here it sounds like you want to be able pass a device-tree fragment or similar *to* the firmware. Manifests are used to describe what resources the modules provide, which wouldn't necessarily help in this case which seems to be about configuring the module (co-processor).
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.
Ok, but it sounds like what we have today would not necessarily help with that problem (apart from providing a messaging service).
Perhaps though I have a hammer and so everything looks like a nail
http://www.urbandictionary.com/define.php?term=Irish%20Screwdriver
Heh. :)
Johan