#osporting

[siliconsignalsblog]

Accelerating Your Development: Silicon Signals Ports Android 14 on the Verdin iMX8M Plus

We are glad to report that Silicon Signals has used the Verdin Development Board to successfully port Android 14 to the Verdin iMX8M Plus. This noteworthy accomplishment not only demonstrates our dedication to offering state-of-the-art solutions, but also our proficiency in embedded systems development.

Key Features of Our Porting Solution

OS: Android 14

Carrier Board: Verdin Development Board

Toradex Easy Installer Supported: Our binary images are designed for seamless integration with the Toradex Easy Installer, ensuring hassle-free deployment.

HDMI Display and Touch Support: Experience full functionality with HDMI display support and responsive touch capabilities.

Download the Android Image

The Verdin iMX8M Plus's Android 14 image is readily available for download on our website. This gives you all the tools you need to get going right away. View Our Video Demo Watch our video demonstration of Android 14 running on the Toradex-NXP-i.MX8MP Verdin System on Module (SoM) in conjunction with the Verdin Carrier Board to see our porting solution in action. Watch as we walk through the HDMI display capabilities and booting procedure.

Watch the Demo Here!

Why Choose Silicon Signals?

You can save money and time by working with Silicon Signals on your Android porting project. Our skilled team's extensive knowledge of embedded system design lets you concentrate on what really matters: your ideas and product.

By leveraging our expertise, you can expect:

Faster Time to Market: Our streamlined process ensures you can bring your product to market quickly, allowing you to stay ahead of the competition.

Cost Efficiency: Our comprehensive solutions reduce the need for additional resources and minimize the risk of costly setbacks, providing you with a more efficient development process.

Tailored Support: We work closely with you to understand your specific project needs, providing the necessary technical support to ensure a successful outcome.

Conclusion

Silicon Signals is committed to providing you with the smoothest possible development experience. We are prepared to assist you in accelerating your project from conception to adoption, having successfully ported Android 14 on the Verdin iMX8M Plus. Are you prepared to move forward? To find out how we can contribute our experience to your project and assist you in reaching your development objectives, get in touch with us right now! For more information about our services, visit Silicon Signals.

[siliconsignalsblog]

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!