BeagleBoard/GSoC/2023 Proposal/AyushSingh
Contents
Proposal: Replace GBridge
About
Student: Ayush Singh
Mentors: Jason Kridner, Vaishnav
Wiki: BeagleConnect
GSoC: TBD
Status
This project is currently just a proposal.
Proposal
- Completed All the requirements listed on the ideas page.
- The PR request for cross-compilation task: #170
About you
IRC: @ayush1325:matrix.org
Github: Ayush1325
Blog: Programmer's Hideaway
Slack: Ayush1325
Gitlab: ayush1325
Discourse: ayush1325
School: Indian Institute of Technology (ISM), Dhanbad
Country: India
Primary language: English, Hindi
Typical work hours: 12PM - 01AM Indian Standard Time<be>
Previous GSoC participation: I have previously participated in GSoC 2022 for Tianocore Organization. I have been quite interested in working on the Linux Kernel, the biggest Open-Source project in the world, for a long time. While I have worked on low-level stuff like UEFI, I still haven’t contributed to upstream Linux. Initially, the barrier of entry was simply too high for me. After completing the GSoC 2022 project, I was more confident about working on upstream Linux. However, I couldn’t find strong enough motivation to drop my other open-source projects to work on Linux Kernel. With this project, I hope to change this and start contributing to upstream Linux. I am also quite interested in BeagleConnect and its implications in the Internet of Things applications. Thus I would like to help improve it.
About your project
Project name: Replace GBridge
Description
Overview
The goal of the project is to eliminate the need for GBridge completely and simplify the architecture of BeagleConnect. The current architecture is as follows:
Greybus <--Netlink--> GBridge <--wpanusb--> cc1532 <--6lowpan--> BeagleConnect
The new architecture will look as follows:
Greybus <--Platform Driver--> cc1532 <--6lowpan--> BeagleConnect
I have also created a Flow Chart for better visualization.
The subtasks I have identified are the following:
- Allow the Greybus Linux driver to directly communicate with cc1352
- Move SVC and APBridge roles into cc1352
- Eliminate the need for GBridge
GBridge Overview
To eliminate GBridge, we must first understand it's different parts. Thus I will discuss each part here in brief.
SVC
It is in charge of module hot plug / hot unplug detection, create / destroy connections, etc.
Netlink
GBridge is using netlink to communicate with Greybus.
Controller
The controller is actually the link between the SVC, netlink and all the modules. There are 4 main controllers present in GBridge currently:
- Bluetooth Controller: It scans continuously to detect new bluetooth module. When a Bluetooth module with the "GREYBUS" string in its name show up, the controller will generate an hotplug event and create a connection.
- TCP/IP: It use avahi to detect a new module.
- GBSHIM: It provides a way to test quickly and easily Greybus, Greybus netlink and gbridge.
- UART: This does not seem to be in the README, but is being registered if a `p` option is supplied.
Greybus Driver
Currently, the upstream Greybus driver uses netlink (which is added using a patch). However, netlink will not be needed since GBridge is being removed. Instead, a platform driver will be used to communicate directly with cc1352.
The actual types that are used in communication can be found at include/linux/greybus/greybus_protocols.h` in upstream Linux kernel. While there are many request and response types, all of them have a header with the following signature:
struct gb_operation_msg_hdr { __le16 size; /* Size in bytes of header + payload */ __le16 operation_id; /* Operation unique id */ __u8 type; /* E.g GB_I2C_TYPE_* or GB_GPIO_TYPE_* */ __u8 result; /* Result of request (in responses only) */ __u8 pad[2]; /* must be zero (ignore when read) */ };
Depending on the driver's choice, the data might need to be formatted in some specific way.
Platform Driver
This new driver will be responsible for communication between Greybus and cc1352. Since this will be a Platform Driver, it will follow the standard convention:
struct platform_driver { int (*probe)(struct platform_device *); int (*remove)(struct platform_device *); void (*shutdown)(struct platform_device *); int (*suspend)(struct platform_device *, pm_message_t state); int (*suspend_late)(struct platform_device *, pm_message_t state); int (*resume_early)(struct platform_device *); int (*resume)(struct platform_device *); struct device_driver driver; };
I have been studying up on OpenThread since it is supported by cc1352 and was suggested in Slack by Jason Kridner.
This will mostly be implemented in Rust as per the current plan. The driver will run on BeaglePlay although it should be possible to use on any host running Linux.
cc1352 Firmware
Most of the heavy lifting will be done by the cc1352 firmware. It now needs to take care of both the SVC and APBridge roles.
This will be running ZephyrRTOS. The functionality will be implemented as a Zephyr Module.
SVC Role
The cc1352 firmware will need to detect the hotplug and removal of modules. In the current architecture, each controller runs an event_loop in a pthread to carry out its functionality. In zephyr, I can see 2 ways to achieve something similar:
- Use threads: Since we can use compile parameters to determine which controllers to use, we can use K_THREAD_DEFINE to define the required threads at compile time. However, since zephyr is more constrained than a Linux host, I am not sure if this is the best implementation.
- Use Polling API: The hotplug detection portion of the controllers can be moved to a Polling API, which can be more efficient.
Currently, I will be focussing on TCPIP controller. I have been studying up on Multicast DNS since that is currently being used in the form of avahi. I will probably use a zeroconf (like avahi) based solution for this, but I am open to other suggestions.
APBridge Role
The cc1352 firmware will now translate communication to/from Linux Host (with Platform driver over USB) and the BCF Node (6lowpan). What this means is extracting the message from the format used by the platform driver, convert to a 6lowpan packet, and vice versa. Some of this is already implemented at wpanusb_bc.
The actual communication between Host and BeagleConnect can be implemented using Message Queues + Events.
Using Message Queues might be better than pipes and/or directly sending messages from the controller since the asynchronous operation of Message Queues in a multi-controller architecture might be more efficient.
Timeline
Date | Status | Details | |
---|---|---|---|
Presubmission |
|
||
May 4 - May 28 | Community Bonding |
I will be having exams till May 10th, so I will start being active after that, | |
May 28 | Milestone #1 |
| |
June 4th | Milestone #2 |
| |
June 11th | Milestone #3 |
| |
June 18th | Milestone #4 |
| |
June 25th | Milestone #5 |
| |
July 2nd | Milestone #6 |
| |
July 9th | Milestone #7 |
| |
July 14th | Milestone #8 (Mid-term Evaluation) |
| |
July 23th | Milestone #9 |
| |
July 30th | Milestone #10 |
| |
August 6th | Milestone #11 |
| |
August 13th | Milestone #12 |
| |
August 21th to 28th | Final Week |
| |
August 28 to September 4 | End of competition |
Mentors submit final student evaluations |
Experience and approach
I have a very good knowledge of Rust programming language in firmware development. I work a lot on `no_std` environments, i.e. environments where Rust standard library is not available due to some reason. I also have experience with Rust FFI for things like UEFI specification. I have some experience with C and C++ as well. Some of my previous projects include
- Rust UEFI std: PR for implementation of Rust std for UEFI. This project was initially done as a part of the Google Summer of Code 2022. However, at this point it has evolved into its own thing and I am still actively working on it.
- r-efi: UEFI Reference Specification Protocol Constants and Definitions in Rust. I am just one of the frequent contributors. This project requires deep knowledge of Rust FFI.
- kconfig-rs: Rust bindings for KConfig KDE Framework. This project was done as a part of the Season of KDE 2022.
- Qmetaobject: I am one of the collaborators in this project. It allows the creation of Qt applications in Rust.
I also regularly contribute to other open-source projects I am using at the time.
Contingency
If I get stuck on my project and my mentor isn’t around, I will use the following resources:
- Current Github Repos
- Linux Kernel mailing list (especially Greybus Subsystem)
- BeagleConnect Documentation
- Zeroconf
Benefit
The completed project would allow using BeagleConnect without requiring an intermediary (GBridge). Also, due to the presence of GBridge, the upstream Greybus drivers need to be patched for netlink support, which will be eliminated by this project. Thus, it will eventually be possible to just use mainline Linux kernel for BeagleConnect. This should help increase the adoption of BeagleConnect as an industry standard.