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-soc/ >> >> 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 _______________________________________________ greybus-dev mailing list greybus-dev@xxxxxxxxxxxxxxxx https://lists.linaro.org/mailman/listinfo/greybus-dev
|