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