Mazaya

My Gallery

GSoC with RTEMS Final Blog: Add Support for Renode.io Simulator

Monday, 14 August 2023·5 min to read
GSoC with RTEMS Final Blog: Add Support for Renode.io Simulator

This is a summary of my journey in this year GSoC at RTEMS Project.

Project short description

This project is intended to help integrating Renode to RTEMS tools for enable testing various BSPs. This project main objectives are the following:

  • Getting BSPs to be tested using Renode simulator
  • Enables Renode to be installed via the RTEMS Source Builder
  • Document all the necessary things that is needed to use Renode in rtems-test

Repositories

There are 3 repositories that contains the changes that I do for this GSoC project.

List of work

This section will lists all the things that I do in this GSoC project.

Renode integration to rtems-test

This is the core of the GSoC project. Renode is a new simulator that is well-known to have a lot of IoT and SoC boards support, it will be very beneficial if there is a ground work that helps with researching and integrating Renode to be RTEMS's simulator because that means the rtems-test testsuites can be used to test any BSP that is supported by Renode.

The work that enable this to happen is the following implementations:

  • Shlex parser usage in splitting arguments
  • Pipe operation implementation in rtems-tools .cfg files
  • Some attempts of reading the showAnalyzer output of Renode which ended to be implemented in this patch. Full story on the attempts tried is listed on the previous blog.

In the end of this GSoC project, 2 BSP are enabled to be tested using Renode.

Renode's RSB recipe

To install renode, you can download the official package for debian, fedora, arch, macOS, and windows in the Renode website. The RTEMS Source Builder (RSB) is intended to ease the installation of software related to RTEMS. Not only that, the RSB installation is guaranteed to be using a release version of the software that is working with RTEMS ecosystem. That is why, one of the thing that I am worked on in this project is to provide the recipe to install Renode via the RSB. The patch to the work is available here.

Documentations

The ground work of implementing Renode testing into RTEMS tools is done, RTEMS users/developers are now able to add more testing configurations to test a particular BSP using Renode. The instruction to do so, is documented in the rtems-docs and the patch is sent to the developers for review. Other than that, because Renode is a software that is not installed together with any toolchain in the RTEMS ecosystem I have also added the documentation of the Renode installation using RSB in the patch.

The current state of the project

There are 3 things I consider a success in this project:

  • The ground work of enabling Renode to be used as rtems-test simulator is done, there are 2 BSP (Kendryte K210 and SPARC Leon3) that will be enabled to be tested using Renode after the final patch is merged.
  • The installation recipe is there and Chris said it is ready to be pushed.
  • The docs to help anyone who wanted to configure more test using Renode is also submitted.

About the patches itself, here are the list of them and their statuses:

What's left?

Configuring more BSP to be tested using Renode is something that can be done, the documentation is submitted and can be used as a guide to do so. Other than that, I don't see/know particularly what can be continued except maybe exploring more about Renode's feature and try to integrate that into the RTEMS tooling ecosystem.

One thing that is interesting but not related to renode is this thread I found in PlatformIO Github issue. Platformio has built-in support to use Renode’s debugger and is compatible with some other RTOS frameworks. One thing someone can do in the future is integrating RTEMS to PlatformIO.

Challenges and important things I learned

There are plenty of things I learned during the GSoC period. It is my first time contributing directly to a well-defined project in the open source realm. I learned that communication is a very vital part of doing open source work, a lot of the work me and my GSoC fellows require a quite intensive commmunication to the devel mailing lists.

Other than that, technical skill wise, there are lots of other things I learned and listing it might be quite tricky. But the hardest challenge in this GSoC project will be 2 things:

  • Understanding how the simulator in rtems-test works is very challenging, there is only a picture in the documentation that explain briefly what it does. That is reasonable because not often that someone will need to implement a new simulator to the rtems-tools repository.
  • Picking which method to be chosen for integrating Renode to rtems-test is also hard. There are plenty of ways to get Renode's showAnalyzer output mapped to the stdout. Exploring these options are quite frustrating and require me to open some issues in the Renode Github repository (full story on the mid term blog).

Those problems lead me to learn a lot of things about:

  • How important it is to know how to setup a proper debug session. Especially to explore a new source code and explore what it does in details.
  • The internals of how Renode works.
  • Using git format-patch and send-email as it is the first organization I worked with that use patch mailing list.
  • Socket server API and threading Python
  • How Renode manages organize the information of hardware peripherals
  • et cetera, there are plenty small things I learned during the way and listing it all up is kinda hard for me hehe

Closing

I have been having a great time contributing to RTEMS via this GSoC project. My mentors (Gedare, Alan, and Hesham) have been very helpful. I learned a lot of things and happy with the result. I am hoping to be able to contribute more in the future.