Renode is an open source software development framework which allows its users to run a multitude of operating systems and software on a range of embedded platforms, from ARM, LEON, POWER to RISC‑V. At Antmicro, we work with most popular open source RTOSs and frameworks, but as a Platinum Member of the Zephyr Project, we are especially happy to enable a wider and easier adoption of this vendor neutral RTOS, as well as improving its testing and CI capabilities, with Renode.

Our recent work has resulted in what we call the Renode Zephyr dashboard, which is a CI system incorporating the advantages of the easy to use, structured Zephyr data and Renode’s flexibility and configurability to produce a concise dashboard, displaying which Zephyr-compatible boards are currently supported in our simulation framework.

This project utilizes the systemized information from Zephyr - which uses device trees to describe the platform information needed to pick and configure specific drivers and subsystems, which can be then mapped onto the plug and play, building-blocks oriented nature of Renode. As a member of the Zephyr’s Technical Steering Committee, Antmicro collaborates with other Zephyr members (which include many of our customers such as Google, Intel or NXP) to ensure the use of a standardized and unified approach to implementing new ports. This concept of defining commonalities in platforms is an important step on the way to improving and generalizing support for silicon in embedded systems.

We work with a variety of architectures and platforms, including ARM, RISC‑V, POWER and Tensilica (support for which is under development), and support our customers with commercial engineering services to implement Zephyr ports and drivers, Renode models as well as complete products based on Zephyr. Therefore, especially in the context of lifecycle management, continuous integration and automation that we are heavily involved with on behalf of our customers, structured data is very important to us.

Dashboard features

The dashboard provides a good overview of the "lay of the land" of basic Zephyr platform support in Renode in a user-friendly and clear way. Boards are grouped together by their architectures and displayed in collapsible categories for easier browsing. The sidebar provides extra help in navigating the dashboard by allowing jumping between categories. Additionally, the information about which version of Renode and Zephyr is used is displayed on the sidebar.

Each board is displayed with a color-coded badge indicating its status. Statuses range from NOT BUILT for boards which couldn’t be built (mostly fixable with installing additional toolchains, which is work in progress), to PASSED for boards which were successfully built, run in a simulation environment and passed our tests. If the architecture category is collapsed, an aggregate status is displayed. Categories which have more than one board in it and where all boards have the same status are collapsed by default.

For testing purposes, the shell_module sample from Zephyr is used. It provides a CLI with a number of commands, including demo board (which we added to Zephyr especially for such use cases!), which prints out the board’s name. We use that information during the testing phase to check it against the expected value that is extracted directly from the board’s configuration file.

Next to the status badge you can find a column with several icons, which point to various files, including:

• ELF file (Zephyr with a statically linked application)
• Flattened device tree
• Renode script
• Renode interactive run logs

These files are useful in learning how Renode matches onto the Zephyr device descriptions and - for the boards that we cannot yet run - where the problem lies.

Additionally, for each successfully passing platform, a play button is provided as the last icon which opens the asciinema player which shows a playback of a recorded UART session. This is a nice showcase of how Renode can be used to provide very visual and concrete output of real executions of your software.

The second-to-last column shows which Renode platform file was used to model the board. They can be grouped into three categories:

• Defined
• Matched
• Automatically generated

A few boards have their Renode platform file defined manually (these ship with your Renode mainline installation, among many other non-Zephyr demos). For most of the boards, however, the dashboard either identifies which Renode platform file to use by traversing the dts files, or automatically generates them. The CI matches which Renode block is required by using the bindings provided by Zephyr, and generates the virtual model description accordingly. This is the same mechanism used by Zephyr internally to identify which driver to use.

Renode for easy CI of complex systems

The Renode framework is being used by ourselves and our customers to generate interactive dashboards, such as the one described in this note, which provide a quick visual summary of the status of your software. This can be especially useful for developing product families with many related devices which can span multiple vendors, MCU variants, configurations and product generations.

The dashboard shows the breadth and flexibility of Renode, which is especially useful in testing complex systems without having to run extensive board farms, with the capability to share results between teams easily and trace problems across your hardware and software stack.

We have been helping our clients build internal and publicly facing CIs that run their software in Renode and extract useful information, e.g. execution metrics such as instruction count and memory usage, testing coverage and status, processes/function traces and more to assist with their daily work, both in pre- and post-silicon use cases.

Status and future plans

So far, almost 100 boards have been successfully tested in Renode, as indicated by the PASSED status. This constitutes almost ¼ of all platforms supported by Zephyr v2.7.0. We are currently working on adding the Xtensa architecture support in Renode which, in time, will enable further platforms to pass. In the future we want to run other Zephyr samples as our dashboard payloads, as well as external projects such as TF Lite Micro, Micro-ROS and MicroPython.

We are also planning to take advantage of the Robot Framework Engine that is implemented in Renode to utilize the Robot Framework test automation features and its more structured output to further help us increase our share of supported Zephyr platforms in Renode.

If you would like to see your platform supported in Renode, or you would want to see your platform added to Zephyr, reach out to us at contact@antmicro.com. Also, if you are already building an IoT product and you are not sure which platform or RTOS to choose and how to construct your testing strategy, we will be happy to help.