> > 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?
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.
>
>
> 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.
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,