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