Tailoring Zephyr to Your Hardware: West Manifest Customization

 

Introduction

The Zephyr Project RTOS (https://zephyrproject.org/), or simply “Zephyr” as it is known colloquially, is an increasingly popular real-time operating system due to its native support for over 450 boards and countless peripherals. Starting from a known baseline is the first step in any embedded software project. This can involve downloading a zip file that represents a particular source code version, as is typically the case with other RTOSes, or cloning a repository from source control, as may be the case with embedded Linux. In order to guarantee that Zephyr development starts from a known baseline, this blog post will outline a personal best practice. As a result, when a client or colleague takes over development of a Zephyr-based project, there are no surprises.



Zephyr is special because it retrieves all of the Zephyr components from various locations, possibly using different mechanisms, using a "meta-tool" called West. Contrast that with a standard software development process, which retrieves the source code from a single repository. A "manifest" file contains instructions for West on how to obtain the various components. A snapshot of the complete Zephyr codebase is provided by the manifest file, which is typically checked into source control.


Strategy

There are two parts to the strategy. We can start by making forks of the repositories where we plan to make changes. Having a dependable location that acts as a sandbox is still crucial, even though the objective is to generate pull requests for pertinent customizations. For instance, a previous blog post (https://zephyrproject.org/supporting-firmware-updates-with-zephyr-nrf/) showed how to add buttonless DFU to MCUBoot, which necessitated making a fork of MCUBoot. A bug we've found or a feature we want to add may also require us to change one of the Zephyr subsystems. We can make a fork of the Zephyr repository in the interim, but it would be best to submit a pull request (PR) following their guidelines (https://docs.zephyrproject.org/latest/contribute/guidelines.html).

We can describe our entire codebase in a custom West manifest file after the forks have been created. Nordic Semiconductor has done a lot of work to develop a complete, stable baseline firmware using Zephyr, and we can start by using their West manifest file (https://github.com/nrfconnect/sdk-nrf/blob/main/west.yml) to assist their customers in getting started. Nordic's manifest file can be modified as needed and used as our own. First, we can include a "remote" with the repository's base URL and a descriptive name:

remotes:

.

.

.

        - name: <a descriptive name>

          url-base: <base repository URL>

Second, we must tell West to use MCUBoot and our fork of Zephyr. When no remote is specified for a specific codebase, Nordic Semiconductor's repository is used as the "default" in their manifest file:
In order to prevent West from using Nordic's repositories, we must include our remote in the Zephyr and MCUBoot entries:

.
.
.    
        - name: <zephyr repository name>      
          path: zephyr
          revision: <git commit/branch>
          remote: <a descriptive name>
.
.
.
        - name: <mcuboot repository name>
          path: bootloader/mcuboot
          revision: <git commit/branch>
          remote: <a descriptive name>



Putting It All Together

Following the aforementioned modifications and uploading the updated West manifest file, we can use the modified West manifest file by running the following command, which will import our MCUBoot and Zephyr forks:

$> west init -m <West manifest repo> --mr <commit/branch>

The “--mr” option can be used to specify a particular commit or branch; this may be useful if the default branch is not master (as in the case of Github, which uses “main” as the default branch).

To sum up, this blog post explained how to create a custom West manifest file, which is a good place to start when developing Zephyr firmware. Because a third-party repository might have changed, a custom West manifest file guarantees that there are no surprises during development. A deliberate choice to upgrade to a newer Zephyr version can be made once the firmware is stable and feature-complete.

 

Ready to optimize your hardware with customized Zephyr RTOS solutions? At Silicon Signals, we specialize in embedded hardware design, software development, and tailored solutions that align with your project requirements.

🚀 Contact us today to discuss how we can accelerate your development with Zephyr and create a robust foundation for your embedded applications!

Comments

Post a Comment

Popular posts from this blog

How Android System Services Connect Apps and HAL: A Deep Dive

Image
Android is more than just a mobile operating system— it's a powerful middleware that seamlessly connects apps to the underlying hardware through a layered architecture of frameworks, services, and abstraction layers .  The Android System Services, which control essential features like window handling, power management, telephony, and more, are at the core of this framework. By serving as a bridge, these services guarantee seamless communication between the hardware abstraction layer (HAL), the framework, and user applications.     The internal operations of Android System Services are examined in this blog, along with how they interact with HAL and apps.   Understanding Android System Services   Essential parts of AOSP, Android System Services oversee fundamental features like power, connectivity, phone, and security. Through Binder IPC, these services enable smooth communication between applications, the framework, and hardware while operating inside SystemS...
Read more

AOSP Passthrough HAL: Architecture, Use Cases & Performance Guide

Image
  With over 3 billion Android devices in circulation and a growing need for optimized hardware-software integration, understanding the different types of Hardware Abstraction Layers (HALs) is crucial for modern developers. In our last blog, we explored the Binderized HAL —now the standard in most Android platforms due to its secure and modular design. But did you know that Passthrough HAL still plays a vital role in performance-critical applications and legacy hardware deployments ?   Despite its aging architecture, Passthrough HAL remains relevant in scenarios where low-latency hardware access and minimal overhead are priorities. In this blog, we’ll break down how Passthrough HAL works, when it makes sense to use it, and why understanding both HAL types is essential for building efficient, scalable, and backward-compatible Android systems .   Understanding Passthrough HAL   Without the need for an IPC mechanism, Android framework components can communic...
Read more

Getting Started with AOSP: Build Custom Android Solutions

Image
  Want to see what it takes to build your own Android-based system? Regardless of whether you want to use custom hardware or embedded software, AOSP delivers a complete and adaptable resource. We’ll go over AOSP, its benefits, drawbacks and why it is slowly being adopted by smartphones, IoT devices and automotive platforms.   AOSP Android BSP What is AOSP (Android Open Source Project)?   The Android Open Source Project is a repository of source code and documentation used to build the core Android operating system. It's open-source , meaning developers, OEMs, and businesses can freely access, modify , and build upon the platform to create custom Android distributions.   While AOSP contains the base OS, it does not include Google’s proprietary apps and services (like Gmail, Google Play, and Maps)—those are part of Google Mobile Services (GMS), which requires a license. AOSP represents the raw and adaptable side of Android, giving developers control over feat...
Read more