JFYI: https://developer.android.com/things/index.html
There's no reason those APIs aren't tunneled over Greybus: https://developer.android.com/things/sdk/pio/index.html Oh wait, I've seen that somewhere before.
On 13/12/16 19:42, Karim Yaghmour wrote:
JFYI: https://developer.android.com/things/index.html
There's no reason those APIs aren't tunneled over Greybus: https://developer.android.com/things/sdk/pio/index.html Oh wait, I've seen that somewhere before.
Interesting to see Intel Edison is one of the supported initial boards I must give that a try.
I suppose for a board like that you could make a virtual host-controller and have it abstract the local-discovery of modules and/or consume DTS data and feed everything into greybus bundles via manifest files built in-memory.
OTOH the co-processor on the Edison is more interesting (the Quark) - in that it can take control of some of the I/O pins - has a shared memory and could be a place to run Nuttx/Zephyr implementing greybus (something I've been thinking about).
http://hackerboards.com/edison-iot-module-ships-with-atom-plus-quark-combo-s...
Beaglebone has a co-processor too I think (though it's not on the list of supported hardware - https://developer.android.com/things/hardware/developer-kits.html.
For development boards like Edison and Beagle, I think greybus could be well suited to communicate with a firmware on the co-processor. All you'd have to do is make a host-controller across the IPC interface between host and AMP-co-processor and then write greybus into your co-processor firmware.
Easy !
--- bod
On Wed, Dec 14, 2016 at 12:24:10PM +0000, Bryan O'Donoghue wrote:
Interesting to see Intel Edison is one of the supported initial boards I must give that a try.
I suppose for a board like that you could make a virtual host-controller and have it abstract the local-discovery of modules and/or consume DTS data and feed everything into greybus bundles via manifest files built in-memory.
OTOH the co-processor on the Edison is more interesting (the Quark) - in that it can take control of some of the I/O pins - has a shared memory and could be a place to run Nuttx/Zephyr implementing greybus (something I've been thinking about).
http://hackerboards.com/edison-iot-module-ships-with-atom-plus-quark-combo-s...
Beaglebone has a co-processor too I think (though it's not on the list of supported hardware - https://developer.android.com/things/hardware/developer-kits.html.
For development boards like Edison and Beagle, I think greybus could be well suited to communicate with a firmware on the co-processor. All you'd have to do is make a host-controller across the IPC interface between host and AMP-co-processor and then write greybus into your co-processor firmware.
But why would you want that? Greybus makes sense for something pluggable (e.g. Ara) or remote (e.g. IoT), but if it's on the same board you should just use the main processor directly to toggle GPIOs or access a sensor over i2c since it would be much more efficient.
At least I fail to see the point in using the bridged-phy protocols in such a setup, but maybe you had something else in mind.
Johan
On 15/12/16 16:55, Johan Hovold wrote:
On Wed, Dec 14, 2016 at 12:24:10PM +0000, Bryan O'Donoghue wrote:
Interesting to see Intel Edison is one of the supported initial boards I must give that a try.
I suppose for a board like that you could make a virtual host-controller and have it abstract the local-discovery of modules and/or consume DTS data and feed everything into greybus bundles via manifest files built in-memory.
OTOH the co-processor on the Edison is more interesting (the Quark) - in that it can take control of some of the I/O pins - has a shared memory and could be a place to run Nuttx/Zephyr implementing greybus (something I've been thinking about).
http://hackerboards.com/edison-iot-module-ships-with-atom-plus-quark-combo-s...
Beaglebone has a co-processor too I think (though it's not on the list of supported hardware - https://developer.android.com/things/hardware/developer-kits.html.
For development boards like Edison and Beagle, I think greybus could be well suited to communicate with a firmware on the co-processor. All you'd have to do is make a host-controller across the IPC interface between host and AMP-co-processor and then write greybus into your co-processor firmware.
But why would you want that? Greybus makes sense for something pluggable (e.g. Ara) or remote (e.g. IoT), but if it's on the same board you should just use the main processor directly to toggle GPIOs or access a sensor over i2c since it would be much more efficient.
Yeah no true - bridged phy would be slower and pointless but, greybus operations and manifests are a pretty powerful way of
- Enumerating - Communicating
with a remote firmware across a message passing bus.
At least I fail to see the point in using the bridged-phy protocols in such a setup, but maybe you had something else in mind.
I'm aware of rproc - I think with a little work greybus could be a fairly decent alternative method for discovery and message passing to remote firmware.
So far I've found rproc difficult to use and implement in comparison to greybus - then again I accept I'm fairly biased :)
It's not an apples-for-apples comparison I'll grant you but still - embedded data in the firmware image (rproc) is a pain versus supplying a manifest like greybus.
--- bod
On Fri, Dec 16, 2016 at 12:10:05PM +0000, Bryan O'Donoghue wrote:
On 15/12/16 16:55, Johan Hovold wrote:
On Wed, Dec 14, 2016 at 12:24:10PM +0000, Bryan O'Donoghue wrote:
Interesting to see Intel Edison is one of the supported initial boards I must give that a try.
I suppose for a board like that you could make a virtual host-controller and have it abstract the local-discovery of modules and/or consume DTS data and feed everything into greybus bundles via manifest files built in-memory.
OTOH the co-processor on the Edison is more interesting (the Quark) - in that it can take control of some of the I/O pins - has a shared memory and could be a place to run Nuttx/Zephyr implementing greybus (something I've been thinking about).
http://hackerboards.com/edison-iot-module-ships-with-atom-plus-quark-combo-s...
Beaglebone has a co-processor too I think (though it's not on the list of supported hardware - https://developer.android.com/things/hardware/developer-kits.html.
For development boards like Edison and Beagle, I think greybus could be well suited to communicate with a firmware on the co-processor. All you'd have to do is make a host-controller across the IPC interface between host and AMP-co-processor and then write greybus into your co-processor firmware.
But why would you want that? Greybus makes sense for something pluggable (e.g. Ara) or remote (e.g. IoT), but if it's on the same board you should just use the main processor directly to toggle GPIOs or access a sensor over i2c since it would be much more efficient.
Yeah no true - bridged phy would be slower and pointless,
Don't forget that it would waste power too, as the main processor would still need to be resumed for any operation (e.g. to toggle a pin). :)
but, greybus operations and manifests are a pretty powerful way of
- Enumerating
- Communicating
with a remote firmware across a message passing bus.
But in a static setup, you control what firmware you load, so you don't need it to be self-describing.
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.
Johan
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)
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
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 ?
On Fri, Dec 16, 2016 at 04:22:02PM +0000, Bryan O'Donoghue wrote:
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 ?
Yes, but that was also in the module->AP direction, as a means to describe non-discoverable buses on the module (e.g. sensors on an i2c bus).
Johan
On Tue, Dec 13, 2016 at 11:42 AM, Karim Yaghmour <karim.yaghmour@opersys.com
wrote:
JFYI: https://developer.android.com/things/index.html
There's no reason those APIs aren't tunneled over Greybus:
heh, It probably already does have the support to :)
- ssp
-
Bryan O'Donoghue -
Johan Hovold -
Karim Yaghmour -
Sandeep Patil