Improving data sources and tests in the Renode Zephyr Dashboard and Renodepedia


Topics: Open source tools, Open simulation, Open software libraries

Since its launch in 2021, we’ve been developing the Renode Zephyr Dashboard, a CI system combining structured data obtained from the Zephyr RTOS with our own Renode simulation framework, running a range of samples on over 470 simulated boards with RISC-V, ARM and other embedded SoCs.

Last year we launched the Renode U-Boot Dashboard, which allows testing the U-Boot bootloader in Renode on different platforms in a unified manner.

A representation of the updates to the Zephyr and U-Boot Dashboards

In this blog note, we will describe the latest expansion of the Zephyr and U-Boot Dashboards, with improvements extending the coverage of the dashboards ever further beyond what we described previously. The U-Boot Dashboard now also provides an additional source of technical data for Renodepedia which uses Renode and structured hardware description data to automatically generate a database of contemporary hardware. The improvements have also been helped by the introduction of the Hardware Model v2 (HWMv2) in Zephyr, which is described later.

Recent updates to the Renode Zephyr Dashboard

To increase the coverage of Zephyr Dashboard we are constantly improving underlying tools, most importantly the dts2repl generator and Renode itself.

Recently, we updated dts2repl to support new extended RISC-V instructions, as well as the new Gaisler GPTimer model along with providing an update to the NVIC model to support multiple CPUs, amongst other improvements.

We also made significant improvements to the Renode library of peripheral models, which is enriched with new peripheral device models alongside enhancements to platform descriptions. Through the combination of dts2repl and improved peripheral models, we made a substantial leap in the amount of passing targets from 300 at the time of the last blog note update to around 470 today.

Our improvements to the Zephyr Dashboard have not only focused on increasing the amount passing targets. We also included a new zephyr-rust sample, which demonstrates Rust running on Zephyr, using Zephyr APIs to provide the Rust standard library’s threading, synchronization and time functions.

We also added a Kenning Zephyr Runtime demo application to the dashboard, showing how a given model is executed on each platform by various inference libraries. The Kenning framework provides tools for compiling and benchmarking AI models on various hardware platforms - including various CPU architectures, GPUs, TPU and more. Some time ago, we developed a bare metal implementation of the Kenning API, which was used to evaluate and deploy models in the Kelvin RISC-V accelerator (formerly Springbok) with V Extensions. Recently, we also brought the Kenning API to the Zephyr RTOS, both for AI evaluation purposes, as well as deployment using a simple unified API regardless of the underlying runtime implementation.

To illustrate this integration, we now have three samples available for running inference of the model with the Kenning Zephyr Runtime using TFLite Micro, microTVM and IREE, which highlights the flexibility of the runtime in AI testing and demonstrates the machine learning possibilities of Zephyr with finite resources. Below, you can view the TFLite Micro sample, running on the 96Boards Argonkey platform.

Development of the dashboard is also sped up through our creation of zephyr-samples-builder, a GitHub Action workflow for building Zephyr RTOS samples for multiple platforms. This allows for numerous new samples to be added to the Zephyr Dashboard, extending its reach further and increasing its usefulness.

Further improvements to Renodepedia

The Zephyr Project recently introduced Hardware Model v2, allowing us to introduce even more data into Renodepedia, with better SoC to vendor mapping and improved SoC hierarchies. HMWv2 also introduced standardized terminology relating to supported boards, meaning that it also benefits the development of Renodepedia by providing relevant hardware data in a more structured and accessible format.
Renodepedia benefits from further ancillary improvements, including availability of verified System RDL files created on the basis of static code analysis of peripheral models, with the files generated by Renode models analyzer. In addition, we now integrate U-Boot sample simulation and new device tree data, helping to build a larger picture of the hardware landscape for users.

Historical build and simulation data in the Renode Zephyr Dashboard

In order to provide more useful data for users, we have adopted a new approach which allows us to aggregate more historical build and simulation data, which can then be easily compared. The restrictions imposed by projects with a long term perspective, such as in the automotive and space industries, sometimes require using older hardware with older/verified software versions, which is why the Renode Zephyr Dashboard has been designed to provide not only the latest information, but also historical data.

We have utilized this capability in the Zephyr Dashboard, allowing users to switch between two views, representing either the most recent Zephyr build or the most recent simulated one to provide more insight into the gathered data.

Collaborative software and hardware development with Antmicro

These dashboards, in parallel with Renode and Renodepedia, as well as our other projects such as the Visual System Designer, the Hardware Component Database and the Open Hardware Portal aim to provide a method for developers and business decision makers to quickly evaluate the opportunities available in both hardware and software, helping them choose the right system for their needs.

As part of our effort to enlarge our coverage of hardware, we are gathering and unifying information about the hardware landscape in our publicly available platforms. This process includes data obtained from a wide variety of sources, including but not limited to static data acquired from Zephyr/U-Boot source code (e.g., configuration, dependencies of components, etc.), as well as data from simulation of actually built and executed binaries.

We invite you to contact us at if you would like to discuss the possibilities enabled by software and hardware testing at scale in Renode, supported by the vast automated Renode ecosystem, illustrated by the implementation of the Renode Zephyr Dashboard, the U-Boot Dashboard and Renodepedia.

See Also: