Upstream Greybus module for Zephyr

Google Summer of Code
1

Introduction

Currently, greybus module for zephyr is a out of tree Zephyr module to bring Greybus support to Zephyr. This makes it hard to maintain, and makes it almost impossible for other people to test and contribute.

The goal of the project is to get greybus and BeagleConnect Technology ecosystem to a point that is easier to test and maintain. It can be considered a continuation of Replace GBridge Project from 2023

Basic Goals

  • Clean up and revive the testing infrastructure already present in module.
  • Make MikroBUS manifest optional. Since MikroBus manifest is not officially part of the Greybus spec, the current module will not work without a modified kernel even if we are not using MikroBUS boards.
  • Upstream the module as an official Zephyr module
  • Use greybus abstractions from the module in greybus-host firmware

Hardware Skills: basic wiring
Software Skills: device-tree, C, ZephyrRTOS, Linux, TCP.
Possible Mentors: @ayush1325 , @jkridner ,
Expected size of project: 350 hour
Rating: medium

Resources

1 Like
2

Hello @ayush1325 ,

I am interested in contributing to this project and would love to get started. From what I understand, the goal is to upstream the Greybus module for Zephyr, clean up the existing testing infrastructure, and make MikroBUS manifest optional. This would make it easier for developers to maintain and contribute to the project.

I have experience in embedded systems and C programming and have worked with STM32 (L476RG), handling various communication protocols. Additionally, I have explored AI/ML models and their deployment on edge devices, and I am eager to expand my knowledge of Zephyr RTOS and Kernel Development through this project.

Since I was looking for a good Zephyr RTOS project, this one looks interesting, and I would like to start contributing. I would appreciate any guidance on how to begin. Are there any initial tasks I should look into? Should I start by exploring the current Greybus module and its testing infrastructure, or are there other areas you recommend?

Looking forward to your guidance and excited to contribute!

Best,
Sahil Jaiswal

3

For initial tasks, you can just try the following:

  1. Get familiar with Zephyr if you are not already. If you have any supported board (does not need to be a BeagleBoard) just try playing around with zephyr and get a feel for things. You can also use the qmeu targets, or I think there are other emulated targets, in case you do not have a board.
  2. Cleaning up unnecessary stuff in the source. It was originally ported from Nuttx (I think), and probably still contain stuff that we can substitute with Zephyr provided stuff. I think I did some cleanup last year.
  3. Explore Zephyr device tree side of things. You will be interacting with it a lot in greybus module.
  4. Look at how Zephyr twister tests run since that is what we will need to use to run tests.
4

Ok I will go through all this tasks and give you a update…

5

I have successfully set up Zephyr, installed the SDK, and built/running samples using QEMU. I explored different targets and tested basic applications.

Now, I am moving on to cleaning up unnecessary legacy components in the source code. I will identify and replace any Nuttx-specific elements with Zephyr-native implementations where applicable. I’ll also verify functionality by testing after modifications.

Let me know if there are any specific areas I should focus on or any guidance on potential components that may still have legacy dependencies.