[greybus-dev] Greybus For IoT : Click Board Support on Beaglebone Boards

Jason Kridner jkridner at beagleboard.org
Wed Jul 17 16:28:09 UTC 2019


On Tue, Jul 16, 2019 at 3:25 PM Greg KH <gregkh at linuxfoundation.org> wrote:
> On Sun, Jul 14, 2019 at 01:13:37AM +0530, Vaishnav MA wrote:
> > > On Sat, Jul 13, 2019 at 06:03:02PM +0530, Vaishnav MA wrote:

[...]

> > tl;dr: the idea of the project is to bind a kernel driver for an
existing
> > I2C/SPI chip to an I2C/SPI greybus device
>
> Yes, I remember reading about this, hopefully it works out :)
>
> > No on the device side, Linux is not running, Click Boards are simply
add-on
> > modules(sensors, OLED displays, transceivers ..) which use SPI, I2C or
UART
> > to communicate with the Beaglebone and Kernel Drivers exist for most of
> > them.
>
> Do you have a pointer to the specs for these?

https://mikroe.com/click

There are about 700 different Click board options.

I'm mentoring Vaishnav in this project. I'll try to restate the goal I'd
ideally like to see him achieve.

The interim goal is provide a template for others to follow when adding any
of these Click boards to a Linux host where existing Linux drivers would be
given sufficient platform data via gbsim to be instantiated over greybus
using these embedded buses that otherwise are non-discoverable. This solves
a few problems:

1. It allows the drivers to be loaded at runtime, rather than be configured
into the boot device tree. Loading driver at boot time can be someone
reasonable to expect, but it slows the debugging process requiring a reboot
and leaving developers with the possibility of making a system not boot
easily. While dynamic overlays are somewhat supported via configfs and I'd
love to see that continue to move forward, there seems to be a fair amount
of push-back due to the security implications of being able to arbitrarily
alter the hardware. By going through greybus, we are limited to extending
and existing set of embedded busses rather than doing arbitrary pokes into
the kernel. So, this is a potentially better way to load these drivers at
runtime.

2. By using the Click header as a proxy for the various embedded buses,
there is an opportunity for abstraction of the Linux host. For example, on
BeagleBone Black, the mikroBUS Cape[1] provides 4 slots for Click boards to
be added. Each of these might utilize a different SPI port, I2C port or
GPIO pins. By defining a metadata set for the body of Click boards, we
could use our implementation of gbsim (or other solution) to map the ports
to board resources. The same abstraction should hold true for
non-BeagleBoard.org Linux systems, allowing us to better share metadata
with folks developing with, say, a Raspberry Pi. So, this is potentially a
better way to collaborate on metadata around these Click boards.

3. While this particular project focuses on building a solution for
BeagleBone Black and PocketBeagle users via gbsim, because it uses greybus,
other transports could potentially be used, either IP (such as demonstrated
by Alexandre Bailon[2][3]) or via a microcontroller interface (such as the
BeagleBone PRUs). So, this can grow to be a tested set of metadata for
connecting to hundreds of IoT sensor/actuator devices that can now be
abstracted regarding how they are wired-up to a system. I plan to talk
about this a lot more at Linux Plumbers in September.

[1] https://www.mikroe.com/beaglebone-mikrobus-cape
[2] https://www.youtube.com/watch?v=7H50pv-4YXw
[3] https://elinux.org/images/c/cb/Using_Greybus_for_IoT.pdf
[4] https://www.mikroe.com/mikrobus

>
>
> So what is going to be the "transport" layer for greybus here?

Today, gbsim will provide the transport, however that works.

>
> If the beaglebone can see the raw SPI/I2C/UART port, and that is where
> Linux is running, it's going to be a bit hard to use greybus here.

Somehow, gbsim has already largely addressed this issue as far as I can
tell. New ports are getting instantiated. The trick is providing the extra
platform information to deal with things like reset controls or interrupt
lines. The mikroBus specification[4] has physical positions for reset and
interrupt, but I'm not sure this is flexible enough. We still need to
translate that into the board-specific resources and pass those to the
kernel somehow as well.

I believe there are two problems here to solve:

1. How do we specify the extra data?

2. For a gbsim implementation, how do we add the translation layer and
build the platform data needed by the drivers?

>
> gbsim is great for doing greybus development of the host code, but
> tieing it to the actual device side is a bit tough here as that is what
> gbsim is emulating.

We'd like to extend it for the purpose of rapid-prototyping and it would
thus act a as a test harness for connecting greybus to a huge collection of
sensors/actuators that could be reused across any transport implemented in
the future, as greybus was originally intended.

>
> >  For example, for SPI based devices I am passing the Driver name to
> > Greybus(via a modified Greybus Simulator Manifest)  through the
.modalias
> > property which is being sent to the spi_new_device call in greybus
> > <
https://github.com/beagleboard/linux/blob/f45281297c419d29df9bedbb9d1eaeb12fd2b93b/drivers/staging/greybus/spilib.c#L475
>
> > ,
> > however, since additional platform_data
> > <
https://linuxtv.org/downloads/v4l-dvb-internals/device-drivers/API-struct-spi-board-info.html
>
> > is not being considered in greybus, support for devices(Click Boards)
with
> > Interrupt/Reset or other requirements cannot be implemented in this way.
> > Can you recommend the best way to bind an existing Kernel Driver for an
> > I2C/SPI chip for a Generic SPI/I2C based device(with interrupts and
other
> > platform specific data).
>
> Use device tree overlays :)

If they can be applied at runtime, that may be a suitable solution.
Translation could happen at the userspace/application layer and the
overlays could be applied. Due to the pushbacks on overlays being added to
the mainline (at least by my understanding), this would continue to live
out-of-tree. I'd like to roadmap a way to eventually bring it all back in.
Hopefully, I've explained sufficiently why greybus still has a role in
this, even if we do generate some dt overlays on-the-fly.

Regards,
Jason
--
https://beagleboard.org/about - a 501c3 non-profit educating around open
hardware computing
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linaro.org/pipermail/greybus-dev/attachments/20190717/f2002b38/attachment.html>


More information about the greybus-dev mailing list