Difference between revisions of "BeagleBoard/GSoC/2023 Proposal/AyushSingh"

From eLinux.org
Jump to: navigation, search
(Benefit)
(Contingency)
Line 80: Line 80:
  
 
===Contingency===
 
===Contingency===
If I get stuck on my project and my mentor isn’t around, I will do the following based on which part of project I am stuck at:
+
If I get stuck on my project and my mentor isn’t around, I will use the following resources:
====Greybus Driver====
+
* Current Github Repos
Since the drivers are present in mainline Linux Kernel, I will approach the Kernel Mailing list, and especially contact (CC) the [https://docs.kernel.org/process/maintainers.html?highlight=greybus maintainers] of different parts of Greybus.
+
** [https://git.beagleboard.org/beagleconnect/linux/greybus Greybus]
 
+
** [https://git.beagleboard.org/beagleconnect/linux/gbridge GBridge]
====cc1532====
+
** [https://git.beagleboard.org/beagleconnect/freedom BeagleConnect Freedom]
TODO
+
* Linux Kernel mailing list (especially [https://github.com/torvalds/linux/blob/a1effab7a3a35a837dd9d2b974a1bc4939df1ad5/MAINTAINERS#L8833 Greybus Subsystem])
 
+
* [https://docs.beagleboard.org/latest/boards/beagleconnect/technology/index.html BeagleConnect Documentation]
====GBridge====
 
TODO
 
  
 
===Benefit===
 
===Benefit===
 
The completed project would allow using [https://docs.beagleboard.org/latest/boards/beagleconnect/technology/index.html 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.
 
The completed project would allow using [https://docs.beagleboard.org/latest/boards/beagleconnect/technology/index.html 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.

Revision as of 12:10, 22 March 2023


BeagleBoard/GSoC/2023 Proposal/AyushSingh

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
School: Indian Institute of Technology (ISM), Dhanbad
Country: India
Primary language: English, Hindi
Typical work hours: 12PM - 01AM Indian Standard Time
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<be>

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

The subtasks I have identified are the following:

  1. Allow the Greybus Linux driver to directly communicate with cc1352
  2. Move SVC and APBridge roles into cc1352
  3. Eliminate the need for GBridge

Greybus Driver

The Greybus driver just has to format the data and send it to cc1532. As such, it will not need any heavy modification. Thus the amount of work that needs to be upstreamed here should be minimal. All the work here will be done in C.

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. At the same time, the `wpanusb` communication will be removed since GBridge is no longer present.

Since the complexity of cc1352 firmware will increase in the new architecture, I would like to write the new code in Rust instead of C. I am planning on only using `core` + `alloc`, and not the full Rust std. Rust's benefits in this scenario are as follows:

  1. Rapid prototyping and testing due to its rich type system. The Rust type system is much more expressive than C and thus allows stricter guarantees on the compilation.
  2. Potentially better performance for the APBridge side of things. While the performance of Rust and C is comparable, the APBridge conversions can be done using `serde`, which can make it much more performant than any normal C implementation.
  3. Memory Safety: This is the property Rust is mainly known for.

With all that being said, I am open to implementing everything in C if that would be preferable.

SVC

The cc1352 firmware will need to detect the hotplug and removal of modules. I am thinking about sticking to avahi since I do not have any better solutions for now.

If we are using Rust, then avahi-sys bindings exist. It might also be possible to use mdns-sd if it is more suitable for our needs.

APBridge

This role basically involves converting UART to something like TCP/IP, which can be implemented in cc1352. I will try to make the parts as modular as possible (to add more transport protocols in the future), but I will be sticking to TCP/IP for now.

If I am using Rust, I will be using serde, unless it is not suitable while trying to write the implementation.

Timeline

TODO

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

  1. 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.
  2. 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.
  3. kconfig-rs: Rust bindings for KConfig KDE Framework. This project was done as a part of the Season of KDE 2022.
  4. 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:

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.