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

From eLinux.org
Jump to: navigation, search
(Experience and approach)
(Timeline)
 
(29 intermediate revisions by the same user not shown)
Line 3: Line 3:
 
[[Category: GSoCProposal2023]]
 
[[Category: GSoCProposal2023]]
  
=[[BeagleBoard/GSoC/2023 Proposal/AyushSingh]] =
+
=[[BeagleBoard/GSoC/2023_Proposal/AyushSingh|Proposal: Replace GBridge]] =
 
About
 
About
 
''Student'': [https://elinux.org/User:Ayush1325 Ayush Singh]<br>
 
''Student'': [https://elinux.org/User:Ayush1325 Ayush Singh]<br>
Line 21: Line 21:
 
''IRC'': [https://matrix.to/#/@ayush1325:matrix.org/ @ayush1325:matrix.org]<br>
 
''IRC'': [https://matrix.to/#/@ayush1325:matrix.org/ @ayush1325:matrix.org]<br>
 
''Github'': [https://github.com/Ayush1325 Ayush1325]<br>
 
''Github'': [https://github.com/Ayush1325 Ayush1325]<br>
 +
''Blog'': [https://www.programmershideaway.xyz/ Programmer's Hideaway]<br>
 +
''Slack'': Ayush1325<br>
 +
''Gitlab'': [https://git.beagleboard.org/ayush1325 ayush1325]<br>
 +
''Discourse'': [https://forum.beagleboard.org/u/ayush1325/summary ayush1325]<br>
 
''School'': [https://www.iitism.ac.in/iitismnew/ Indian Institute of Technology (ISM), Dhanbad]<br>
 
''School'': [https://www.iitism.ac.in/iitismnew/ Indian Institute of Technology (ISM), Dhanbad]<br>
 
''Country'': India<br>
 
''Country'': India<br>
 
''Primary language'': English, Hindi<br>
 
''Primary language'': English, Hindi<br>
''Typical work hours'': 12PM - 01AM Indian Standard Time<br>
+
''Typical work hours'': 12PM - 01AM Indian Standard Time<be>
 +
 
 
''Previous GSoC participation'': I have previously participated in [https://summerofcode.withgoogle.com/archive/2022/projects/PwQlcngc 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.
 
''Previous GSoC participation'': I have previously participated in [https://summerofcode.withgoogle.com/archive/2022/projects/PwQlcngc 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.
  
Line 41: Line 46:
 
Greybus <--Platform Driver--> cc1532 <--6lowpan--> BeagleConnect
 
Greybus <--Platform Driver--> cc1532 <--6lowpan--> BeagleConnect
 
</pre>
 
</pre>
 +
 +
I have also created a [https://drive.google.com/file/d/1oBRAVORr8Oqz8kXEYZF5lc2H0qVKA0RB/view?usp=share_link Flow Chart] for better visualization.
  
 
The subtasks I have identified are the following:
 
The subtasks I have identified are the following:
Line 60: Line 67:
 
# UART: This does not seem to be in the README, but is being registered if a `p` option is supplied.
 
# UART: This does not seem to be in the README, but is being registered if a `p` option is supplied.
  
====Greybus Driver====
+
====Greybus Serdev Driver====
Currently, the upstream Greybus driver uses netlink (which is added using a [https://git.beagleboard.org/beagleconnect/freedom/-/blob/master/sw/linux/0006-greybus-add-gb_netlink-patch.patch patch]). However, netlink will not be needed since GBridge is being removed. Instead, a platform driver will be used to communicate directly with cc1352.
+
This new driver will be responsible for communication between Greybus and cc1352. This will be a Serial Device Bus Driver (serdev) driver with the following structure:
 
 
The actual types that are used in communication can be found at [https://github.com/torvalds/linux/blob/master/include/linux/greybus/greybus_protocols.h '''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:
 
  
 
<pre>
 
<pre>
struct gb_operation_msg_hdr {
+
struct serdev_device_driver {
__le16 size; /* Size in bytes of header + payload */
+
struct device_driver driver;
__le16 operation_id; /* Operation unique id */
+
int (*probe)(struct serdev_device *);
__u8 type; /* E.g GB_I2C_TYPE_* or GB_GPIO_TYPE_* */
+
void (*remove)(struct serdev_device *);
__u8 result; /* Result of request (in responses only) */
 
__u8 pad[2]; /* must be zero (ignore when read) */
 
 
};
 
};
 
</pre>
 
</pre>
  
Depending on the driver's choice, the data might need to be formatted in some specific way.
+
The actual types that are used in communication can be found at [https://github.com/torvalds/linux/blob/master/include/linux/greybus/greybus_protocols.h '''include/linux/greybus/greybus_protocols.h`'''] in upstream Linux kernel.
 +
 
 +
The driver will run on [https://www.beagleboard.org/boards/beagleplay BeaglePlay's] AM62 processor, although it should be possible on any Linux host.  
  
====Platform Driver====
+
The two main functions of this driver are as follows:
This new driver will be responsible for communication between Greybus and cc1352. Since this will be a [https://docs.kernel.org/driver-api/driver-model/platform.html Platform Driver], it will follow the standard convention:
+
=====probe=====  
 +
This step will involve the following:
 +
* Initialize stuff: This includes Work Queue, spin locks and allocate read/write buffers.
 +
* Open the serial device. Set parameters such as the baudrate. Mostly copy the configuration from bcfserial.
 +
* Create gb_host_device.
  
<pre>
+
Since we only want to use a single static UART (between AM62 and CC1352), we can optimize the driver probe.
struct platform_driver {
+
 
      int (*probe)(struct platform_device *);
+
=====remove=====
      int (*remove)(struct platform_device *);
+
* Flush the contents of the work queue.
      void (*shutdown)(struct platform_device *);
+
* Close the serdev 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;
 
};
 
</pre>
 
  
 
====cc1352 Firmware====
 
====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.
+
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 on BeaglePlay's CC1352 processor.
 +
 
 +
This will be running ZephyrRTOS. The functionality will be implemented as a [https://docs.zephyrproject.org/3.1.0/develop/modules.html Zephyr Module].
 +
 
 +
While I am writing about SVC Role and APBridge Role separately, the implementation would not really have any rigid separation. The SVC and AP terminology is from the Project Ara days when these used to be physically separate entities.  
  
 
=====SVC Role=====
 
=====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:  
+
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. The approach I am currently thinking of is as follows:
# Use [https://docs.zephyrproject.org/latest/kernel/services/threads/index.html threads]: Since we can use compile parameters to determine which controllers to use, we can use [https://docs.zephyrproject.org/latest/kernel/services/threads/index.html#c.K_THREAD_DEFINE 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.
+
# Run a loop in a separate thread that polls for `_greybus._tcp`.
# Use [https://docs.zephyrproject.org/latest/kernel/services/polling.html Polling API]: The hotplug detection portion of the controllers can be moved to a Polling API, which can be more efficient.
+
# Maintain a table of nodes.
 +
# Compare the polled devices against the table for new/removed nodes.
 +
# Handle new devices and free removed device resources.
 +
 
 +
Initially, I plan on implementing a basic version using [https://docs.zephyrproject.org/3.2.0/kernel/services/threads/index.html threads]. However, if I have time, I will try to write a more efficient implementation using the [https://docs.zephyrproject.org/3.2.0/kernel/services/polling.html Polling API].
  
 
=====APBridge Role=====
 
=====APBridge Role=====
This role involves converting UART to something like TCP/IP, which can be implemented in cc1352. The actual communication between Host and BeagleConnect can be implemented using [https://docs.zephyrproject.org/latest/kernel/services/data_passing/message_queues.html#message-queues Message Queues] + [https://docs.zephyrproject.org/latest/kernel/services/synchronization/events.html Events].
+
The cc1352 firmware will now also be responsible for the APBridge role, which is currently handled by GBridge. This role involves a variety of tasks:
 +
*Reading/Writing Greybus messages over 6lowpan and generating messages to send to host.
 +
*Installing/Uninstalling greybus interfaces on insertion/removal after receiving an event from SVC.
 +
*Get Device manifest on insertion.
 +
*Sending events to register drivers, etc
  
I think 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.
+
The actual communication between Host and BeagleConnect can be implemented using [https://docs.zephyrproject.org/latest/kernel/services/data_passing/message_queues.html#message-queues Message Queues] + [https://docs.zephyrproject.org/latest/kernel/services/synchronization/events.html 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===
 
===Timeline===
Line 110: Line 126:
 
|-
 
|-
 
! Date !! Status !! Details
 
! Date !! Status !! Details
|-
 
| Presubmission || ||
 
*Setup zephyr environment and build a board for native POSIX execution
 
*Blink an LED using Linux, Zephyr and Greybus
 
|
 
 
|-
 
|-
 
| May 4 - May 28 || Community Bonding ||
 
| May 4 - May 28 || Community Bonding ||
I will be having exams till May 10th, so I will start being active after that,
+
*I will be having exams till May 10th, so I will start being active after that.
 +
*Introduction Video.
 +
*Required hardware will be available to me.
 +
*Setup BeaglePlay and BeagleConnect Freedom.
 
|-
 
|-
 
| May 28 || Milestone #1 ||  
 
| May 28 || Milestone #1 ||  
*Required hardware will be available to me, and I will start flashing Zephyr on Beagleconnect Freedom
+
*Run some samples on the two boards.
*Start going through the documentation and datasheet of the hardware available.
+
*Write a Hello World Linux Driver for BeaglePlay.
 +
*Setup workflow to deploy to driver from Linux host.
 
|-
 
|-
 
| June 4th || Milestone #2 ||  
 
| June 4th || Milestone #2 ||  
*Introduction Video
+
*Start work on serdev Linux Driver.
*Start work on platform driver for communication between Greybus and cc1352.
+
*Start work on Zephyr Module For CC1352.
 
|-
 
|-
 
| June 11th || Milestone #3 ||  
 
| June 11th || Milestone #3 ||  
*Start testing communication between Greybus and cc1352 using new platform driver.
+
*Start testing communication between serdev driver running on AM62 with Zephyr Module on CC1352.
*Start with Module Insert Event.
+
*The communication will just be simple messages (not Greybus stuff)
 
|-
 
|-
 
| June 18th || Milestone #4 ||  
 
| June 18th || Milestone #4 ||  
*Implement APBridge role for cc1352.
+
*Start implementing greybus stuff. This will involve creating gb host device, sending/reciveing greybus messages, cleaning up greybus stuff on remove, etc.
 +
*This involves implementing async processing of greybus requests and responses over the socket.
 +
*Also add parsing for greybus manifest.
 
|-
 
|-
 
| June 25th || Milestone #5 ||
 
| June 25th || Milestone #5 ||
*Write tests that APBridge role is working as intended
+
*Implement a table to keep track of all nodes and their cports.
 +
*Implement the SVC role for cc1352.
 +
*This involves implementing all control operations.
 
|-
 
|-
 
| July 2nd || Milestone #6 ||  
 
| July 2nd || Milestone #6 ||  
*Start work on implementing the SVC role for cc1352.
+
*Implement APBridge role for cc1352.
*Write generic code used by all controllers.
+
*Use HDLC for UART communication.
 +
*Also implement MCUmgr over HDLC
 
|-
 
|-
 
| July 9th || Milestone #7 ||  
 
| July 9th || Milestone #7 ||  
*Implement TCPIO controller.
+
*Write some tests for SVC Role.
 +
*Also run the tests in CI.
 
|-
 
|-
 
| July 14th || Milestone #8 (Mid-term Evaluation) ||  
 
| July 14th || Milestone #8 (Mid-term Evaluation) ||  
 +
*Write tests that APBridge role is working as intended.
 +
*Also run the tests in CI.
 +
|-
 +
| July 23th || Milestone #9 ||
 
*Start testing all the 3 components (Greybus Linux driver, cc1352 and BeagleConnect) together.
 
*Start testing all the 3 components (Greybus Linux driver, cc1352 and BeagleConnect) together.
 
*Iron out bugs.
 
*Iron out bugs.
 
|-
 
|-
| July 23th || Milestone #9 ||  
+
| July 30th || Milestone #10 ||  
*Implement Bluetooth controller.
 
 
*Submit upstream PR for the new Platform Driver.
 
*Submit upstream PR for the new Platform Driver.
|-
 
| July 30th || Milestone #10 ||
 
*Implement UART controller
 
 
|-
 
|-
 
| August 6th || Milestone #11 ||  
 
| August 6th || Milestone #11 ||  
Line 187: Line 208:
 
* Linux Kernel mailing list (especially [https://github.com/torvalds/linux/blob/a1effab7a3a35a837dd9d2b974a1bc4939df1ad5/MAINTAINERS#L8833 Greybus Subsystem])
 
* 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]
 
* [https://docs.beagleboard.org/latest/boards/beagleconnect/technology/index.html BeagleConnect Documentation]
 +
* [http://www.zeroconf.org/ Zeroconf]
  
 
===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.

Latest revision as of 09:07, 5 July 2023


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:

  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

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:

  1. 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.
  2. TCP/IP: It use avahi to detect a new module.
  3. GBSHIM: It provides a way to test quickly and easily Greybus, Greybus netlink and gbridge.
  4. UART: This does not seem to be in the README, but is being registered if a `p` option is supplied.

Greybus Serdev Driver

This new driver will be responsible for communication between Greybus and cc1352. This will be a Serial Device Bus Driver (serdev) driver with the following structure:

struct serdev_device_driver {
	struct device_driver driver;
	int	(*probe)(struct serdev_device *);
	void	(*remove)(struct serdev_device *);
};

The actual types that are used in communication can be found at include/linux/greybus/greybus_protocols.h` in upstream Linux kernel.

The driver will run on BeaglePlay's AM62 processor, although it should be possible on any Linux host.

The two main functions of this driver are as follows:

probe

This step will involve the following:

  • Initialize stuff: This includes Work Queue, spin locks and allocate read/write buffers.
  • Open the serial device. Set parameters such as the baudrate. Mostly copy the configuration from bcfserial.
  • Create gb_host_device.

Since we only want to use a single static UART (between AM62 and CC1352), we can optimize the driver probe.

remove
  • Flush the contents of the work queue.
  • Close the serdev device

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 on BeaglePlay's CC1352 processor.

This will be running ZephyrRTOS. The functionality will be implemented as a Zephyr Module.

While I am writing about SVC Role and APBridge Role separately, the implementation would not really have any rigid separation. The SVC and AP terminology is from the Project Ara days when these used to be physically separate entities.

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. The approach I am currently thinking of is as follows:

  1. Run a loop in a separate thread that polls for `_greybus._tcp`.
  2. Maintain a table of nodes.
  3. Compare the polled devices against the table for new/removed nodes.
  4. Handle new devices and free removed device resources.

Initially, I plan on implementing a basic version using threads. However, if I have time, I will try to write a more efficient implementation using the Polling API.

APBridge Role

The cc1352 firmware will now also be responsible for the APBridge role, which is currently handled by GBridge. This role involves a variety of tasks:

  • Reading/Writing Greybus messages over 6lowpan and generating messages to send to host.
  • Installing/Uninstalling greybus interfaces on insertion/removal after receiving an event from SVC.
  • Get Device manifest on insertion.
  • Sending events to register drivers, etc

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
May 4 - May 28 Community Bonding
  • I will be having exams till May 10th, so I will start being active after that.
  • Introduction Video.
  • Required hardware will be available to me.
  • Setup BeaglePlay and BeagleConnect Freedom.
May 28 Milestone #1
  • Run some samples on the two boards.
  • Write a Hello World Linux Driver for BeaglePlay.
  • Setup workflow to deploy to driver from Linux host.
June 4th Milestone #2
  • Start work on serdev Linux Driver.
  • Start work on Zephyr Module For CC1352.
June 11th Milestone #3
  • Start testing communication between serdev driver running on AM62 with Zephyr Module on CC1352.
  • The communication will just be simple messages (not Greybus stuff)
June 18th Milestone #4
  • Start implementing greybus stuff. This will involve creating gb host device, sending/reciveing greybus messages, cleaning up greybus stuff on remove, etc.
  • This involves implementing async processing of greybus requests and responses over the socket.
  • Also add parsing for greybus manifest.
June 25th Milestone #5
  • Implement a table to keep track of all nodes and their cports.
  • Implement the SVC role for cc1352.
  • This involves implementing all control operations.
July 2nd Milestone #6
  • Implement APBridge role for cc1352.
  • Use HDLC for UART communication.
  • Also implement MCUmgr over HDLC
July 9th Milestone #7
  • Write some tests for SVC Role.
  • Also run the tests in CI.
July 14th Milestone #8 (Mid-term Evaluation)
  • Write tests that APBridge role is working as intended.
  • Also run the tests in CI.
July 23th Milestone #9
  • Start testing all the 3 components (Greybus Linux driver, cc1352 and BeagleConnect) together.
  • Iron out bugs.
July 30th Milestone #10
  • Submit upstream PR for the new Platform Driver.
August 6th Milestone #11
  • Test the completed setup and make some performance optimizations.
August 13th Milestone #12
  • Make any suggested changes to different PRs.
August 21th to 28th Final Week
  • Submit final work product and final mentor evaluation
  • Complete YouTube video
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

  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.