mikroBUS manifesto additions #2
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
mikroBUS is an add-on board socket standard by MikroElektronika which provides high expandability with the lowest number of pins used. The mikrobus linux kernel driver makes use of an extended version of the greybus manifest to pass the device driver specific information, the manifest binary is expected to be stored on an on-board EEPROM from where the mikroBUS driver fetches the contents and enumerates the drivers.
Add example manifest for a mikrobus add-on board(ENC28J60 SPI Ethernet Controller) The manifest was tested with the mikroBUS driver on a PocketBeagle Target.
vaishnavachath
force-pushed
the
mikrobus_manifesto
branch
from
82dce65
to
aff9b2c
Compare
|
Vaishnav thank you for your pull request. I am very interested in this but we are considering moving this upstream repository somewhere else, so your request may not get addressed until after that is settled. Please join the Greybus mailing list if you have not; it basically serves as the de-facto Project Ara discussion list, and "manifesto" would fall into that category. https://lists.linaro.org/mailman/listinfo/greybus-dev |
|
Is there a pointer to the kernel code for this anywhere? |
|
Thank you @alexelder and @gregkh for your quick response, the Kernel code for the mikroBUS add-on board support is submitted for RFC: https://lkml.org/lkml/2020/7/24/518 |
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jul 24, 2020
Attached is a patch for the mikroBUS driver which helps to instantiate an add-on board device on a mikrobus port by fetching the device identifier manifest binary from an EEPROM on-board the device. mikroBUS is an add-on board socket standard by MikroElektronika that can be freely used by anyone following the guidelines, more details and discussions on the status of the driver can be found here in this eLinux wiki: https://elinux.org/Mikrobus In the current state of the driver, more than 80 different add-on boards have been tested on the BeagleBoard.org PocketBeagle and the manifest binary is generated using the same manifesto tool used to generate Greybus manifest binaries, The pull request to manifesto to add new descriptors specific to mikrobus is here : projectara/manifesto#2 The utilization of Greybus manifest binaries here is not entirely coincidental, We are evaluating ways to add mikroBUS sockets and devices via Greybus expansion. The mikroBUS standard includes SPI, I2C, UART, PWM, ADC, GPIO and power (3.3V and 5V) connections to interface common embedded peripherals, There are more than 750 add-on boards ranging from wireless connectivity boards to human-machine interface sensors which conform to the mikroBUS standard, out of which more than 140 boards already have support in the Linux kernel.Today, there is no mainlinesolution for enabling mikroBUS add-on boards at run-time, the most straight forward method for loading drivers is to provide device-tree overlay fragments at boot time, this method suffers from the need to maintain a large out-of-tree database for which there is need to maintain an overlay for every mikroBUS add-on board for every Linux system and for every mikroBUS socket on that system. The mikroBUS driver tries to solve the problem by using extended version of the greybus manifest to describe the add-on board device specific information required by the device driver and uses it along with the fixed port specific information to probe the specific device driver.The manifest binary is now fetched from an I2C EEPROM over the I2C bus on the mikroBUS port(subject to change in mikroBUS v3 specification) and enumerate drivers for the add-on devices.There is also ongoing work to define a mikroBUS v3 standard in which the addon board includes a non-volatile storage to store the device identifier manifest binary, once the mikroBUS v3 standard is released, the mikroBUS can be seen as a probeable bus such that the kernel can discover the device on the bus at boot time. The driver also has a few debug SysFS interfaces for testing on add-on boards without an EEPROM, these can be used in the following manner: (example for mikroBUS port 1 on BeagleBoard.org PocketBeagle): printf "%b" '\x01\x00\x00\x59\x32\x17' > /sys/bus/mikrobus/add_port The bytes in the byte array sequence are (in order): * i2c_adap_nr * spi_master_nr * serdev_ctlr_nr * rst_gpio_nr * pwm_gpio_nr * int_gpio_nr * add_port sysFS entry is purely for debug and in the actual state of the driver, port configuration will be loaded from a suitable device tree overlay fragment. echo 0 > /sys/bus/mikrobus/del_port (to delete the attached port) echo 1 > /sys/class/mikrobus-port/mikrobus-0/rescan (to rescan the EEPROM contents on the I2C bus on the mikroBUS port). cat board_manifest.mnfb > /sys/class/mikrobus-port/mikrobus-0/new_device * debug interface to pass the manifest binary in case an EEPROM is absent echo 0 > /sys/class/mikrobus-port/mikrobus-0/delete_device * to unload the loaded board on the mikrobus port These sysFS interfaces are only implemented for debug purposes and in the actual implementation of the driver these will be removed and the manifest binary will be fetched from the non volatile storage on-board the device. The mikroBUS driver enable the mikroBUS to be a probeable bus such that the kernel can discover the device and automatically load the drivers. There are already several Linux platforms with mikroBUS sockets and the mikroBUS driver helps to reduce the time to develop and debug support for various mikroBUS add-on boards. Further, it opens up the possibility for support under dynamically instantiated buses such as with Greybus. Please let know the feedback you have on this patch or the approach used. Thanks, Vaishnav M A Signed-off-by: Vaishnav M A <vaishnav@beagleboard.org>
cfriedt
reviewed
Jul 24, 2020
| ; in linux/irq.h | ||
| [device-descriptor 1] | ||
| driver-string-id = 3 | ||
| protocol = 0x1 |
There was a problem hiding this comment.
This was already discussed, and was also posted to the LKML, but we should reuse the CPort Protocol enumerations rather than coming up with new enumerations here for compatibility reasons.
jadonk
reviewed
Jul 26, 2020
manifesto
Outdated
| 0x01: 'SPI', | ||
| 0x02: 'I2C', | ||
| 0x03: 'UART', | ||
| 0x04: 'SPI_GPIO_CS', |
There was a problem hiding this comment.
@cfriedt I don't think this needs to be handled right away, but by switching to CPort protocols, these additional protocols will be removed. These special cases are here to enable special driver modes. I believe moving them to properties or an alternative extension does make sense to keep CPort and DeviceDescriptor well in-sync.
There was a problem hiding this comment.
I think it would be helpful to have a clearer description about what these protocols are for. I'm a bit hesitant to give it a thumbs-up because it may be a problem that is already solved on the Greybus / controller side. I'm not sure if that was brought up on LKML.
|
On 8/6/20 12:39 PM, Christopher Friedt wrote:
***@***.**** commented on this pull request.
In general, this was my thinking as well. There
exist protocols in Greybus to serve those device
types. I wanted to learn more about mikroBUS
before I responded about this, but so far am
not in a position to comment.
-Alex
… ------------------------------------------------------------------------
In manifesto
<#2 (comment)>:
> + self._parent = desc
+
+ def __str__(self):
+ r = ""
+ r += "[{} {:#x}]\n".format(MnfsParser.PROPERTY_DESC, self.id_)
+ r += "name-string-id = {}\n".format(self.name_stringid)
+ r += "type = {}\n".format(self.typ)
+ r += "value = {}\n".format(self.value)
+ return r
+
+class DeviceDescriptor(Descriptor):
+ device_protocol = {
+ 0x01: 'SPI',
+ 0x02: 'I2C',
+ 0x03: 'UART',
+ 0x04: 'SPI_GPIO_CS',
I think it would be helpful to have a clearer description about what
these protocols are for. I'm a bit hesitant to give it a thumbs-up
because it may be a problem that is already solved on the Greybus /
controller side. I'm not sure if that was brought up on LKML.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAH3SY47JPKBBOHWCE2ZO7DR7LTGLANCNFSM4PCOYOTA>.
|
This commit updates the mikrobus descriptor and the device descriptor as per the changes in the v2 patch for mikrobus driver.
vaishnavachath
force-pushed
the
mikrobus_manifesto
branch
from
012c38e
to
0a2c09a
Compare
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Aug 18, 2020
This patch adds new descriptors used in the manifest parsing inside the mikrobus driver, the device descriptor help to describe the devices on a mikroBUS port, mikrobus descriptor is used to set up the mikrobus port pinmux and GPIO states and property descriptor to pass named properties to device drivers through the Unified Properties API under linux/property.h The corresponding pull request for manifesto is updated at : projectara/manifesto#2 Signed-off-by: Vaishnav M A <vaishnav@beagleboard.org>
Ayush1325
added a commit
to Ayush1325/linux
that referenced
this pull request
Mar 17, 2024
DONOTMERGE mikroBUS addon boards allow using same mikroBUS connector for a wide range of peripherals. It is also possible for the addon board not to use all the pins in mikroBUS socket (marked by NC or Not Connected). This would require the need to create an almost new overlays for each permutation of the hardware. To overcome this, a manifest format based on Greybus manifest specification was created which allows describing mikroBUS addon boards. The reason for choosing greybus manifest for the identifier is that so far we discussed only about physical mikroBUS ports on the board, but we can also have mikroBUS ports on a remote microcontroller appearing on host over greybus and there a device tree overlay solution does not work as the standard identifier mechanism. The patch introduces 3 new greybus descriptor types: 1. mikrobus-descriptor: Is a fixed-length descriptor (12 bytes), and the manifest shall have precisely one mikroBUS descriptor. Each byte describes a configuration of the corresponding pin on the mikroBUS addon board in a clockwise direction starting from the PWM pin omitting power (VCC and ground) pins as same as the default state of the pin. There are mikroBUS addon boards that use some dedicated SPI, UART, PWM, and I2C pins as GPIO pins, so it is necessary to redefine the default pin configuration of that pins on the host system. Also, sometimes it is required the pull-up on the host pin for correct functionality 2. property-descriptor: Are used to pass named properties or named GPIOs to the host. The host system uses this information to properly configure specific board drivers by passing the properties and GPIO name. There can be multiple instances of property descriptors per add-on board manifest. 3. device-descriptor: Describes a device on the mikroBUS port. The device descriptor is a fixed-length descriptor, and there can be multiple instances of device descriptors in an add-on board manifest in cases where the add-on board presents more than one device to the host. New mikroBUS addon boards also sometimes contain a 1-wire EEPROM with the mikroBUS manifest, thus enabling plug and play support. I have also created PR to add mikrobus descriptors in Greybus spec and I think the old PR on manifesto by Vaishnav should also work. However, both of these repositories seem to be inactive. I am guessing the greybus mailing list can provide more information on how I should go about these. Here is a sample mikroBUS manifest: ``` ;; ; PRESSURE CLICK ; https://www.mikroe.com/pressure-click ; CONFIG_IIO_ST_PRESS ; ; Copyright 2020 BeagleBoard.org Foundation ; Copyright 2020 Texas Instruments ; [manifest-header] version-major = 0 version-minor = 1 [interface-descriptor] vendor-string-id = 1 product-string-id = 2 [string-descriptor 1] string = MIKROE [string-descriptor 2] string = Pressure [mikrobus-descriptor] pwm-state = 4 int-state = 1 rx-state = 7 tx-state = 7 scl-state = 6 sda-state = 6 mosi-state = 5 miso-state = 5 sck-state = 5 cs-state = 5 rst-state = 2 an-state = 1 [device-descriptor 1] driver-string-id = 3 protocol = 0x3 reg = 0x5d [string-descriptor 3] string = lps331ap ``` Link: https://www.mikroe.com/clickid ClickID Link: https://docs.beagleboard.org/latest/projects/beagleconnect/index.html beagleconnect Link: https://github.com/projectara/greybus-spec Greybus Spec Link: projectara/greybus-spec#4 Greybus Spec PR Link: projectara/manifesto#2 manifesto PR Co-developed-by: Vaishnav M A <vaishnav@beagleboard.org> Signed-off-by: Vaishnav M A <vaishnav@beagleboard.org> Signed-off-by: Ayush Singh <ayushdevel1325@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
mikroBUS is an add-on board socket standard by
MikroElektronika which provides high expandability
with the lowest number of pins used.
https://www.mikroe.com/mikrobus
The mikrobus linux kernel driver tries to make use of an
extended version of the greybus manifest to pass
the device driver specific information to the click device driver,
the manifest binary is expected to be stored on an on-board EEPROM
from where the mikroBUS driver fetches the contents and
enumerates the drivers.
This PR contains two commits, one for the changes introduced in
the manifesto tool and another one to add the manifest examples
for supported click boards. (https://www.mikroe.com/click)
Testing video for few Click Boards
Available at : https://www.youtube.com/watch?v=AjTHuikczW4