
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.

- [The rtems-tools repository](https://github.com/MSMazaya/rtems-tools/tree/add-renode-implementation), you can see the changes [here](https://github.com/RTEMS/rtems-tools/compare/master...MSMazaya:squashing_renode_implementation)
- [The rtems-source-builder repository](https://github.com/MSMazaya/rtems-source-builder/tree/add-renode-recipe), you can see the changes [here](https://github.com/RTEMS/rtems-source-builder/compare/master...MSMazaya:rtems-source-builder:add-renode-recipe)
- [The rtems-docs repository](https://github.com/MSMazaya/rtems-docs/tree/renode), you can see the changes [here](https://github.com/RTEMS/rtems-docs/compare/master...MSMazaya:rtems-docs:renode)

## 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](https://lists.rtems.org/pipermail/devel/2023-August/076129.html). Full story on the attempts tried is listed [on the previous blog](https://mazaya.id/blogs/gsoc-midterm-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](https://renode.io/). 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](https://lists.rtems.org/pipermail/devel/2023-July/075868.html).

### 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](https://lists.rtems.org/pipermail/devel/2023-August/076225.html) 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](https://lists.rtems.org/pipermail/devel/2023-August/076225.html).

## 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:

- [Shlex argument parsing to match POSIX convention](https://lists.rtems.org/pipermail/devel/2023-May/075287.html): merged
- [Pipe command support for RTEMS tools parser](https://lists.rtems.org/pipermail/devel/2023-June/075543.html): merged
- [Renode implementation for the 2 BSP](https://lists.rtems.org/pipermail/devel/2023-August/076129.html): v4 review with licensing commented, not merged yet
- [RSB Recipe for Renode](https://lists.rtems.org/pipermail/devel/2023-July/075868.html): Chris said its OK to be pushed, but its not merged yet
- [Docs about Renode](https://lists.rtems.org/pipermail/devel/2023-August/076225.html): No review yet

## 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](https://discord.com/channels/820452222382112799/820452222848335924/1106250421179269210). 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](https://docs.rtems.org/branches/master/user/testing/simulation.html) 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](https://mazaya.id/blogs/gsoc-midterm-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.


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


Hi again!

This blog is made to document how to test Kendryte K210 using `rtems-test`. As a prerequisite, you need to have:

- The `rtems` repository cloned
- The `rtems-tools` repository cloned and applied with [the necessary patch](https://lists.rtems.org/pipermail/devel/2023-August/076256.html)
- The `rtems-source-builder` repository cloned and applied with [the necessary patch](https://lists.rtems.org/pipermail/devel/2023-July/075868.html)

## Required Dependency for Renode

Renode requires Mono >= 5.20 (Linux, macOS) or .NET >= 4.7 (Windows).

### Linux
Install the `mono-complete` package as per the installation instructions for various Linux distributions, which can be found on [the Mono project website](https://www.mono-project.com/download/stable/#download-lin).

### macOS
On macOS, the Mono package can be downloaded directly from [the Mono project website](https://download.mono-project.com/archive/mdk-latest-stable.pkg).

### Windows
On Windows 7, download and install [.NET Framework 4.7](https://www.microsoft.com/net/download/dotnet-framework-runtime). Windows 10 ships with .NET by default, so no action is required.

### Other Dependencies (Linux only)

```bash
sudo apt-get install policykit-1 libgtk2.0-0 screen uml-utilities gtk-sharp2 libc6-dev gcc python3 python3-pip
```

## Installing Renode

To install renode, you can download the official package for debian, fedora, arch, macOS, and windows [here](https://renode.io/#downloads).  Alternatively, you can access [Renode's GitHub releases](https://github.com/renode/renode/releases/tag/v1.13.3) or you can also [build it from source](https://renode.readthedocs.io/en/latest/advanced/building_from_sources.html#building-from-source).

For RTEMS usage, it is recommended to install it via the RTEMS Source Builder (RSB) because its using a version which has been proven to work with the RTEMS ecosystem. To do so, we can go to the RSB directory and use the following command.

```bash
$ cd rtems
$ ../source-builder/sb-set-builder --prefix=$YOUR_PREFIX --trace --bset-tar-file devel/renode
```

`$YOUR_PREFIX` is where your build artefact be built. After executing the command, you should be able to run Renode via `$YOUR_PREFIX/bin/renode`. Also, make sure that you have included the bin path of the prefix to your `PATH` environment variable. Otherwise, the test will fail later on.

## Building Kendryte K210 BSP

To build RTEMS Kendryte K210 BSP, Go to the RTEMS repository directory and create a `config.ini` file with content as follows.

```bash
[riscv/kendrytek210]
RTEMS_SMP        = True
```

Then, execute the following command to build the BSP.

```bash
$ ./waf configure --prefix=$YOUR_PREFIX
$ ./waf build install
```

That should build all the necessary things to use the BSP.

## Testing the BSP

To test the BSP, go to your `rtems-tools` repository directory and build the repository to the `prefix` of your choice the same way as we built the BSP.

```bash
$ ./waf configure --prefix=$YOUR_PREFIX
$ ./waf build install
```

Next, we can use `rtems-test` to test the BSP. The command to test the BSP is as follows.

```bash
$ rtems-test --rtems-bsp=kendrytek210-renode  ~/quick-start/src/rtems/build/riscv/kendrytek210/testsuites/
```

If it is successful, you probably see an output that looks something like this:

```bash
RTEMS Testing - Tester, 6.0.not_released
 Command Line: /home/mazaya/quick-start/rtems/6/bin/rtems-test --rtems-bsp=kendrytek210-renode /home/mazaya/quick-start/src/rtems/build/ri
scv/kendrytek210/testsuites/
 Host: Linux mazaya-HP-Spectre-x360-2-in-1-Laptop-14-ef0xxx 5.19.0-46-generic #47~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Wed Jun 21 15:35:31 U
TC 2 x86_64
 Python: 3.10.6 (main, May 29 2023, 11:10:38) [GCC 11.3.0]
Host: Linux-5.19.0-46-generic-x86_64-with-glibc2.35 (Linux mazaya-HP-Spectre-x360-2-in-1-Laptop-14-ef0xxx 5.19.0-46-generic #47~22.04.1-Ub
untu SMP PREEMPT_DYNAMIC Wed Jun 21 15:35:31 UTC 2 x86_64 x86_64)
[ 3/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  L:0  i:0  W:0  | riscv/kendrytek210-renode: cdtest.exe
[ 2/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  L:0  i:0  W:0  | riscv/kendrytek210-renode: capture.exe
[ 6/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  L:0  i:0  W:0  | riscv/kendrytek210-renode: iostream.exe
[ 1/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  L:0  i:0  W:0  | riscv/kendrytek210-renode: base_sp.exe
[ 4/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  L:0  i:0  W:0  | riscv/kendrytek210-renode: fileio.exe
[11/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  L:0  i:0  W:0  | riscv/kendrytek210-renode: unlimited.exe
[ 5/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  L:0  i:0  W:0  | riscv/kendrytek210-renode: hello.exe
[ 7/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  L:0  i:0  W:0  | riscv/kendrytek210-renode: minimum.exe
[ 8/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  L:0  i:0  W:0  | riscv/kendrytek210-renode: nsecs.exe
[10/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  L:0  i:0  W:0  | riscv/kendrytek210-renode: ticker.exe
[ 9/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  L:0  i:0  W:0  | riscv/kendrytek210-renode: paranoia.exe
[ 1/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  L:0  i:0  W:0  | riscv/kendrytek210-renode: base_sp.exe
[ 2/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  L:0  i:0  W:0  | riscv/kendrytek210-renode: capture.exe
[ 3/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  L:0  i:0  W:0  | riscv/kendrytek210-renode: cdtest.exe
[ 4/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  L:0  i:0  W:0  | riscv/kendrytek210-renode: fileio.exe
[ 5/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  L:0  i:0  W:0  | riscv/kendrytek210-renode: hello.exe
[ 6/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  L:0  i:0  W:0  | riscv/kendrytek210-renode: iostream.exe
[ 7/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  L:0  i:0  W:0  | riscv/kendrytek210-renode: minimum.exe
[ 8/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  L:0  i:0  W:0  | riscv/kendrytek210-renode: nsecs.exe
[ 9/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  L:0  i:0  W:0  | riscv/kendrytek210-renode: paranoia.exe
[10/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  L:0  i:0  W:0  | riscv/kendrytek210-renode: ticker.exe
[11/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  L:0  i:0  W:0  | riscv/kendrytek210-renode: unlimited.exe

Passed:         6
Failed:         3
User Input:     2
Expected Fail:  0
Indeterminate:  0
Benchmark:      0
Timeout:        0
Test too long:  0
Invalid:        0
Wrong Version:  0
Wrong Build:    0
Wrong Tools:    0
Wrong Header:   0
-----------------
Total:         11
Failures:
 minimum.exe
 nsecs.exe
 paranoia.exe
User Input:
 capture.exe
 fileio.exe
Average test time: 0:00:01.184675
Testing time     : 0:00:13.031424
```

And that's it! you have tested the Kendryte K210 BSP using `rtems-test` :)


How to test RTEMS Kendryte K210 BSP using rtems-test


Hi! it's the end of the first phase of GSoC and It's Midterm evaluation time :D. It has been a great time, with a good amount of frustrating one, and a great learning journey so far. The community have been very friendly and helpful to me. I wan't to thank my mentors and the RTEMS contributors: Gedare Bloom, Alan Cudmore, Hesham Almatary, Chris John, Joel Sherrill, and all others.

In this blog, I will be summarizing of things that I have been learning and the patches that I have submitted in the last few weeks during the coding period.

## Renode implementation to test Kendryte K210 in rtems-test

This is the main patch that I have been working on in this first period of GSoC. The idea was to be able to test a BSP with rtems-test that is using renode in the background. So, the expectation is that we can run something like this:

```bash
$ rtems-test --rtems-bsp=bsp-name-renode ~/build-dir
```

Alan, one of my mentors, said that I can take a look at the new BSP that he has ported into RTEMS. It's the Kendryte K210, and he has a very good [example repository](https://github.com/alanc98/k210-rtems-test) of using renode-test framework for testing the Kendryte K210 RTEMS BSP implementation. Therefore, in my first implementation I chose to work in making Kendryte K210 being able to be tested using `rtems-test` framework.

The first piece of puzzle to understand is: how does `rtems-test` actually work? It's a challenging part because new implementation of testing framework -- I believe -- is not something that the RTEMS community would expect to happen often. So there is no complete walkthrough about it, it's different from something like adding a new rtems-source-builder config which has [a very good documentation](https://docs.rtems.org/branches/master/user/rsb/configuration.html#new-configurations) on how to do that. But, there is a good picture on the documentation that sort of show how does it work under the hood.

![RTEMS test simulation](https://res.cloudinary.com/dw4bwn79m/image/upload/v1689215522/test-simulation_ojr1sc.png)

It uses the stdout of the simulator, and capture the output to see if it matches with the certain testing logic that is implemented in the test suites. Since I have been tinkering with renode for quite some time in the community bonding period, I know that Renode does not produce it's executable output from the stdout. It has its own window where the output is shown namely the staticAnalyzer. My next question is: how do I get the output of the executables then?

After reading the Renode's documentation, I found a section named ["UART integration"](https://renode.readthedocs.io/en/latest/host-integration/uart.html) that tells us different ways of getting the UART output -- that should be on the staticAnalyzer -- for our personal usage. It says that there are 2 ways of doing so: using [UART pty terminal](https://renode.readthedocs.io/en/latest/host-integration/uart.html#uart-pty-terminal) or using the [socket terminal](https://renode.readthedocs.io/en/latest/host-integration/uart.html#socket-terminal). The UART pty approach seems quite concerning because it states that:

```bash
This feature is available on Linux/macOS only.
```

Because RTEMS target Windows, macOS, and several Linux distribution to be supported, I decided that it's probably best to use the socket terminal. After discussing it with my mentors via email and discord, I decided to use it for the first attempt of the Renode implementation for `rtems-test`.

To be able to do so, I must know how the internals of `rtems-test` works. Spesifically, how does it get the stdout output from the simulator. This is where the python debugger comes in handy. There is a requirement before writing GSoC proposal that potential students should be able to compile and run the rtems executables. Because of that, I have the SPARC tool suite installed and I can use the rtems-test to test it.

```bash
$ rtems-test --rtems-bsp=erc32-sis build/sparc/erc32
```

Using that command, I started my python DAP (debugging analyzer protocol) session and just step in to the function and taking some notes of where potentially the simulator process is started. I found that in [the exact line](https://github.com/MSMazaya/rtems-tools/blob/add-renode-implementation/tester/rt/config.py#L247) that does that, I also figured out one of the feature that `rtems-tools` has which is the console.

```py
def _dir_execute(self, data, total, index, rexe, bsp_arch, bsp):
    self.process = tester.rt.exe.exe(bsp_arch, bsp, trace = self.exe_trace('exe'))
    if not self.in_error:
        if self.console:
            self.console.open()
        if not self.opts.dry_run():
            self.process.open(data,
                              ignore_exit_code = self.defined('exe_ignore_ret'),
                              output = self.capture,
                              console = self.capture_console,
                              timeout = (int(self.expand('%{timeout}')),
                                         int(self.expand('%{max_test_period}')),
                                         self._timeout,
                                         self._test_too_long))
        if self.console:
            self.console.close()
```

You can see that in the 4th and 15th line, there is an additional logic so that we can read the output of the simulator using a ["console"](https://docs.rtems.org/branches/master/user/testing/consoles.html). It is said in the docs that The RTEMS Tester directly supports the telnet protcol as a console and can interface to the `ser1net` server. So I thought to myself, maybe I can use this console to read the output of the Renode's socket terminal. After knowing about the console, I started to create the renode script to run the socket server and I have my first implementation of renode working for the `hello.exe` test.

![First success](https://res.cloudinary.com/dw4bwn79m/image/upload/v1689226154/unnamed_siuy9t.png)

The main problem is, this test is waiting the console timeout to stop the console from reading the output and move on. This is a problem because there is no way of telling renode to stop executing after the console done reading all the output. This caused the `rtems-test` to only be able to test a single test exe and then we have a renode process that is unkilled hanging around. What we can do instead, is to terminate the renode after the test is finished by using the [line hook integration](https://renode.readthedocs.io/en/latest/basic/using-python.html#uart-hooks) on Renode. But even after doing so, there is a new error that the console failed to connect to the Renode socket terminal because it dies earlier before the console process get the chance to be spinned.

Confused, I decided to research another viable approach that I can use for the project. This is where I figured out that I can access python's socket library on the UART line hook of renode. After that, I got the idea of sending each line of the renode's output using the socket library instead of using the socket terminal from renode. Huh, how is that a benefit from using the previous approach? Well, after diggin deeper into the `rtems-tools` source code, I found that we can implement our own [file handle](https://github.com/MSMazaya/rtems-tools/blob/add-renode-implementation/rtemstoolkit/execute.py#L180) for the `_readthread` of `rtems-test` (supplied by the argument). If I can implement a custom class that has a similar method as the file handle, I can implement my own custom logic so that it reads the socket message input from renode and kill the process after the test is completed. I know this is very hacky and arguable far from best practice, but Gedare (my mentor) said that its fine to have an initial implementation that is "ugly". As there might be suggestions from the community on how to do things better after submitting the patch.

Therefore, I spend my time to write [the implementation](https://github.com/MSMazaya/rtems-tools/commit/91664e5d15a48d8e4a627a38540ebd7851ca1238). After a while, I realized that there are too many edge cases I need to cover because of how bad the idea was. To mention a few: I need to also make sure I can know the simulator process is Renode, handle a panic so we don't have a socket server process just hanging like that, how to make Renode wait for the socket server to start before sending the message, etc. 

At this moment I decided to see if it is really not possible to output the renode's uart to stdout. Fortunately, after filing an issue to Renode's Github repository, turns out I can use a `logAnalyzer` to replace the `staticAnalyzer` so that it outputs the result on the stdout. The only problem was: there are some additional data from the logs I don't need but prepended by Renode. I tried to use `sed` to trim the command and it seems like `rtems-test` does not support piping operation. I give some time to help with that and sent my second patch on supporting pipe operation for `rtems-test`. After that, I also managed to have my working implementation of Renode for testing Kendryte K210 and send the patch to the community to be reviewed.

![Final success](https://res.cloudinary.com/dw4bwn79m/image/upload/v1689229498/image_1_ypmgmw.png)

## Building Renode via RSB

One of the feedback from the Renode's patch is that there should be a build config in the RTEMS Source Builder (RSB) to build Renode. And that is exactly what I tried to do after having the Renode's patch being reviewed. First I try to follow [the example of adding a new configuration](https://docs.rtems.org/branches/master/user/rsb/configuration.html#new-configurations) on the RTEMS user docs. The problem is, I can't get it built in the first place and there is no sign of error whatsoever. At this moment, Gedare told me to have a daily email of my progress update on this problem followed by the log file attached to the email.

After knowing [the problem](https://github.com/MSMazaya/rtems-source-builder/commit/9fe7135319447ea7f4e98e540b0810e0b90fca05) and fixing it, I get it to download the Renode release package. It still has some error, but its better than no error. Not longer after that, I managed to have it sorted out. I have sent the implementation to the community and it has gotten a feedback which I fixed in the v2 patch that I have just sent. It is tested in Ubuntu and I will try to test it in Windows and FreeBSD. I tried to setup Windows dev environment for RTEMS but can't seem to get it right. I will do this in paralel with other tasks I aim to do next.

## What's next?

Phew, that was quite a blog (longest I have written so far, what a shame). In the next half of GSoC period, I will be working in implementing Renode for testing 2 other BSP: leon3 and sihive hifive unleashed. In paralel, I will also setup other RTEMS supported host dev environment on my computer so I can test the previous RSB implementation just to make sure. Other than that, I will try to discuss it further with my mentors.

Thank you for reading! Cheers!


GSoC Midterm Blog!


## Introduction 

Hi everyone! My name is Muhammad Sulthan Mazaya, I'm currently studying at Bandung Institute of Technology in my 6th semester as an Engineering Physics student. I have a very big passion for software engineering in general, so much so I have interned 3 times as a software engineer, won various hackathons, and built software stuff for my student organizations just so I can learn to code even more! I have worked in various projects including: web development, mobile development, microcontrollers, etc. I aspire to be an IoT engineer, I always love and am curious to learn more about low-level systems, especially embedded systems. 

That is why, I decided to choose RTEMS Project for my GSoC organization. Other than that, I have always wanting to contribute to an open source. Given the opportunity to do so while learning things that I like is something I am very grateful and thankful for 😊

## Community Bonding Period

During this period, I will spend my time to align communication channels, deliverables, and expectations throughout this summer with my mentors. While doing that, I will also try to familiarize myself with the community and hopefully start contributing to bug fixes or feature implementation that the users/developers of RTEMS need. Related to my project, I will also spend my time to do the following:

- Familiarize myself with the RTEMS codebase (especially `rsb` and `rtems-tools`)

    If I can wrap my head around it quickly enough, I will also start working on writing the build recipe of renode in the `rsb` codebase.

- Start figuring out how to use Renode features (gdb debugging and network testing)

    I have been able to run `sparc/leon3` and `riscv/kendrytek210` on Renode thanks to Alan :) Soon, I will try to use the gdb and network testing tools that it provide (I will try to document this in the RTEMS docs as one of my GSoC deliverables).

## That's it!

Well I guess that's my first GSoC blog, hopefully the project will goes successfully implemented into RTEMS :)


Google Summer of Code - RTEMS


What's up! 

Hi everyone, thank you for paying a visit into my very first blog post!

Here (in the blogs section), you can expect to find a variety of content related to embedded systems, software engineering, and lots of other stuff that I found might be interesting to share (my academic journey, etc). Whether you're a tech enthusiast or simply someone who loves to explore the world, I hope you'll find something here that sparks your interest.

So grab a cup of coffee (or tea!) and join me on this journey. Cheers!


My Gallery

Mazaya's Blog

Where words meet code and dreams are pixelated