Upstream Zephyr Support on BBAI-64 R5

Google Summer of Code
1

Goal: Upstream Zephyr RTOS support of the R5 core in the J721E SoC
Hardware Skills: ARM Cortex R5
Software Skills: C, RTOS
Possible Mentors: @Nishanth_Menon , @dhruvag2000
Expected Size of Project: 350 hrs
Rating: Medium
Upstream Repository: GitHub - zephyrproject-rtos/zephyr: Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.
References:

2 Likes
2

Hello @dhruvag2000, could you help suggesting how to proceed further in this.
I have experience working with Zephyr but not with providing board support and such

3

Hi @malto101 ,
Here’s reference to last year’s project gist page: GSoC 2023 Final Report.md · GitHub

Please refer to it and you can find the PR’s that are still pending and not merged upstream.
Other than that we also hope to add more drivers support like perhaps mailbox / TI-SCI and be able to run basic IPC examples with the Linux cores, and also have the ability for the R5 cores to talk to the Device Manager to turn on/off or request clocks to certain controllers that it wishes to use.

I suggest that with these tasks in mind you start writing your proposal in the format mentioned here:
https://gsoc.beagleboard.io/guides/proposal.html#gsoc-proposal-guide

1 Like
4

Hello @dhruvag2000,

I took a look at the work you shared with me on Discord regarding adding Zephyr support for BBAI64, as well as the PRs created by Prashanth last year. Additionally, I completed the “getting started” section of Zephyr projects.

While reviewing every PR, I gained a basic understanding of how to add support for boards. However, I still need more guidance on how to do it from scratch. Could you please assign me a task that would help me understand how to add board support from scratch?

5

Have you looked in the git history of Zephyr to see commits that have added a new board? I think looking at the format of the commits is the best guide, plus, there is specific documentation on the process. I’ll leave it for you to find those resources.

Before starting to code, I think surveying all of the comments on the various pull requests and summarizing the steps that must be completed here would show that you are able to participate meaningfully. Ultimately, I’ll be looking for 3 things just to get the project defined.

  1. A more fleshed out list of objectives and mentor engagement on those
  2. A merge request for the idea to the gsoc ideas page
  3. A merge request for a proposal to the gsoc proposals (as @dhruvag2000 suggested … this doesn’t need to wait for 1 and 2 to be completed, but can be done in parallel)

The merge requests will show us that you are able to work within our GitLab-based CI infrastructure.

BTW, if you want to contribute to Zephyr upstream, you’ll need to fork the original Zephyr repo on Github. We’ll want to mirror that repo on OpenBeagle.org. The mirror would update in the direction of OpenBeagle → Github.

2 Likes
6

Is that site being used for anything? Just logged in and all I see is blank. How do I find what is active?

git-lab-blank
git-lab-blank1533Ă—681 58.8 KB

7

Click on “public projects”, you will be able to find all the existing repo related to beagleboard.
For Zephyr, you could this link: Zephyr · GitLab

1 Like
8

Thank you.

9

Thank you for your assistance! Yes, I have reviewed the git history and will now examine the format of the commits and refer to the documentation as needed. And also I’ll make a list of what needs to be done based on the comments on past pull requests and summarize that all here.

  1. I will create a list of objectives by discussing with mentors.
  2. Can you please explain how to create a merge request for the idea to the GSoC ideas page?
  3. I will begin writing my proposal in parallel.

I’ll keep you updated on my progress.

10

Hello @jkridner @dhruvag2000
I have created a list of things that need to be completed based on the PR commits survey:

  • The commit message bit more descriptive it will help reviewers.
  • There is a need to submit an RFC proposal which describing the full scope of change and future work. The RFC proposal provides the required context to reviewers, but allows for smaller, incremental, PRs to get reviewed and merged into the project.
  • West flash must be implemented and tested before adding PR.

@dhruvag2000 @Nishanth_Menon (Mentors) I have also created a list of objectives of this project. Please let me know if there is anything else that needs to be addressed. Here are the objectives that have been covered in the proposal:

List of the objectives:

  • Merge unmerged PR’s.
  • Add peripheral support for more drivers (ADC, I2C, and SPI have been included in the proposal).
  • Include support for mailbox, TI-SCI, IPC (to run basic IPC examples with the Linux cores).
  • Add support for the R5 cores to communicate with the Device Manager to control the clock.

Proposal link:
Please review my proposal here. Can you kindly provide your feedback and let me know if any changes are required? I would also appreciate if you could share your expectations regarding the proposal.
Thank you.

11

Hi Suraj!

Thanks for submitting the proposal, It’s off to a good start, but a few suggestions to consider:

  1. In the “Implementation Details” section, I don’t think you will need to write the board YAML and device tree from scratch because most of the heavy lifting has been done in this PR right? The only relevant part I see in that section is Add Flash and debug support. This I think was left toward the end of the project.

  2. ** Driver developement** section has alot of detail about devicetree. Always remember, devicetree is just hardware description and never should talk about any software or driver level details. Hence putting DT stuff under this section feels wrong to me. I suggest a different section for driver details and different one for DT details. Also, s/ **API Definations**/ **API Definitions** :wink:

  3. Overall I don’t see much details about how you’re going to be writing the drivers, maybe expand a bit more on that.

  4. Understanding TI-SCI: doesn’t feel like just a 1 week activity to me :slight_smile: I think it will eat up a pretty sizeable chunk of this project. I suggest you carefully read about TISCI, how the transport layer works and what drivers you’ll actually need to write to implement TISCI. You’ll uncover how much you really need to ramp up and then take a call on rest of the goals and timeline. I would suggest not leaving much to ramp up during the project phase and thus I would really like to see more details on how you pan to add TISCI support as part of your proposal itself. What would be the IPs involved, what drivers will you need, will you be able to leverage any existing frameworks in zephyr?

  5. I also suggest you start working on studying the unmerged pull requests ASAP, and not keep only Milestone #2 (June 10th) for it. Upstreaming anything is a time consuming activity and you’ll need to develop community engagement and a good effort estimate to see how things will go. Start working on this as soon as the community engagement period starts. Don’t wait for first milestone/ first week of coding period.

12

All other contributors looking to participate in this project idea, humble request to start posting your proposal PR’s and proposal links on this forum ASAP. Mentors will not be able to hunt on discord for proposal links and this forum thread acts as a good way to keep track of all activities related to this idea.

Thanks.

13

Hello @dhruvag2000 @Nishanth_Menon
Could you please appraise my proposal and provide any feedback.

14

HI @malto101 ,

Similar feedback on TISCI, please read through what TISCI is and how it works, how are the messages actually sent to the Device Manager. You cana lso go through existing kernel, trusted firmware ARM drivers to understand more. Pleas revise timeline accordingly and add more details for the same.

I can see that you’ve covered rpmsg and remoteproc well but don’t see much details on TISCI

1 Like
15

Thank you for the brief suggestions. I will make the suggested changes and start working on studying the unmerged PRs.

16

I got SPI and EPWM working from an R5. If you need help with that you can reach out to me. I have been meaning to add to the R5 example on openbeagle.org, have not gotten to it yet

2 Likes
17

Yes sure. Thanks!