- 1 Clickboard Support Under Greybus
- 2 Status
- 3 Proposal
- 3.1 About me
- 3.2 About my project
- 3.2.1 Description
- 3.2.2 Timeline
- 22.214.171.124 Prior to Coding Period
- 126.96.36.199 Community Bonding Period: April 23 - May 13
- 188.8.131.52 Week 1: May 14 - May 20
- 184.108.40.206 Week 2: May 21 - May 27
- 220.127.116.11 Week 3: May 28 - June 3
- 18.104.22.168 Week 4: June 4 - June 10
- 22.214.171.124 Week 5: June 11 - June 17
- 126.96.36.199 Week 6: June 18 - June 24
- 188.8.131.52 Week 7: June 25 - July 1
- 184.108.40.206 Week 8: July 2 - July 8
- 220.127.116.11 Week 9: July 9 - July 15
- 18.104.22.168 Week 10: July 16 - July 22
- 22.214.171.124 Week 11 and 12: July 22 - Aug 5
- 3.2.3 Experience and approach
- 3.2.4 Contingency
- 3.2.5 Approach
- 3.2.6 Benefit
- bringing in Click Board Support via Manifests using Greybus Simulator, instead of device tree overlays
- modify the Greybus drivers and provide an userspace simulator based on GBSIM (Greybus Simulator)
- Create example manifests for several MikroElectronika click boards and provide documentation for creating and loading Greybus Simulator Manifest files.
Student: Vaishnav M A
Mentors: Jason Kridner
GSoC: Not Yet Submitted
This project aims to bring in Click board support starting from Greybus Simulator, I was able to install the Greybus Simulator on:
Linux beaglebone 4.1.38-bone24
BeagleBoard.org Debian Image 2018-10-07
During the installation I was facing some issues and was able to fix it by making simple changes to the Greybus Simulator Sources here : https://github.com/vaishnav98/gbsim/commit/aaf23e23dcaba53dbe9518f4a10318fde8cff293
Currently I am trying to fix the errors occurring while installing the greybus simulator and its dependencies on:
Linux beaglebone 4.14.71-ti-r80
This project is currently in the proposal stage.
The Hello World Application was Cross-Compiled(and tested using QEMU Emulator) and Pull Request #127 was generated.
IRC: vaishnav98_ || vaishnav98
School: College of Engineering,Trivandrum under Kerala Technological University
Primary language : English
Typical work hours : 11 AM-6:30 PM GMT (3:30 PM to 10:30 PM Indian Standard Time)
Can also switch to 3 AM-10:30 AM GMT (7:30 AM to 3:00 PM Indian Standard Time)
About my project
Project name : Clickboard Support Under Greybus
Click boards are a flagship hardware product line of MikroElektronika with over 600 add-on boards ranging from wireless connectivity clicks to Human Machine Interface clicks for interfacing with peripheral sensors or transceivers. Most of the Click boards use the common protocols like SPI,I2C or UART to communicate with the Beaglebone and thus the support for them now is accomplished via device tree overlays via the bb.org-overlays repository. This requires /boot/uEnv.txt to be modified to load the drivers at boot, requiring at least one reboot to enable the support in a potentially error-prone way, as modifying that file could prevent the image from booting. This makes the interfacing of the Click Boards with Pocketbeagle a tedious task and it would be better if there was a possibility of adding hot-plugging support for the click boards which would make the interfacing a lot easier.
The Greybus Simulator is a tool which simulates an AP Bridge, SVC, and an arbitrary set of Ara modules plugged into Greybus. Greybus already provides most of the interfaces used on click boards and utilizes manifest files to enumerate hardware at run-time. By using the simulator, similar functionality should be possible to achieve for these existing buses, rather than via true hot-swapping hardware.
The Greybus specification provides device discovery and description at runtime, network routing and housekeeping, and class and bridged PHY protocols, which devices use to talk to each other and to the processors. The following figure gives a glimpse of how various parts of the kernel interact with the Greybus subsystem.
The Greybus core implements the supervisory controller (SVC) protocol, which is used by the application processor (AP — the CPUs running Linux) to communicate to the SVC. The SVC represents an entity within the Greybus network that configures and controls the Greybus (UniPro) network, mostly based on the instructions from the AP. All module insertion and removal events are first reported to the SVC, which in turn informs the AP about them using the SVC protocol. The AP is responsible for administrating the Greybus network via the SVC.
During module initialization (after the module is detected on Greybus, here in our case the simulator emulates the device connection), the Greybus core parses the module's manifest, which describes the capabilities of the module and creates devices within the kernel to represent it.
Greybus Manifest Files
When a module is connected to the Greybus network, the AP starts enumerating its interfaces over CPort0. The AP fetches a block of data from the interfaces, called the interface manifest. The manifest is a data structure containing the manifest header along with a set of descriptors. The manifest allows the AP to learn about the capabilities of the interface and creates devices within the kernel to represent the interface.
Following is a simple example of a raw manifest file that represents an interface that supports a single audio bundle. The manifest file is converted into a binary blob using the Manifesto library.A minimal manifest file contains the manifest-header , interface-descriptor,string-descriptors,bundle-descriptor, function-descriptors(I2C,SPI,UART,GPIO,..) and c-port descriptors.
The Manifesto library is a simple tool to generate a Greybus manifest blob from a Python ConfigParser-style input file, when using with the Greybus Simulator it's possible to hot plug/unplug modules by simply copying or removing a conformant manifest blob file in the /path/to/hotplug-module directory
The Greybus Simulator is a tool which simulates an AP Bridge, SVC, and an arbitrary set of modules plugged into Greybus. Greybus Simulator successfully runs on the beaglebone backend( Linux beaglebone 4.1.38-bone24), it is possible to hot plug/unplug modules by simply copying or removing a conformant manifest blob file in the /path/to/hotplug-module directory. Thus we can enable Clickbus Support via Greybus Simulator by writing suitable Manifests according to the Clickboard Specifications, creating and copying the respective Manifest blobs to the /path/to/hotplug-module directory. Thus we can bring in click board support in a more convenient way without requiring a reboot each time when a new click is added as required when loading a device tree overlay for the click board.For writing the manifest i am planning to use the available Device Tree Overlays as reference to get a clear idea about the interfaces used by each click board.
I am planning to work on fixing the Greybus Simulator issues and then try to demonstrate a simple example for the clickbus support via GBSIM before proceeding to adding support for other click boards.
Prior to Coding Period
I will use this time to go through the entire codebase of Greybus Simulator, try to understand the Greybus specifications, the structure of the GBSIM Manifest files and the Manifest file generator. I will also try to use this period to fix the compilation/installation issues with GBSIM on Linux beaglebone 4.14.71-ti-r80(and recent kernel versions).
Community Bonding Period: April 23 - May 13
- Prepare the introduction video and start a blog to document the project progress.
- Testing and getting familiarized with the hardware
- Make changes to some of the goals according to mentors’ opinion
- Fix timings for periodic meeting with mentors
- Discuss about Documentation Guidelines to be Followed
Week 1: May 14 - May 20
Week 2: May 21 - May 27
Week 3: May 28 - June 3
Week 4: June 4 - June 10
At the end of Phase I , i will be able to deliver :
Week 5: June 11 - June 17
Week 6: June 18 - June 24
Week 7: June 25 - July 1
Week 8: July 2 - July 8
By the end of Phase II , I will be able to Deliver
Week 9: July 9 - July 15
Week 10: July 16 - July 22
Week 11 and 12: July 22 - Aug 5
Experience and approach
I am a Third year undergraduate pursuing Electronics and Communication Engineering, I have enough experience working with BeagleBone and other Embedded Linux based boards. I have successfully completed GSoC 2018 under Beagleboard.org Foundation : Fixing Bugs in BoneScript and Improve BeagleBone UI
I have also some experience in Linux Kernel Module development and cross-compiling which will be useful for the project. I have tried to go through the Greybus Simulator sources and have a basic understanding of the project.
pxt-beaglebone – Makecode Beaglebone a Makecode Blocks editor for Beaglebone Boards
My Works(all uploaded on my Github Repository):
If I get stuck and if my mentor isn’t around , I’ll try to search the internet for similar issues and try to solve the particular issue that cannot be solved with my knowledge, so even if my mentors are not available for a short period of time, it won't much affect the quality of my work, If I am not able to find the solution to a problem by searching, going through forums, IRC and mailing lists, I will try to proceed my work by focussing on documenting the finished work and creating demonstration videos.
I don't have any other commitments during my vacation, so I can devote about 7-9 hours a day, i.e. around 50 hours a week to achieve my milestones. I am willing to spend more time if I am not able achieve any of the targets set by me.
MikroElektronika Click boards are a wonderful piece of hardware which can be used for interfacing with peripheral sensors or transceivers. There are over 600 add-on click boards from wireless connectivity clicks to Human Machine Interface clicks which could take PocketBeagle projects to the next level. Unfortunately, the current method of adding support for click boards through device tree overlays require /boot/uEnv.txt to be modified to load the drivers at boot, requiring at least one reboot to enable the support in a potentially error-prone way thus making it a tedious task. However, through the Greybus simulator which offers most of the interfaces used by click boards, hardware enumeration can be performed by utilizing manifest files (i.e. just by copying a manifest blob to the simulator hot-plug directory) thus achieving similar functionality for these existing buses, rather than via true hot-swapping hardware. The progress in this project can also help in adding support for various Click modules to TechLab Cape.
Some of comments mentioning the importance of this project are given below:
Mentor Jason Kridner on Beagleboard-GSoC google groups in the project ideas introduction mail
I'm really thinking there is a lot of fun around Greybus to have. By using the simulator, similar functionality should be possible to achieve for these existing buses, rather than via true hot-swapping hardware.
As Project Ara is discontinued now, it would be quite interesting to find new targets (like the Internet of Things) for the Greybus subsystem and adapt Greybus to support them.