Difference between revisions of "Mikrobus"

From eLinux.org
Jump to: navigation, search
m (Update Mikrobus Driver Approach)
Line 15: Line 15:
  
 
=== Using Greybus simulator to enable software hotplug support ===
 
=== Using Greybus simulator to enable software hotplug support ===
This requires running the Greybus simulator, gbsim.
+
This requires running the Greybus simulator, [https://github.com/projectara/gbsim gbsim] . Instructions for setting up gbsim and more information can be found [https://github.com/vaishnav98/gbsim/wiki/Beagleboard-GSoC-'19:--Clickboard-Support-Under-Greybus here]. This method uses Greybus simulator to load a manifest blob to kernel greybus driver where the virtual interfaces(SPI/I2C/other) are created and gbsim manages the transfers between the physical bus/gpio/interrupt and the virtual greybus interface.
  
This also requires additional platform data and this is the main thing I need to explain.
+
This approach requires additional platform data for instantiating Click Devices with platform data requirements like reset/interrupt-gpio/other named-gpio, thus the approach needs more refinements to tackle the issues of instantiating devices with additional platform data requirements, a few approaches to solve this problem is discussed [https://elinux.org/BeagleBoard/Mikrobus_Support here]. This approach has an added advantage of using different transports which makes it ideal for [https://www.youtube.com/watch?v=7H50pv-4YXw IoT Applications].
  
 
== Implementation of a mikroBUS socket on an embedded Linux system ==
 
== Implementation of a mikroBUS socket on an embedded Linux system ==
Line 26: Line 26:
  
 
=== Creation of a mikroBUS bus driver in the Linux kernel ===
 
=== Creation of a mikroBUS bus driver in the Linux kernel ===
 
+
This approach does not involve the use of greybus directly but uses the greybus manifests for providing the platform data, it is actually a combination of the [https://elixir.bootlin.com/linux/v4.9.17/source/drivers/staging/greybus/manifest.c#L454 Greybus manifest parsing logic] combined with the working of [https://github.com/beagleboard/linux/blob/3.8/drivers/misc/cape/beaglebone/capemgr.c Bone Cape Manager] used in the previous BB kernels, the Cape Manager used to load the data for a cape from the Device Tree whereas this bus driver takes the data from the manifest blob passed via the SysFS interface.The Mikrobus port information for the device is parsed from the Device Tree(this information only account for the port information and does not have any click specific information).
 
== Improving the mikroBUS standard for better Linux support ==
 
== Improving the mikroBUS standard for better Linux support ==
  
Line 59: Line 59:
  
 
=== Why should mikroBUS be a bus in the kernel even if these other interfaces aren't? ===
 
=== Why should mikroBUS be a bus in the kernel even if these other interfaces aren't? ===
 +
 +
* It's an open standard
 +
* Over 750+ Click add-on boards ranging from wireless connectivity clicks to Human Machine Interface clicks, of which more than 100+ clicks has already support in the linux kernel.
 +
* Over 140+ Development boards [https://www.mikroe.com/blog/development-boards-that-support-mikrobus supported.]
  
 
=== Why aren't we opening pandora's box by adding this as a bus in the kernel? ===
 
=== Why aren't we opening pandora's box by adding this as a bus in the kernel? ===

Revision as of 16:08, 4 April 2020

mikroBUS is a standard specification by MikroElektronika that can be freely used by anyone following the guidelines. It includes SPI, I2C, UART, PWM, ADC, reset, interrupt, and power (3.3V and 5V) connections to common embedded peripherals.

This page is meant to foster discussion within the embedded Linux community on usage of mikroBUS compatible add-on boards, adding mikroBUS sockets to embedded Linux systems, and ways to improve both Linux support for mikroBUS and the mikroBUS standard.

Usage of mikroBUS compatible add-on boards today

Device tree overlays loaded at boot time

Today, there is no mainline solution for enabling mikroBUS add-on boards at run-time, so they must all be configured at boot-time with device-tree.

Instructions for PocketBeagle: https://github.com/beagleboard/pocketbeagle/wiki/Click-boards%E2%84%A2

Example overlay: https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/PB-I2C2-MPU-9DOF-CLICK.dts

There are some out-of-tree mechanisms for loading device-tree overlay fragments. TODO: Need reference to DTBO configfs patch. This patch doesn't apply after 4.14 and is not likely to be accepted in mainline. Mainline doesn't want arbitrary device-tree fragments, but there is a chance that this could be considered a "development-only" patch if this is rebased. The solution would allow run-time loading, but would not be automatic and requires authoring of overlay fragments specific to every add-on board, every Linux platform and every mikroBUS socket.

Using Greybus simulator to enable software hotplug support

This requires running the Greybus simulator, gbsim . Instructions for setting up gbsim and more information can be found here. This method uses Greybus simulator to load a manifest blob to kernel greybus driver where the virtual interfaces(SPI/I2C/other) are created and gbsim manages the transfers between the physical bus/gpio/interrupt and the virtual greybus interface.

This approach requires additional platform data for instantiating Click Devices with platform data requirements like reset/interrupt-gpio/other named-gpio, thus the approach needs more refinements to tackle the issues of instantiating devices with additional platform data requirements, a few approaches to solve this problem is discussed here. This approach has an added advantage of using different transports which makes it ideal for IoT Applications.

Implementation of a mikroBUS socket on an embedded Linux system

Improving Linux support for mikroBUS

Motivation for supporting software hotplug

Creation of a mikroBUS bus driver in the Linux kernel

This approach does not involve the use of greybus directly but uses the greybus manifests for providing the platform data, it is actually a combination of the Greybus manifest parsing logic combined with the working of Bone Cape Manager used in the previous BB kernels, the Cape Manager used to load the data for a cape from the Device Tree whereas this bus driver takes the data from the manifest blob passed via the SysFS interface.The Mikrobus port information for the device is parsed from the Device Tree(this information only account for the port information and does not have any click specific information).

Improving the mikroBUS standard for better Linux support

Identifier

Proposal #1: Use Greybus Manifest binaries

  • Module vendor specified separately from driver usage
  • Possibility of using existing driver names for invocation

Proposal #2: Use simple string identifiers

  • Requires table to be kept in kernel
  • Fix-ups would be very direct and not "fix-ups" at all, since no driver specific information would be encoded

Specifics on power function

The direction and accommodations related to the power pins aren't as specific in the mikroBus standard as with Feather.

Comparisons to other popular embedded add-on form-factors

The purpose of this page is to advance the development of mikroBUS support in Linux. Some distractions may be introduced to either illustrate the effort cannot be sufficiently limited in scope to tackle or that focus should be elsewhere. I'm not assuming these would be introduced with any ill-will, they are just natural concerns that need to be addressed up-front.

Form-factor Size Comments
mikroBUS 1.0" x 1.125"/1.6"/2.25" Example
Feather/Wing 0.9" x 2.0" De-facto standard based on implementation pin-out. Could benefit from some of the efforts for mikroBUS support, but not as cleanly defined with a limited and focused scope. Not as easy to make an impact on the majority of existing designs.
Arduino/Shield XxY Too irregular to make useful as an embedded system bus.
BeagleBone/Cape XxY Far too flexible for a standard outside of the Beagle ecosystem.

Why should mikroBUS be a bus in the kernel even if these other interfaces aren't?

  • It's an open standard
  • Over 750+ Click add-on boards ranging from wireless connectivity clicks to Human Machine Interface clicks, of which more than 100+ clicks has already support in the linux kernel.
  • Over 140+ Development boards supported.

Why aren't we opening pandora's box by adding this as a bus in the kernel?

Definitions

  • Platform data
  • Device driver
  • Bus driver
  • Probe
  • Identifier
  • Device tree