Porting software to new hardware is one of Antmicro’s staple services which we often perform as part of larger customer and R&D projects. As a Platinum member of the Zephyr Project, we actively participate in developing this open source, compact RTOS intended for resource-constrained, connected devices. In this area, we often work for and with silicon vendors, product makers, and hyperscalers, advocating for the use of the open source RTOS and helping in the implementation process itself.
In this note we will describe our recent work on adding Zephyr support for the Silicon Labs EFR32BG22 and EFR32MG24 ARM® Cortex®-M33 System on Chips designed for enabling, respectively, Bluetooth connectivity and mesh IoT wireless connectivity using Matter, OpenThread and Zigbee to battery-powered IoT products. We will take the opportunity to shed some light on the porting process itself, the practicalities of working with an open source ecosystem and challenges that needed to be addressed. Finally we will show how to run a simple Zephyr demo on the BG22 SoC in Renode, Antmicro’s open source simulation framework.
You can also read about Silicon Labs’ perspective on the collaboration on their Technical Blog.
Porting process
As is common with open source, it is rarely the case that we are starting a Zephyr RTOS porting process completely from scratch: usually, there is some pre-existing code base we first need to take over, scrutinize and update according to a project’s needs. The BG22 port was no exception, as there was prior Silicon Labs work to base on. Since every PR for the Zephyr project undergoes a review process, it is most efficient to work in small increments and send in small PRs for review. Submitting a piece of code triggers a review from the respective maintainers for a specific subsystem or platform as defined in the project’s maintainers.yml file. It is an iterative process, where potential additions undergo a series of reviews and changes, often multiple times, before being accepted and merged. Any code submitted to Zephyr also needs to abide by the project’s guidelines.
To begin with, in order to prepare the baseline for further work, Antmicro submitted an initial PR a minimal version of the Silicon Labs BG22 PR mentioned above, which it superseded, adding:
- the Pinctrl driver
- UART driver modifications
- EFR32BG22 SoC support
- EFR32BG22-SLTB010A board support.
This PR also resulted in some additions to the Thunderboard entry in the Zephyr project documentation.
On top of this, in a series of PRs, we have added the following features which are already part of mainline Zephyr:
- Adding support for the Gecko SPI and an SPI transaction sample
- Enabling the Gecko Watchdog Timer driver
- Enabling the Gecko i2c driver
- Enabling the entropy driver
- Enabling Bluetooth Low Energy.
A feature that still remains to be added is introducing initial support for the BRD2601B (Mighty Gecko Radio Board) board based on the MG24 SoC.
Zephyr release schedule and HAL
The Zephyr RTOS has a strict release cycle, where no new features and ports are accepted with a new release approaching. During this time, known as the "feature freeze" period, only bug fixes and documentation updates are accepted, which needs to be taken into consideration when planning a project like this.
Another challenge that we needed to address were Hardware Abstraction Layer (HAL) co-dependencies used by Silicon Labs. As open source proponents, Antmicro tends to refrain from using HALs, but since this approach is widely used across the Zephyr ecosystem, we temporarily took over maintainership of the HAL and released the parts that do not fall under a proprietary license. As a general rule, Antmicro shares everything that is developed with the customer and onboards them to the project. In this case, we took over the maintainership of the HAL for the purposes of the porting process before handing it back to the customer.
Running Zephyr demos in Renode
In the porting process, we have used simulation in Renode alongside working on actual hardware. This enabled us to automatically test new implementations in CI and parallelize the testing without a need for physically connecting multiple boards.
Provided that you have python3 and pip installed on your machine, you can run several demos available for this board, e.g. running the Zephyr shell submodule, allowing you to use the OS’s console.
In order to run this demo for a BG22 board, you first need to download and install Renode and pre-built binaries for the demo by running:
pip3 install --user --upgrade git+https://github.com/antmicro/renode-run.gitThen you can run the simulation in Renode:
renode-run demo -b efm32hg_slstk3400a shell_moduleYou can visit Renodepedia to find more Zephyr demos for the SoCs, that you can run locally in Renode or on a cloud server with Google Colab, e.g. performing arithmetic operations using the MicroPython Zephyr port or running a sample TensorFlow application.
To browse the landscape of boards supported in Zephyr RTOS and see them running in Renode, take a look at Antmicro’s Renode Zephyr Dashboard.
Bring Zephyr to your hardware with Antmicro
Combining Antmicro’s hardware and software knowledge with the capabilities offered by the deterministic simulation environment in Renode enables us to efficiently port open source software to existing silicon, and develop HW and SW in parallel.
If you are interested in porting Zephyr to your silicon and maintainable, test-driven development of Zephyr RTOS code for real-world products, reach out to us at contact@antmicro.com. If you prefer to find out more about porting Zephyr in person, find us at the Zephyr Project Developer Summit in Prague, Czechia on 27-30 June 2023 and attend the joint talk by Silicon Labs and Antmicro titled "Enabling the Silicon Labs EFR Family in Zephyr – a Case Study from a Port’s Lifecycle".