When developing embedded software for IoT devices, it is essential to achieve high-speed, stable wireless communication in a Linux environment. In particular, advanced use of Wi-Fi technology to support collaboration with a variety of IoT devices is an important theme in development sites.
There is a type of Wi-Fi module known as host-based. In host-based modules, the wireless communication software stack is implemented on an external processor (host CPU). This configuration reduces the processing load on the module, allowing for advanced control and customization on the host side. As a result, flexible function expansion and optimization according to application requirements is possible. Using host-based modules makes it easier to meet the diverse needs of IoT devices and industrial applications. However, unique know-how is required for building the development environment and build process.
This article uses the u-blox JODY-W3 series Wi-Fi module and NXP i.MX8 evaluation board as examples to provide a detailed explanation of how to build a Linux development environment using the Yocto Project. It also provides practical know-how that will be useful in the field, from integrating drivers and firmware, building, image writing, and boot debugging.
Reasons why the u-blox JODY-W3 series is chosen for ECU development and its main specifications
The difference between "host-based type" and "standalone type" wireless modules
u-blox is a Swiss company that provides high-precision wireless solutions for automobiles, focusing on GNSS positioning, Wi-Fi, and Bluetooth technologies. u-blox's wireless modules can be broadly divided into two types: "host-based type" and "standalone type." The standalone type is further divided into "u-connect type" and "open CPU type."
Host-based type
Features:
This method involves installing a wireless chipset inside the module, and implementing the wireless communication software stack on an external host CPU (e.g., i.MX).
merit:
- High-level control and customization possible on the host CPU side
- Easy to flexibly expand and optimize functionality according to application requirements
- Easy integration of multiple wireless standards and proprietary functions
Cons:
- Requires specialized know-how for building development environments and build processes
- Increased resource consumption on the host CPU side
Standalone: u-connect type (AT command based)
Features:
The wireless communication software stack is stored inside the module, and the host CPU is controlled using AT commands via UART or similar.
merit:
- The host CPU side can be controlled with a simple API, reducing development load
- Low resource consumption of the host CPU, making it easy to incorporate
- Evaluation and implementation can be done in a relatively short period of time
Cons:
- Customization and extensibility are more limited than host-based types
- May not be suitable for special requirements or advanced control
Standalone: Open CPU type (RTOS-based, such as Zephyr)
Features:
The module is equipped with a CPU and the wireless communication software stack runs on an RTOS (e.g., Zephyr). User applications and custom firmware can be implemented directly within the module, allowing it to operate independently without an external host CPU.
merit:
- The module operates independently, eliminating the need for an external host CPU
- Unique applications and advanced control LOGIC can be implemented
Cons:
- Knowledge of RTOS and firmware development required
- Module resource constraints
- The range of applications is limited compared to host-based types
For an overview of u-blox's wireless modules, please refer to the Short range radio product overview document below.
Introducing the u-blox JODY-W3 series of host-based wireless communication modules
In this article, we used the u-blox JODY-W3 series, a host-based type Wi-Fi module. The JODY-W3 series is a high-end wireless module equipped with the NXP 88Q9098 chipset, supporting Wi-Fi 6 (802.11ax) and Bluetooth 5.3, and is automotive-grade. The JODY-W3 series is a host-based type, and thanks to its flexible customizability and high performance, it is widely used in automotive and industrial applications.
*The JODY-W3 also has Bluetooth functionality, so technically it is a Wi-Fi/Bluetooth module, but since this article focuses on the Wi-Fi function, we will refer to it as the "Wi-Fi module."
u-blox M.2 type Wi-Fi module M2-JODY-377 specifications
| Item | Content |
|---|---|
| Model name | M2-JODY-W377 |
| Chipset | 88Q9098 (NXP) |
| Wi-Fi IEEE Standard | Wi-Fi 6 (802.11ac/ax) |
| Wi-Fi Radio Frequency | 2.4GHz / 5GHz |
| Bluetooth | Bluetooth BR/EDR, BLE |
| Bluetooth Qualification | v5.3 |
| Bluetooth profile | HCI |
| Interface | UART PCIe SDIO I2S(PCM) |
u-blox M.2 type Wi-Fi module M2-JODY-377 appearance and block diagram
*M.2 type is the name of an interface standard, a small form factor for expansion cards such as SSDs, Wi-Fi, and Bluetooth.
The appeal of the NXP i.MX8 evaluation board and the Yocto Project
Introducing the NXP i.MX8 evaluation board, ideal for host-based modules
NXP is a Dutch company that provides semiconductor solutions integrating Linux-compatible application processors (i.MX series) with wireless communication and security functions for the automotive, industrial, and IoT fields. NXP's i.MX evaluation board features a high-performance Arm-based processor and is characterized by flexible expandability with a wide range of interfaces, including PCIe, SDIO, and USB. The i.MX evaluation board can also be easily connected to host-based u-blox Wi-Fi modules, providing an ideal environment for IoT and embedded Linux development. Furthermore, a Yocto Project-compatible BSP (Board Support Package) is available on GitHub, providing a major advantage in that it enables efficient driver integration and custom image building.
The features of the i.MX8 series evaluation board used in this article are as follows:
NXP i.MX8 series evaluation board MCIM8QXP-CPU specifications
| Item | Content |
|---|---|
| Model name | MCIMX8QXP-CPU |
| CPU | i.MX 8QuadXPlus 4x Cortex-A35 @ up to 1.2 GHz |
| OS | Linux, Android, FreeRTOS |
| DDR memory | 3 GB LPDDR4 memory x 32 |
| Non-volatile memory | 32GB eMMC 5.0, 64MB Octal SPI Flash |
| Debugging Interface | Serial to USB connector, JTAG, |
| M.2 CONNECTORS | PCIe, USB, UART, I2C, I2S |
| OTHERS CONNECTORS | 10/100/1000 Ethernet port, USB3.0 TypeC, SD/MMC slot |
NXP i.MX8 series evaluation board MCIM8QXP-CPU external appearance
What is the Yocto Project in embedded development?
The Yocto Project is an open source project for building embedded Linux systems efficiently and flexibly.
By utilizing layer structures and recipe management with BitBake, highly reproducible builds and advanced customization are possible.
The main features are as follows:
- Build a highly customizable Linux distribution
- BSP provides an environment for specific hardware
- Building packages and images with Bitbake and recipes (.bb files)
- Meta-layer structure allows for flexible addition of functions and module integration
Particularly in the embedded field, flexible build environments like Yocto are widely used because it is necessary to support different hardware configurations for each product.
Please refer to the NEXTY Electronics technical column for detailed explanations of the steps to set up a Yocto build environment on i.MX and the performance requirements of the PC you will be using.
TIPS Pitfalls of Embedded Linux Build Environments: Relationship between Memory Capacity and Number of Threads
When creating an embedded Linux build environment with the Yocto Project, you need to be careful about the memory capacity of your PC. Yocto builds involve massive parallel processing, so insufficient memory can be fatal.
The PC used in this article initially had 8GB of memory, but build errors occurred frequently unless the number of threads was limited. After increasing the memory to 32GB, builds were able to be performed reliably without limiting the number of threads.
When building a development environment, we recommend that your PC have at least 16GB of memory, and 32GB or more if possible.
For reference, the PC specs used in this article are as follows:
Specifications of the PC used in this article (for reference):
- Model name: STYLE-S06M-124-UH3X (IIYAMA desktop PC)
- CPU: Intel® Core™ i5-12400 (6 cores/12 threads, up to 4.4GHz)
- Memory: 32GB (DDR upgrade from 8GB)
- Storage: 2.5TB (SSD added from 500GB)
- OS configuration: Windows 11 (200GB), Ubuntu 20.04.6 LTS (700GB)
Triple boot configuration of Ubuntu 22.04.5 LTS (300GB) - WLAN: USB WLAN adapter (WDC-150SU2MWH, IEEE802.11b/g/n compatible)
Host-based software architecture
Meanwhile, the module can focus on communication functions, enabling efficient real-time wireless processing.
*Details of the software architecture are explained in 3.4 Software architecture in the System integration manual for u-blox's JODY-W3 series.
The u-blox JODY-W3 series is a high-performance wireless module equipped with Wi-Fi and Bluetooth functionality, and employs a host-based architecture. In this configuration, wireless communication control and application execution are performed on the host system (e.g., NXP's i.MX series), and the JODY-W3 module is primarily responsible for processing the physical and MAC layers.
This chapter explains the components of the host-based architecture, dividing them into the host system side and the module side. It provides a detailed technical introduction to the protocol stack and device drivers that run on a Linux-based OS, the firmware management mechanism, and the wireless processing functions inside the JODY-W3 module.
Host-based type u-blox JODY-W3 series software architecture
Left: Host system, Right: Module (JODY-W3)
Host System Department
Application layer (User application)
User applications and services operate on this layer, enabling network communication using Wi-Fi and Bluetooth. Applications tailored to their intended use, such as IoT gateways and industrial equipment, are deployed here.
OS/Protocol stack (Host OS/XXX stack)
The Linux kernel's TCP/IP stack and cfg80211 subsystem support Wi-Fi communication, while the BlueZ stack is used for Bluetooth communication. These stacks work with applications through standardized APIs to provide stable communication.
Device driver layer (XXX driver)
For Wi-Fi, specific drivers for the NXP chipset (e.g. moal/MLAN kernel modules) are loaded, and for Bluetooth the hci_uart driver is used. These drivers provide the host side with a communication interface to the module and allow it to work with the firmware.
Firmware (XXX firmware)
In host-based wireless modules like the JODY-W3 series, the Wi-Fi and Bluetooth control firmware is downloaded from the host to the module. The firmware managed by the host is provided as "combo firmware" that integrates both Wi-Fi and Bluetooth functions. Combo firmware is a set of code that controls both Wi-Fi and Bluetooth wireless communication functions in an integrated manner, enabling simultaneous communication using different communication methods within the same module. This firmware is loaded via PCIe or UART when the module starts up. This allows the module to operate with the latest features and security patches.
JODY-W3 module
OTP Memory
It stores module-specific information such as calibration data and MAC addresses, ensuring communication stability and identification.
Firmware
The firmware downloaded from the host runs and controls wireless communication. Note that the user application runs on the host side; the JODY-W3 module does not run any application on its own.
[Practice] Yocto development environment construction procedure
When creating a build environment for the i.MX Series using the Yocto Project, you must first install the necessary development tools and utilities on Ubuntu. This will ensure that the build process, including cross-compilation, package management, and image generation, proceeds smoothly. While we won't go into details in this article, the general steps for installing development tools and utilities on Ubuntu, creating the build environment, and creating the build directory are as follows:
1. Install various basic application packages (first time only)
The first time you install Ubuntu, you will need to install the necessary development tools and utilities.
$ sudo apt-get install build-essential chrpath cpio debianutils diffstat file gawk gcc git iputils-ping libacl1 liblz4-tool locales python3 python3-git python3-jinja2 python3-pexpect python3-pip python3-subunit socat texinfo unzip wget xzutils
zstd efitoolsIf no error messages appear, the installation was successful.
2. Install the repo utility
Install the repo utility required for Yocto Project source control.
$ sudo apt update
$ sudo apt install curl
$ mkdir -p ~/bin
$ curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
$ chmod a+x ~/bin/repo
$ nano .bashrc
$ source ~/.bashrc
Use the nano command's editor function to add the following line to the last line of the .bashrc file (text).
export PATH=~/bin:$PATH
You can check the contents of the file with cat .bashrc.
If no error messages appear, the installation was successful.
3. Configure your local Git user information
Set the local Git username information for your PC to download the BSP.
Use the git config command to set your Git username and email address. To confirm that it was configured correctly, use the git config –list command to check the local Git username setting. The command is as follows:
*We will not go into details about registering a GitHub user account here.
$ git config --global user.name "Your Name"
$ git config --global user.email "Your Email"
$ git config –listAn example of execution is as follows.
$ git config --global user.name "Nexty"
$ git config --global user.email " nexty@nexty-ele.com "
$ git config --list
user.name=Nexty
user.email=nexty@nexty-ele.com
4. Get Yocto BSP
Use the repo utility to download the Yocto Project BSP for i.MX from GitHub.
The following is an example of specifying the BSP for kernel version 6.1.36-2.1.0 release name mickledore.
$ mkdir imx-yocto-bsp
$ cd imx-yocto-bsp
$ repo init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-mickledore -m imx-6.1.36-2.1.0.xml$ nano .bashrc
$ repo sync*If you change the Linux kernel version, you will need to configure the BSP again.
If the final repo sync returns a success log, the process is complete.
repo sync has finished successfully5. Create a build directory
Create a build directory with the distro command. If you are doing a clean build, create a new directory.
＄cd imx-yocto-bsp
＄DISTRO=fsl-imx-xwayland MACHINE=imx8qxpc0mek source imx-setup-release.sh -b bld-imx8qxpc0mek8The parameters in the create build directory command syntax are explained below:
$ DISTRO=<Name of the build environment to use> MACHINE=<Type of target board> source imx-setup-release.sh -b <Name of the build directory to generate (optional)>
As shown in the example below, if you move to the directory of the "Build directory name to generate (optional)" set with the DISTRO command without any error messages and return to $, the process is complete.
When the DISTRO command is executed in the directory "~/imx-yocto-bsp_6136210" and completed, it will return to the subordinate directory "~/imx-yocto-bsp_6136210/bld-imx8qxpc0mek_06".
~/imx-yocto-bsp_6136210$ DISTRO=fsl-imx-xwayland MACHINE=imx8qxpc0mek source imx-setup-release.sh -b bld-imx8qxpc0mek_06
Build directory is bld-imx8qxpc0mek_06
Some BSPs depend on libraries and packages which are covered by NXP's
End User License Agreement (EULA). To have the right to use these binaries in
your images, you need to read and accept the following...
中略
Your build environment has been configured with:
MACHINE=imx8qxpc0mek
SDKMACHINE=i686
DISTRO=fsl-imx-xwayland
EULA=
BSPDIR=
BUILD_DIR=.
meta-freescale directory found
~/imx-yocto-bsp_6136210/bld-imx8qxpc0mek_06$
These procedures are based on the official NXP user's guide, "i.MX Yocto Project User's Guide."
Additionally, detailed steps are explained in the Nexty Electronics technical column, so please refer to that.
TIPS: How to deal with repo sync fetch errors when downloading Yocto BSP and notes on EULA acceptance
When downloading a BSP for the i.MX platform in the Yocto Project, a fetch error may occur when executing the repo sync command. This is due to the load caused by parallel processing or network instability. Please try the following to resolve the issue.
Solution
Use repo sync -j1 --fail-fast option
By limiting parallel processing to one thread and immediately stopping it when an error occurs, synchronization can be ensured.
EULA acceptance notes
If you are asked to accept the EULA (End User License Agreement) after executing the Distro command, keep pressing the y key until the progress reaches 100%. The build will not start until acceptance is complete.
Creating a build environment to incorporate u-blox modules
To run the u-blox module on the i.MX8 evaluation board, you need to integrate the driver and firmware for the u-blox module into the Yocto project and build a Linux image. This chapter explains how to understand the BSP structure, edit the configuration file, and place the software resources of the u-blox module.
First, I have summarized the file names, function descriptions, and work details that were added and edited in the Yocto project to build the Linux image of the u-blox module.
File names and work required for building
| Item | File name | Function Description | Work content |
|---|---|---|---|
| Build Configuration File | bblayers.conf | BBlayers allows you to specify which meta-layers (a collection of recipes, settings, classes, patches, etc.) to build. | Specify the directory where u-blox's Yocto recipes are referenced |
| Build Configuration File | local.conf | Specify the build contents, such as which board to use (MACHINE) and what packages and applications to include (IMAGE_INSTALL). | u-blox package group and model specification Specifying installation of various applications |
| Driver and firmware for u-blox module JODY-W3 series | PCIE-WLAN-UART-BT-9098-U16-X86-17.68.1.p149.55-17.26.1.p149.55- MXM5X17405_P42_V0V1-MGPL.zip | JODY-W3 series driver and firmware package | Place it in the downloads directory in the BSP |
| RF test tool for u-blox JODY-W3 series | 9098_Bridge_and_Native_Labtool_MFG_FW_p230.zip | JODY-W3 series MFG package for RF testing RF test firmware, bridge application Includes mfgbridge, RF test application Labtool | Place it in the downloads directory in the BSP |
| Yocto recipe for u-blox module integration | meta-ublox-modulesー2025-05-05 | A set of .bb files that describe the build procedures for drivers and tools. | Place in the opt/Yocto/Archive directory |
The explanation in this chapter is as follows:
1. i.MX Yocto BSP Directory Structure
Details of the directories in the BSP downloaded by the repo utility
2. Software resource allocation for u-blox modules
The driver and firmware are placed in the downloads directory, and the Yocto recipes are placed in the opt/Yocto/Archive directory.
3. Important points for editing the configuration file
- local.conf: Specific methods for specifying the u-blox package group, model, and installation of various applications
- bblayers.conf: How to specify the directory that references u-blox's Yocto recipes
4. Recipe Editing
Explaining the structure and editing examples of u-blox's Yocto recipes
What is a Yocto recipe?
Yocto recipes are build definition files used by the Yocto Project in embedded Linux development, an open source project for building customizable Linux distributions, and recipes are its central building block.
A Yocto recipe is a file that describes the following:
- What source code to use (Git repository, tarball, etc.)
- How to build it (configure, make, etc.)
- How to install (where to place files, etc.)
- Dependencies (relationships with other recipes)
- License information (GPL, MIT, etc.)
Recipe files typically have the extension .bb (BitBake).
The biggest advantage is that the recipe clearly specifies all build steps and dependencies, ensuring the same results can be obtained regardless of who builds it or where. Utilizing Yocto recipes increases build reproducibility and makes it easier to manage dependencies and licenses. Flexible customization is also possible, contributing to improved product development efficiency and quality. Another major advantage is that it can support multiple architectures and development environments.
1. BSP directory structure of the Yocto Project for i.MX
This article provides an easy-to-understand explanation of the BSP directory structure and role of the Yocto Project for NXP's i.MX series. The purpose is to clarify the characteristics and uses of the build directory, sources directory, and downloads directory, enabling developers to efficiently configure their build environment.
The BSP used in this article is configured based on the imx-linux-mickledore manifest file "imx-6.1.36-2.1.0", which was downloaded using the repo utility.
This BSP is stored in a directory called "imx-Yocto-bsp_6136210". The "6.1.36" in the file name indicates the Linux kernel version.
About i.MX BSP
The i.MX BSPs for all kernel versions up to now have been published in nxp-manifest under nxp-imx (NXP i.MX Linux BSP Software) on GitHub.
In the previous chapter, we explained how to download from the above URL using the repo utility.
When you actually open the URL, the manifest for the latest kernel version will be displayed by default, as shown below.
This article uses the manifest branch imx-linux-micledore. You can select the branch by pulling down the red box in the image below.
This provides a set of manifest files for i.MX processors, including XML files that describe the layer structure and version information required to build the Yocto Project BSP.
BSP directory structure and correlation diagram
The BSP directory contains the build directory, sources directory, and downloads directory.
The diagram below uses arrows to show how the files and directories discussed in this article relate to each part of the BSP.
The roles of the higher level directories are as follows:
・Build directory (bld-imx8qxpc0mek_XX)
This directory is generated when the DISTRO command is executed. It stores the generated build results and the build configuration files (bblayers.conf and local.conf) in the conf directory.
*XX is the build version number.
・sources directory
Stores the source code and configuration files that make up the BSP, including the elements required for building, such as the OS, drivers, and middleware.
・downloads directory
An area for storing external files retrieved from the Internet and packages added manually.
Now, use the command to see the actual directory structure.
BSP Directory Structure
Use the tree command to check the BSP directory structure.
The bld-imx8qxpc0mek_XX directory (XX is the build version number) is the build directory generated when you run the DISTRO command.
nexty@nexty:~/imx-yocto-bsp_6136210$ tree -L 1
.
├── README -> sources/base/README
├── README-IMXBSP -> sources/meta-imx/README
├── bld-imx8qxpc0mek_00
├── bld-imx8qxpc0mek_01
├── bld-imx8qxpc0mek_02
├── bld-imx8qxpc0mek_03
├── bld-imx8qxpc0mek_04
├── bld-imx8qxpc0mek_05
├── bld-imx8qxpc0mek_06
├── bld-imx8qxpc0mek_07
├── bld-imx8qxpc0mek_08
├── bld-imx8qxpc0mek_09
├── bld-imx8qxpc0mek_10
├── bld-imx8qxpc0mek_11
├── bld-imx8qxpc0mek_12
├── bld-imx8qxpc0mek_13
├── downloads
├── imx-setup-release.sh -> sources/meta-imx/tools/imx-setup-release.sh
├── setup-environment -> sources/base/setup-environment
└── sourcesPre-build build directory structure
The conf directory contains the build configuration files bblayers.conf and local.conf.
Use the tree command to check the structure of the conf directory.
nexty@nexty:~/imx-yocto-bsp_6136210$ cd bld-imx8qxpc0mek_06
nexty@nexty:~/imx-yocto-bsp_6136210/bld-imx8qxpc0mek_06$ tree -L 2
.
└── conf
├── bblayers.conf
├── bblayers.conf.org
├── conf-notes.txt
├── local.conf
├── local.conf.org
├── local.conf.sample
└── templateconf.cfgsources directory structure
The sources directory contains the source code and configuration files for configuring the BSP, including the OS, drivers, middleware, and other files required for building.
Check the structure of the sources directory with the tree command.
nexty@nexty:~/imx-yocto-bsp_6136210$ cd sources/
nexty@nexty:~/imx-yocto-bsp_6136210/sources$ tree -L 1
.
├── base
├── meta-arm
├── meta-browser
├── meta-clang
├── meta-freescale
├── meta-freescale-3rdparty
├── meta-freescale-distro
├── meta-imx
├── meta-nxp-demo-experience
├── meta-openembedded
├── meta-qt6
├── meta-security
├── meta-timesys
├── meta-virtualization
└── pokyPart of the downloads directory structure
The downloads directory stores external files and packages required for the build, either obtained from the internet or added manually.
Use the tree command to check the structure of the downloads directory.
nexty@nexty:~$ cd imx-yocto-bsp_6136210
nexty@nexty:~/imx-yocto-bsp_6136210/downloads$ tree -L 1
.
├── 9098_Bridge_and_Native_Labtool_MFG_FW_p230.zip
├── 9098_Bridge_and_Native_Labtool_MFG_FW_p230.zip.done
├── Error-0.17029.tar.gz
├── Error-0.17029.tar.gz.done
├── Inflector-0.11.4.crate
├── Inflector-0.11.4.crate.done
├── Jinja2-3.1.2.tar.gz
├── Jinja2-3.1.2.tar.gz.done
├── Linux-PAM-1.5.2.tar.xz
├── Linux-PAM-1.5.2.tar.xz.done
├── Mako-1.2.4.tar.gz
├── Mako-1.2.4.tar.gz.done
├── MarkupSafe-2.1.2.tar.gz
├── MarkupSafe-2.1.2.tar.gz.done
├── NetworkManager-1.42.4.tar.xz
├── NetworkManager-1.42.4.tar.xz.done2. u-blox module software resource allocation
The u-blox JODY-WE3 series uses the NXP wireless chipset 88Q9098. Place the following three files for the chipset 88Q9098 under the BSP directory:
- Wi-Fi drivers and firmware
- MFG package for RF testing (as needed for testing)
- Yocto recipe for u-blox module integration
To obtain these files, you must enter into a software license agreement with u-blox called e-LULA.
What is e-LULA (Electronic u-blox License User Agreement)?
When using software or firmware included with u-blox products (modules and ICs for GNSS, cellular, Wi-Fi, Bluetooth, etc.), users must agree to a software license agreement. Unlike traditional paper-based contracts, e-LULA supports electronic signatures, making it easy to conclude contracts online. To conclude an e-LULA with u-blox, support from a distributor is required. If you would like to obtain the files required to conclude an e-LULA, please Inquiry Nexty Electronics.
Wi-Fi drivers and firmware
File name: PCIE-WLAN-UART-BT-9098-U16-X86-17.68.1.p149.55-17.26.1.p149.55-MXM5X17405_P42_V0V1-MGPL.zip
Contents: This package contains the Wi-Fi and Bluetooth drivers and firmware for the NXP wireless chipset 88Q9098.
Location: It is located in the BSP downloads directory.
MFG Package for RF Testing
File name: 9098_Bridge_and_Native_Labtool_MFG_FW_p230.zip
Contents: This package includes RF test firmware and bridge application "mfgbridge" for the NXP wireless chipset 88Q9098, as well as the RF test application "Labtool." These drivers are optional and are used for radio wave certification such as technical conformity and ANTENNAS radiation pattern measurements. Please install them as needed by the user.
Location: It is located in the BSP downloads directory.
Now, let's use the tree command to check the downloads directory structure after actually placing the "Wi-Fi driver firmware" and "MFG package for RF testing." The yellow frames in the image show the two files that were placed.
Yocto recipe for u-blox module integration
Directory name: meta-ublox-modules-2025-05-05
What it is: A collection of recipes for integrating u-blox module drivers, firmware, tools, etc. into a Yocto build.
Location: It is placed in the opt/Yocto/Archive directory under the root directory.
3. Edit the configuration files local.conf and bblayers.conf
The conf directory under the build directory generated by the distro command contains two configuration files: local.conf and bblayers.conf. We will now edit these files and add settings to the default settings to incorporate the u-blox module into Yocto.
Editing points for local.conf
The settings you need to add to the local.conf file are as follows:
- Installing the package group for the u-blox module
- JODY-W3 series model specification
- Installing various applications (iperf, hostapd, networkmanager, etc.)
- Image file type specification (file with wic extension)
- Specifying a package version
Below is the content of the local.conf file after editing, with the part in the red box being the added part.
Key points for editing bblayers.conf
The settings you need to add to the bblayers.conf file are as follows:
- Specify the directory where the recipes for the u-blox module are stored
Below is the edited content of bblayers.conf, with the added parts highlighted in red.
4. Delete unnecessary model files from the recipe
The default Yocto recipe provided by u-blox includes files for multiple modules (e.g. JODY-W3, TOBY, LARA, etc.) In this article, we have deleted files for models other than JODY-W3 to avoid build errors caused by unnecessary files.
We won't go into detail about the recipe here, but please refer to the comments in the file for the contents. Edited recipe The main directory structure of the meta-ublox-modules layer is as follows:
/opt/Yocto/Archive/meta-ublox-modules-2025-05-05$ tree -L 3
├── CHANGELOG.md ＃変更履歴
├── LICENSE ＃ライセンス情報
├── README.md ＃説明書
├── RELEASE_NOTES.md ＃リリースノート
├── classes ＃ビルド用クラスファイル
│ ├── ubx-compile-qa.bbclass
│ ├── ubx-getversion.bbclass
│ ├── ubx-mrvl-txpowerlimits.bbclass
│ ├── ubx-nxp-txpowerlimits.bbclass
│ └── ubx-sanitize.bbclass
├── conf ＃レイヤー設定ファイル
│ └── layer.conf
├── files ＃追加ライセンスやファームウェア
│ └── additional-licenses
├── recipes-connectivity # hostapdやwpa-supplicantなど無線通信関連レシピ
│ ├── brcm-patchram-plus
│ ├── hostapd
│ ├── mrvl-nci
│ ├── wapi-ap-app
│ ├── wireless-regdb
│ ├── wpa-supplicant
│ └── wpa-supplicant-mrvl-wapi
├── recipes-core ＃u-bloxモジュール用パッケージグループ定義
│ └── packagegroups
├── recipes-devtools ＃LabtoolやMFG パッケージのレシピ
│ ├── jody-w3-labtool ＃JODY-W3用Labtoolのレシピ
│ └── jody-w3-mfg ＃JODY-W3用MFG パッケージのレシピ
└── recipes-kernel #ドライバー関連レシピ
└── jody-w3-driver-pcieuart ＃JODY-W3用ドライバーのレシピ[Hands-on] Building a Linux image in the Yocto Project
Once you have completed the steps above, build the Yocto project that includes the u-blox module. The build command is bitbake.
For more information about build commands, please refer to the NXP user's guide "i.MX Yocto Project User's Guide" and the Nexty Electronics technical column.
- https://www.nxp.com/docs/en/user-guide/UG10164.pdf
- Building an i.MX Development Environment (Yocto Edition) | Technical Column
An example of a build execution is shown below.
ビルド実行例
nexty@fnexty:~/imx-Yocto-bsp_6136210/bld-imx8qxpc0mek_09$ bitbake core-image-minimal
ビルド成功時ログ抜粋
Loading cache: 100% |
| ETA: --:--:--
Loaded 0 entries from dependency cache.
Parsing recipes: 100%
Time: 0:00:50
Parsing of 3448 .bb files complete (0 cached, 3448 parsed). 5311 targets, 375 skipped, 18 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies
Build Configuration:
BB_VERSION = "2.4.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "ubuntu-20.04"
TARGET_SYS = "aarch64-poky-linux"
MACHINE = "imx8qxpc0mek"
DISTRO = "fsl-imx-xwayland"
DISTRO_VERSION = "6.1-mickledore"
中略
0: linux-imx-6.1.36+gitAUTOINC+04b05c5527-r0 do_compile - 38m49s (pid 990326)
1: rust-llvm-native-1.68.2-r0 do_compile - 34m13s (pid 1101364) 32%
2: mesa-2_23.0.3-r0 do_compile - 5m32s (pid 2254232) 52% |######################################################################
Setscene tasks: 1849 of 1849
WARNING: linux-imx-6.1.36+gitAUTOINC+04b05c5527-r0 do_package_qa: QA Issue: File /usr/src/debug/linux-imx/6.1.36+gitAUTOINC+04b05c5527-r0/drivers/tty/vt/consolemap_deftbl.c in package linux-imx-src contains reference to TMPDIR
File /usr/src/debug/linux-imx/6.1.36+gitAUTOINC+04b05c5527-r0/drivers/video/logo/logo_linux_clut224.c in package linux-imx-src contains reference to TMPDIR
File /usr/src/debug/linux-imx/6.1.36+gitAUTOINC+04b05c5527-r0/lib/oid_registry_data.c in package linux-imx-src contains reference to TMPDIR [buildpaths]
NOTE: Tasks Summary: Attempted 4589 tasks of which 0 didn't need to be rerun and all succeeded.The above log shows that all tasks were completed successfully. This time, the build took about 2 hours to complete.
TIPS: When a build error occurs, use generative AI!
If an error occurs during a build, it is important to first check the displayed log and identify the cause. In recent years, using generative AI to analyze logs has become an effective method. By inputting the details of the error into AI, it is possible to obtain hints on the cause and countermeasures.
Here we will introduce an example of using generative AI for error analysis.
Yocto build aborted due to fetch error?
In Yocto builds, network issues, repository changes, etc. can cause fetch errors, which can lead to builds being interrupted due to failure to download necessary source files. In fact, the following error log was displayed:
NOTE: Tasks Summary: Attempted 250 tasks of which 17 didn't need to be rerun and 3 failed.
Summary: 3 tasks failed:
virtual:native:/home/fukumoto/imx-Yocto-bsp_6136210/sources/poky/meta/recipes-devtools/perl/perl_5.36.0.bb:do_fetch
virtual:native:/home/fukumoto/imx-Yocto-bsp_6136210/sources/poky/meta/recipes-devtools/perl-cross/perlcross_1.4.bb:do_fetch
virtual:native:/home/fukumoto/imx-Yocto-bsp_6136210/sources/poky/meta/recipes-extended/bzip2/bzip2_1.0.8.bb:do_fetch
Summary: There were 7 WARNING messages.
Summary: There were 6 ERROR messages, returning a non-zero exit code.
When we input the error log into the generating AI and asked it how to deal with the problem, we received the following response:
Summary of the generated AI's answers
- Error analysis results: Multiple source files (tar.gz), such as perl-5.36.0.tar.gz and bzip2-1.0.8.tar.gz, could not be retrieved from the URL.
- Suggested solutions: 1) Check network connectivity, 2) Check URL validity, 3) Manually download the necessary files and place them in the Yocto downloads directory, 4) Utilize MIRRORS settings and review proxy settings.
Actual example of how to deal with this
One of the suggested solutions involved manually downloading the necessary files and placing them in the Yocto downloads directory, which resolved the error and allowed the build to succeed.
TIPS Where is the image file after building?
When you run a Yocto build, a build directory (bld-imx8qxpc0mek_XX) is generated. The build results are saved in multiple subdirectories within this build directory. The main save locations are as follows:
Main build artifact storage location
| directory | Content |
|---|---|
| tmp/deploy/images/<machine> | Final Linux image (e.g. rootfs, kernel, bootloader, etc.) |
| tmp/work/<recipe>/<version>/ | Intermediate build files, logs, installed files, etc. for each recipe |
| tmp/deploy/sdk/ | SDK (cross-compilation environment) deliverables |
| tmp/sysroots/ | System roots to build (dependent libraries, etc.) |
| tmp/sysroots/ | Reusable build cache (used for speed) |
<machine> is the target board name (e.g. imx8qxpc0mek).
Under mp/work, build logs and installation details for each recipe are recorded in detail, which is useful for troubleshooting.
When you run the Yocto build, you can see that the image file core-image-minimal-imx8qxpc0mek-20250623221121.rootfs.wic has been generated in the tmp/deploy/images/imx8qxpc0mek directory (circled in red).
Example of directory structure after build (tree command output)
[Practice] From writing the built Yocto image to starting and debugging
Write Yocto build image to eMMC with uuu command
This article explains the procedure for writing a Linux image built with Yocto to the eMMC of the i.MX8 evaluation board.
The connection configuration for the i.MX8 evaluation board, M.2-JODY-W377 module, debug PC, and build PC used in this experiment is as follows. The build PC (Ubuntu) generates a Linux image using Yocto and writes it to the eMMC on the evaluation board using the uuu command. The debug PC (Windows) connects to the debug port on the evaluation board via Micro USB and monitors the boot and write logs in real time. In the event of a write failure or boot failure, analyzing the logs will help identify the cause.
System configuration diagram for writing images to the i.MX8 evaluation board
Actual system environment for writing images to the i.MX8 evaluation board
The steps for setting up the hardware and executing commands to write an image to the i.MX8 evaluation board are as follows:
1. Connect the build PC (Ubuntu) and the i.MX8 evaluation board with a USB Type-C CABLES. This connection allows you to write the built image directly to the eMMC.
2. Connect the debugging PC (Windows) to the Micro USB debugging TERMINALS on the i.MX8 evaluation board so that you can monitor the serial log during programming and startup in real time.
3. Before writing the image, insert the M.2-JODY-W377 module into the M.2 CONNECTORS on the i.MX8 evaluation board.
4. When writing the image, set the BOOT MODE SWITCHES on the i.MX8 evaluation board to "SERIAL", which switches to writing mode via USB.
BOOT MODE SWITCHES SERIAL setting
5. After POWER SUPPLIES on the i.MX8 evaluation board, go to the directory where the image file is stored on the build PC (Ubuntu).
nexty@nexty:~$ cd imx-Yocto-bsp_6136210/bld-imx8qxpc0mek_09/tmp/deploy/images/imx8qxpc0mek6. Execute the "uuu" command (Universal Update Utility provided by NXP) to write the Linux image to the eMMC.
sudo uuu -b emmc_all image file name
The following is an example of a log that shows the uuu command being executed on the build PC (Ubuntu) and the Linux image being successfully written to the eMMC of the i.MX8 evaluation board.
nexty@nexty:~/imx-Yocto-bsp_6136210/bld-imx8qxpc0mek_09/tmp/deploy/images/imx8qxpc0mek$ sudo uuu -b emmc_all core-image-minimal-imx8qxpc0mek-20250623221121.rootfs.wic
[sudo] nexty のパスワード:
uuu (Universal Update Utility) for nxp imx chips -- libuuu_1.5.182-0-gda3cd53
Success 1 Failure 0
1:113- 3/ 3 [=================100%=================] SDPV: jump -scanlimited 0x800000
1:113-D16810 8/ 8 [Done
If "Success 1 Failure 0" is displayed, the image writing was completed successfully. If it failed, please check the connection and BOOT MODE setting again.
For information on how to install the uuu command, as well as detailed usage and troubleshooting, please refer to the NEXTY Electronics Technology Column (uuu Edition).
How to debug the i.MX8 evaluation board: Using USB serial connection and Ethernet SSH
There are two ways to debug an i.MX8 evaluation board equipped with the u-blox JODY-W3: via USB serial connection or via Ethernet SSH connection. This article provides an easy-to-understand explanation of the procedures and key points for each.
General preparation: Boot mode setting
Before debugging, set the BOOT MODE SWITCHES on the evaluation board to "eMMC." This will boot the Linux system from the image written to the eMMC.
Actual state of the debug environment system of the i.MX8 evaluation board after image writing and eMMC setting of the BOOT MODE SWITCHES
1. Debugging via USB-serial connection
This method is effective when you want to check the startup log in real time.
Configuration overview
Connection method: Connect the debugging PC (Windows) and evaluation board with a Micro USB CABLES
Tool used: Tera Term (serial communication software)
USB-serial debug connection configuration for i.MX8 evaluation board
Steps
1. Connect the debug PC and the i.MX8 evaluation board via Micro USB.
2. POWER SUPPLIES on the i.MX8 evaluation board.
3. In the Device Manager of the debugging PC, check that the i.MX8 evaluation board is recognized as a COM port.
4. Start Tera Term, create a new serial connection, and select the appropriate COM port.
5. Set the baud rate of the serial connection to 115200bps.
6. When the "login:" prompt appears, log in with the username "root".
7. If the "~#" prompt appears, the Linux system has been successfully booted from the image written on the i.MX8 evaluation board.
imx8qxpc0mek login: root
root@imx8qxpc0mek:~#8. When shutting down, be sure to execute the poweroff command before turning off POWER SUPPLIES.
root@imx8qxpc0mek:~#poweroff9. To check the startup log from the initial state, turn POWER SUPPLIES on again and you will be able to check the startup log from the initial state.
2. Debugging via Ethernet SSH connection
This is useful when you want to log in via a network and perform more flexible operations.
Configuration overview
Connection method: Connect the debug PC and evaluation board with a LAN CABLES
Tools used: Tera Term (SSH connection)
i.MX8 Evaluation Board Ethernet SSH Login Debug Connection Configuration
Steps
1. Connect the debug PC and the i.MX8 evaluation board with a LAN CABLES.
2. POWER SUPPLIES on the i.MX8 evaluation board.
3. Open the "Network and Sharing Center" on the debug PC. Click "Change adapter settings" on the left side of the screen.
4. A list of Internet connections will be displayed, so double-click the icon for "Ethernet," which is a wired LAN. Click "Properties" under Operation Status to open the "Ethernet Properties" window. Select "Internet Protocol Version 4 (TCP/IPv4)" on the "Network" tab and click "Properties." The "Internet Protocol Version 4 (TCP/IPv4)" window will open, so check "Use the following IP address" on the "General" tab, enter the IP address and subnet mask, and set a fixed IP address as the default gateway.
5. Open the "Wi-Fi Properties" window, and check "Internet Connection Sharing" on the "Sharing" tab to bridge the Wi-Fi and Ethernet subnetworks.
6. After setting up, unplug the LAN CABLES and plug it back in.
7. Start PowerShell on the debug PC and run the arp -a command. From the command output, check the Ethernet IP address assigned to the i.MX8 evaluation board by DHCP. The Ethernet IP address is framed in red in the image.
*If you cannot obtain an IP address, uncheck "Internet Connection Sharing" in the Ethernet properties, click OK, and then try steps 5 to 7.
8. Create a new connection in Tera Term, enter the IP address of the i.MX8 evaluation board you just obtained in the TCP/IP settings, and connect.
9. If a security warning screen appears, click "Continue". If an SSH authentication screen appears, enter "root" as the user name and click OK.
10. If the "~#" prompt appears, the image has been successfully written to the i.MX8 evaluation board and the Linux system has booted successfully.
11. When shutting down, be sure to execute the poweroff command before turning off POWER SUPPLIES.
root@imx8qxpc0mek:~#poweroffSummary
This article explains how to build a Linux development environment using the Yocto Project, using a u-blox JODY-W3 series Wi-Fi module and an NXP i.MX8 evaluation board. It also covers the entire process, from driver and firmware integration, building, image writing, and boot debugging, as well as know-how specific to host-based Wi-Fi modules.
We hope that the contents of this article will be helpful to those who are considering embedded Linux development or introducing Wi-Fi modules.
Please feel free to contact Nexty Electronics for any implementation or evaluation inquiries!
Related Info
NEXTY Electronics Partnered Manufacturers: u-blox, NXP
Nexty Electronics Related Articles
Inquiry
Link to Related Technical Columns
Related Product Information
CO2 sensor demo system
Our CO2 sensor demo system transmits measured CO2 values via BLE to a dedicated Android app, and the measurement results can be displayed in graphs.
- Infineon Technologies AG
- ICT and Industrial
- Smart Factories and Robotics
Introduction to Edge AI Solutions with NXP's NPU-equipped i.MX/MCX
This article explains the rapidly growing edge AI with real device examples and introduces NXP’s processors and microcontrollers equipped with NPUs.
- NXP Semiconductors NV
- NEXT Mobility
- ICT and Industrial
- Smart Factories and Robotics
Motion Controllers and Motor Drivers for Stepping Motors
Our industry-leading motion control products improve energy efficiency, prevent loss of synchronization, and reduce motor noise and vibration, making them ideal for fields requiring advanced control.
- Analog Devices, Inc.
- NEXT Mobility
- ICT and Industrial
An In-Depth Look at the Features of NXP's Automotive CAN/LIN Transceiver Products
This article explains the features of NXP’s automotive CAN/LIN transceivers, designed to withstand harsh in-vehicle conditions, for ECU developers looking for reliable in-car network products.
- NXP Semiconductors NV
- NEXT Mobility
- ICT and Industrial
ミリ波レーダーを活用した在室検知 簡易デモシステム
高精度・低消費電力の在室検知デモシステムです。プライバシーに配慮した人物検知で、会議室の利用状況把握やバス置き去り防止に貢献します。
- Acconeer AB
- NEXT Mobility
- ICT and Industrial
ソフトウェア保護・暗号化とライセンシングソリューション
Wibu-SystemsのCodeMeterは、ソフトウェアの違法コピー対策、知的財産保護、収益化を強力に実現するソリューションです。
- WIBU-SYSTEMS AG
- ICT and Industrial
- Smart Factories and Robotics
- Software
