The UUU (Universal Update Utility) is an open source program provided by NXP, which is the successor of NXP's MFG Tools, intended to download and execute code on the i.MX SoC family via the Serial Download Protocol (SDP). Documentation, source code, and prebuilt tool releases are available via the NXP mfgtools github repository.
IMX_SOC_REV:${MACHINE} ?= "A0" OEI_DDRCONFIG = "TQMa95xxSA.DDR-Timing.${OEI_RAM_SIZE}GB.V16.0005"
If you have not built your software for the correct SOC revision, problems and crashes will occur when using the UUU tool.
imx-boot-tqma95xxsa-*-sd.bin-flash_a55*.wic or *.wic.zst (e.g., tq-image-generic-debug-tqma95xxsa-4gb-mb-smarc-2.rootfs.wic.zst)To communicate with the module via USB, it must be set to βSerial Downloadβ mode.
S3
1 - 3 have no effect
uuu -lsusb.To initially boot the board (e.g., with an empty flash memory), U-Boot can be loaded directly into RAM without writing to the eMMC.
Execute the following command in the folder containing the UUU binary and the bootstream:
sudo uuu <bootstream>
Example for the TQMa95xxSA:
sudo uuu imx-boot-tqma95xxsa-4gb-mb-smarc-2-sd.bin-flash_a55
This command boots the board and uses the booted system to flash the bootstream and the WIC image to the eMMC.
sudo uuu -bmap -b emmc_all <bootstream> <wic-image>
Example for the TQMa95xxSA:
sudo uuu -bmap -b emmc_all imx-boot-tqma95xxsa-4gb-mb-smarc-2-sd.bin-flash_a55 tq-image-generic-debug-tqma95xxsa-4gb-mb-smarc-2.rootfs.wic.zst
For custom flashing procedures (e.g., if you want to program a WIC image to eMMC without writing the boot stream to the eMMC boot partition), UUU commands can be collected in a cmdlist file.
uuu.tqma95xxsa) in the same directory as the UUU tool.BOOTSTREAM and WICIMAGE variables:uuu -e BOOTSTREAM=<bootstream> -e WICIMAGE=<wic image> uuu.tqma95xxsa
An example of a custom script can be found here:
uuu_version 1.5.4
SDPS: delay 500
SDPS: @ boot -f @BOOTSTREAM@
SDPV: delay 1000
SDPV: @ write -f @BOOTSTREAM@ -skipspl -scanterm -scanlimited 0x800000
SDPV: jump -scanlimited 0x800000
FB: ucmd setenv fastboot_dev mmc
FB: ucmd setenv mmcdev ${emmc_dev}
FB: ucmd mmc dev ${emmc_dev}
FB: @ flash -raw2sparse all @WICIMAGE@
FB: done
If the wrong protocol is used in the UUU script (e.g., using SDP instead of SDPS on the i.MX95), the UUU tool will detect the USB device, but the transfer will permanently freeze at the first command (e.g., visible as a hang at 1/ 0 [).
By running the command
uuu.exe -v
(without any further arguments), the UUU tool lists its internal configuration. In the Pctl (Protocol) column, you can look up the correct protocol prefix assignment for the respective chip (in the Chip column).
Example excerpt:
Pctl Chip Vid Pid BcdVersion Serial_No
==================================================
SDPS: MX93 0x1fc9 0x014e
SDPS: MX95 0x1fc9 0x015d
SDP: MX6Q 0x15a2 0x0054
SDP: MX8MM 0x1fc9 0x0134
Here you can see that an i.MX8MM script must begin with SDP:, while an i.MX95 script strictly requires SDPS:.
| Reference | Explanation |
|---|---|
| <machine> | Target machine name (e.g., tqma62xx, tqma8mpxl, etc.) |
| <build-dir> | Build directory name (e.g., tqma62xx_build) |
| <arch> | CPU architecture (e.g., arm64, arm) |
| <kernel-recipe> | Linux kernel recipe name (e.g., linux-ti-tq, linux-tq, linux-imx) |
In preparation for this guide, the default BSP image (e.g. tq-image-weston-debug) has to be built according to the module specific quickstart BSP instructions.
During the evaluation, package(s) may be missing in the TQ BSP default image configuration. If you're looking for specific recipes or layers, the OpenEmbedded layer index layer index is a good place to start.
Adding package(s) to the build may require adding additional Yocto meta layer(s)
The easiest approach to add a package recipe to the build, is to use the use IMAGE_INSTALL:append variable in the conf/local.conf file, which is located in the current build space.
Open a new terminal on the development host and navigate into the workspace directory and initialize the build environment as described in the Quickstart BSP:
cd ~/workspace/<path-to-ci-meta-tq> source setup-environment <build-dir>
The example below demonstrates how to add the editor nano (which is part of the meta-oe Yocto layer) to the build.
Open conf/local.conf with an editor of choice and insert the following lines at the end of the file:
IMAGE_INSTALL:append = " nano"
Multiple packages can also be added using the IMAGE_INSTALL:append variable. This can be done in one line or multiple lines, shown in the two code examples below.
IMAGE_INSTALL:append = " <recipe-name_1> <recipe-name_2>" # OR IMAGE_INSTALL:append = " \ <recipe-name_1> \ <recipe-name_2> \ "
Once the desired package(s) have been added, the image can be rebuilt by executing:
bitbake tq-image-weston-debug
Note: Changes to local.conf only affect the current build space. They will be lost when the build space is reset.
For customer-specific adaptations, we recommend creating an own Yocto meta-layer. For this purpose Bitbake provides a script that simplifies the process of creating new layers.
It creates a template meta-layer with basic structure.
To add a template layer to ci-meta-tq/sources, using the bitbake-layers create-layer script:
cd ~/workspace/<path-to-ci-meta-tq>/sources bitbake-layers create-layer meta-custom
Before making changes to the new layer, it is recommended to perform the following actions:
π meta-custom/
βββ π conf/layer.conf
βββ π README
βββ π recipes-images/
β βββ π images/
β βββ π tq-image-weston-debug.bbappend (Add packages)
βββ π recipes-kernel/
βββ π linux/
βββ π <kernel-recipe>/
β βββ π example.cfg (Kernel Config Fragments)
β βββ π example.patch (Kernel source code patch)
βββ π <kernel-recipe>.bbappend (Includes .cfg and .patch)
Create a git repository for the new layer
Version control with Git is best practice in software development, so we recommend initializing the new meta-layer as a Git repository.
Move into the directory of the new custom layer:
cd ~/workspace/<path-to-ci-meta-tq>/sources/meta-custom git init git add . git commit -m "Initial Commit"
Configure layer priority
The bitbake-layers create-layer script sets a layer priority of 6 by default. To ensure the custom layer has the higher priority, set the priority BBFILE_PRIORITY_meta-custom to a higher value (e.g., β10β) in conf/layer.conf.
BBFILE_PRIORITY_meta-custom = "10"
Adding the new layer to the build
Before the new layer can be used, it must be added to conf/bblayers.conf in the build directory.
echo 'BBLAYERS += "${BSPDIR}/sources/meta-custom"' >> conf/bblayers.conf
The advanced approach is to add packages by creating *.bbappend files to expand the original image recipe (Yocto recipe) without changing it.
In general:
meta-tq/meta-dumpling.Create the .bbappend file in custom Yocto layer:
mkdir -p ~/workspace/<path-to-ci-meta-tq>/sources/meta-custom/recipes-images/images cd ~/workspace/<path-to-ci-meta-tq>/sources/meta-custom/recipes-images/images touch tq-image-weston-debug.bbappend nano tq-image-weston-debug.bbappend
Add lines below to the new .bbappend file:
IMAGE_INSTALL:append = " <recipe-name>" # Example: IMAGE_INSTALL:append = " nano"
For your .bbappend file to work properly, please keep in mind that you should have removed the package (e.g. nano) from the local.conf file if it was added to the build there before. Rebuild the image:
bitbake tq-image-weston-debug
The Linux kernel configuration is usually defined in a defconfig file (in-tree or out-of-tree) and expanded by TQ-specific fragments.
Using Linux kernel config fragments requires that the kernel recipe is based on linux-yocto.
Create the path:
Recreate the path to the kernel recipe in the custom layer.
Find the kernel recipe corresponding to the machine configuration linux-ti-tq, linux-imx, linux-tq.
Path: ci-meta-tq/sources/meta-custom/recipes-kernel/linux/<kernel-recipe>/<machine>
Menuconfig:
Navigate to the build directory and open menuconfig:
bitbake -c menuconfig virtual/kernel
Diffconfig:
After making changes and saving, create the fragment:
bitbake -c diffconfig virtual/kernel # The shell will output the path to a fragment.cfg.
Move Fragment:
Move this file to the custom layer path created in Step 1 and rename it (e.g., example.cfg).
Create bbappend:
Create a .bbappend file for the kernel (e.g., <kernel-recipe>.bbappend) in recipes-kernel/linux/ inside the custom layer.
FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:" SRC_URI += "file://example.cfg"
Rebuild:
bitbake -c cleansstate virtual/kernel bitbake tq-image-weston-debug
Creating the patch
1. Navigate to the kernel source directory (usually located in tmp/work-shared/β¦/kernel-source):
cd ~/workspace/ci-meta-tq/<build-dir>/tmp/work-shared/<machine>/kernel-source
2. Make changes to the source code (e.g., Device Tree in arch/<arch>/boot/dts/β¦).
3. Create a patch using git:
git diff > example.patch
4. Move example.patch to the custom layer (same path as the .cfg file above).
Add patch to the build
Add the patch to the SRC_URI variable in the kernel .bbappend file (created in the previous section):
FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:" SRC_URI += "file://example.patch"
Rebuild the kernel and image as described above.
For extensive development, using a local git repository is recommended.
1. Clone sources:
Clone the relevant TQ kernel repository to a local folder (e.g., local_repos).
2. Branch:
Create a custom branch and commit the changes locally.
3. Get Commit ID:
Note the commit ID using git rev-parse HEAD.
4. Update bbappend:
In the meta-custom layer, update the kernel .bbappend to point to the local file path.
# Remove the original upstream source SRC_URI_remove = "${TQ_GIT_BASEURL}/<repo-name>.git;protocol=${TQ_GIT_PROTOCOL};branch=${SRCBRANCH}" # Add local source SRC_URI_append = "git://${BSPDIR}/../local_repos/<repo-name>;protocol=file;branch=${SRCBRANCH}" SRCBRANCH = "custom-branch" SRCREV = "<Commit-ID>"
Finally, rebuild the kernel:
bitbake -c build virtual/kernel
Once the build process is successfully completed, the generated images, kernel binaries, and device trees need to be located for deployment onto the target hardware.
All final build artifacts are deployed in the following directory:
cd ~/workspace/ci-meta-tq/<build-dir>/tmp/deploy/images/<machine>/
Look for files ending in .wic, .ext4, or .tar.gz for the root filesystem, and Image / .dtb files for the kernel and device tree.
If changes made in a .bbappend file do not seem to take effect, it is crucial to verify if BitBake is actually parsing and applying the custom append file.
To list all recipes and their applied .bbappend files, use the following command:
bitbake-layers show-appends
Search the output for the modified recipe (e.g., tq-image-weston-debug). The custom layer path should be listed under the recipe name.
To verify if a variable (such as IMAGE_INSTALL) contains the newly added packages, the BitBake environment can be printed and filtered:
bitbake -e tq-image-weston-debug | grep ^IMAGE_INSTALL=
This outputs the exact string BitBake uses for the variable after parsing all layers and overrides.
The Yocto build system utilizes heavy caching (Shared State Cache). When making manual changes to source files or configurations outside of the standard workflow, BitBake might use cached objects instead of recompiling.
To force a clean rebuild of a specific recipe (e.g., the kernel), the state cache for this specific recipe must be cleared before rebuilding:
bitbake -c cleansstate virtual/kernel bitbake virtual/kernel
cleanall unless strictly necessary, as it will also delete all downloaded source archives for that recipe.