On 16/12/16 16:10, Johan Hovold wrote:
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).
Another way to do what we want to do is to tell a firmware which pins it owns (consuming dts) yes absolutely, fair point.
I was thinking of the problem from the perspective of a firmware engineer who would want to write his/her software - have it launch and then request the resources it was assigned. For people doing projects with these types of boards they are typically breaking out to these co-processors to do 'real time' applications (meaning they want it done fast - maybe even on a deadline :) ) and those types of development patterns would probably just want to assign a few pins in their firmware, load the image and have the kernel/firmware negotiate.
I completely concede another approach (and a more Linuxly way of doing it) is to describe the resource allocation in devicetree.
Didn't we have some sort of plan to unify manifests and device-tree overlays ?