Building an i.MX Development Environment (Yocto Edition) | Technical ColumnYocto ProjectI used it to build the i.MX BSP.
Once the build is complete, use the build toolbitbakeLet's take a look at the directories that were created. Knowing what kind of directories were created will improve development efficiency and be useful for troubleshooting.
In this article, I will organize and introduce frequently used directories using the environment where I built the i.MX BSP as an example. There are many directories, but I will focus on the directories that I Access frequently during development.
The directory to be introduced is here. The directory location isconf/local.confWe assume you have not changed the directory location in
Below, we will quote 4 Source Directory Structure from the Yocto Project Reference Manual as appropriate.
The following content is an image using NXP's BSP (L6.12.3_1.0.0) for the i.MX 95 Verdin evaluation kit.imx-image-fullThis has been checked in the build environment.
${BBPATH}/tmp
${BBPATH}teethbitbakeThis is an environment variable that is defined when you enable , and it points to the build directory (<build/directory> in the commands below) that you passed when you executed the following command.
$ source setup-environment
... (出力は省略)
$ echo ${BBPATH}
=> <build/directory> が出力される
In this article, we will change the output to show the build directory.${BBPATH}The actual output will show the path, so please read it accordingly.
Now that the preamble is over,tmpLet's start talking about.bitbakeWhen I build a Linux image with${BBPATH}Directly belowtmpThis will create a directory called .
tmpThe word "temporary" comes from the word "temporary." Here is a relevant quote from the Yocto Project Reference Manual:
Note
By default, the Build Directory contains TMPDIR, which is a temporary directory the build system uses for its work.
This is my personal interpretation, but I think the meaning of temporary is "directories and files in this directory will be deleted by bitbake."
"It's okay because it's managed with git"
It is not. Depending on the bitbake subcommand or option, the entire git management directory may be deleted.tmpDo not develop under this directory.
Now let's move on to the next level.
work
The source code and intermediate files required for the build are saved by recipe. Logs of task execution are also saved, so if an error occurs during the build, you can search for the cause in this directory.
workSeveral directories are created under this directory. In this environment, the following were created:
- all-poky-linux
- armv8a-mx95-poky-linux
- armv8a-poky-linux
- imx95_19x19_lpddr5_evk-poky-linux
- imx95_19x19_verdin-poky-linux
- recipetool-o3wixn8f
- x86_64-linux
These are in each recipeMULTIMACH_TARGET_SYSThe reason for this division is to classify the build results into recipes that can share build results and those that cannot when building images for different targets in the same build directory.
work-shared
It is used in some special recipes. When built under these conditions, the following directory was created:
- gcc
- llvm
- linux kernel
This directory is provided for efficient builds and appears to be used in recipes that meet the following conditions:
- The source code is large
- Several recipes use the same source code
The relevant part of the documentation is excerpted below:
4.2.8.12 build/tmp/work-shared/
For efficiency, the OpenEmbedded build system creates and uses this directory to hold recipes that share a work directory with other recipes.
You can see that it says "For efficiency".
deploy
This is where the final build artifacts are stored, each with its own directory.
Let's look at the lower directories.
images
This is the location where the Linux image is stored. In addition to the Linux image, it also stores the device tree file and boot loader.
deb
The i.MX BSP is by defaultconf/local.confSince the following settings are present, the results of the recipe will be packaged into a .deb package.
# Switch to Debian packaging and include package-management in the image
PACKAGE_CLASSES = "package_deb"
The .deb files created by each recipe are stored here.
Summary
This time, we introduced the directories that are often referenced during development from the build directory created by bitbake.
If the build went smoothly, there would be no need to refer to these, but in reality, this is not always the case. Bitbake stores build intermediate products and logs in directories created according to rules, so if you understand the directory structure, you can quickly access the logs and working directory.
NEXTY Electronics' development team offers proposals and support for product development that utilizes NXP's i.MX series.
We also use the latest i.MX9 series, so please feel free Inquiry.
bonus
deployHere is a brief introduction to the files other than the Linux image stored in the directory.
Manifest File
.manifestThis file has the extension . This file lists the packages included in the image. You can check whether the built image contains the expected recipes before writing it.
A manifest file is also created in the SDK. This was an unnecessary addition, since we weren't talking about the SDK this time.
Publish the built deb file on the apt server
This content is Apt the package created with bitbake (but only for debugging purposes) of Almost tracing I find this very helpful.
For example, you may want to add libraries or tools to a built image later in the following situations:
- There are apps that you just want to explore, and the changes aren't so extensive that they require a remake.
- I want to temporarily add a development package for debugging purposes.
- I want to use the software I always use on the actual device.
In such cases, transfer the files in the deb directory to the actual device,dpkgoraptHowever, this method requires you to find all the dependent packages and manually transfer them to the actual device, which can be quite a pain.
Therefore, we will set up an apt server on the build PC and distribute the deb packages stored in the deb directory from this server, so that packages can be added and updated from the actual device using the apt command.
The steps are as follows:
-
・ Build PC
- 1.
aptCreating indexes - 2.
aptStarting the server
- 1.
-
Actual machine
- 1.Connection destination
aptServer Configuration - 2.Time setting
- 3.
aptExecuting commands
- 1.Connection destination
Build PC - 1.aptCreating indexes
bitbakeIf you use the recipe provided by
$ bitbake vim # 追加したいパッケージが `IMAGE_INSTALL`にない場合はビルドしておきます
$ bitbake package-index
dpkg-scanpackages(aptIf you use the commands provided by
$ sudo apt install dpkg-dev
$ cd ${BBPATH}/tmp/deploy/deb
$ dpkg-scanpackages . /dev/null | gzip -9c > Packages.gz
Both give roughly the same results.bitbakeI think it's easier to use .
Build PC - 2.aptStarting the server
Start an HTTP server. I think it's easiest to use Python.
$ sudo apt install python3
$ cd ${BBPATH}/deploy/
$ python3 -m http.server 8000
Actual device - 1. Connection destinationaptServer Configuration
To connect to the apt server/etc/apt/sources.listFile or/etc/apt/sources.list.d/You need to create a file in the directory.
The contents are as follows.<server address>Please set the IP address or URL of the build PC.
bitbake package-indexIf you create an index with
deb [trusted=yes] http://<server address>:8000/deb/all ./
deb [trusted=yes] http://<server address>:8000/deb/cortexa55 ./
deb [trusted=yes] http://<server address>:8000/deb/cortexa55-mx95 ./
deb [trusted=yes] http://<server address>:8000/deb/toradex_smarc_imx95 ./
dpkg-scanpackagesIf you create an index withdeb [trusted=yes] http://<server address>:8000/deb ./
Because the certificate is omitted,[trusted=yes]AddaptIt forces you to trust it.
The above files can also be created with bitbake and added to the image. If you refer to the Yocto documentation, the procedure and explanation are as follows: 28.4.1 Build Considerations
You can use the PACKAGE_FEED_ARCHS, PACKAGE_FEED_BASE_PATHS, and PACKAGE_FEED_URIS variables to pre-configure target images to use a package feed. If you do not define these variables, then manual steps as described in the subsequent sections are necessary to configure the target. You should set these variables before building the image in order to produce a correctly configured image.
PACKAGE_FEED_ARCHS, PACKAGE_FEED_BASE_PATHS, PACKAGE_FEED_URISBy setting this, a configuration file to Access the repository will be automatically created and added to the image. In the case of apt, it will look like this:
PACKAGE_FEED_URIS = "https://<server address>:8000"
PACKAGE_FEED_BASE_PATHS = "deb"
PACKAGE_FEED_ARCHSIf you do not set this, a configuration file will be created that targets all files built for the actual device.
Actual Machine - 2. Time Setting
apt updateIn order for this to work properly, the time on the server and the actual machine must be roughly the same. During the experiment, updates were possible even if the time was off by about half a day, but it is better if the time is the same.
There are several ways to do this, but the easiest isdateI think the way to do this is to use commands.
- On the build PC, run the following:
# date -u +%m%d%H%M%Y.%S
- Copy the output of this command
- Run the following on the device:
# date -u <2.でコピーした結果を貼り付け>
# date #日付が設定されていることを確認
Actual machine -3.aptExecuting commands
Now you can run the package built on the build PC from the actual device.aptYou can get it with the command:
Make sure that the actual device and the build PC are connected via Ethernet.aptRun:
# apt update
(出力省略)
# apt info vim
vim/unknown 9.1.1652-r0 arm64
# apt install vim
(以下略)
Related Information and References
Inquiry
Link to Related Technical Columns
Related Product Information
An In-Depth Look at the Advantages of NXP's Automotive Microcontroller S32K1
NXP's S32K1 series of automotive microcontrollers incorporates the ARM Cortex-M0+ and M4F cores, achieving high processing power and low power consumption. We will thoroughly explain its appeal and features.
- NXP Semiconductors NV
- NEXT Mobility
An In-Depth Look at the Advantages of NXP's Automotive Microcontroller S12 MagniV
NXP’s integrated microcontroller, S12 MagniV, helps miniaturize ECUs and shorten development time, contributing to the electrification of automotive systems. This article explains its features and benefits.
- NXP Semiconductors NV
- NEXT Mobility
- ICT and Industrial
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
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
Introduction to NXP's Automotive General-Purpose Microcontroller Products
NXP’s general-purpose automotive microcontrollers—S32K1, S12 MagniV, and S32K3 families—combine high performance, security, and cost efficiency to support the advancement of automotive technologies.
- NXP Semiconductors NV
- NEXT Mobility
NXP Automotive Microcontroller S32K311 Evaluation Board by NEXTY Electronics
The S32K311 is NXP's latest automotive microcontroller, offering high performance in a small package and the latest features at a low cost. We will introduce its features and our own S32K evaluation board.
- NXP Semiconductors NV
- NEXT Mobility
