iMX95 NPU Yocto walnascar build fails

Harry · June 25, 2026, 6:56am

I’m trying to follow instructions on AI, Computer Vision and Machine Learning on Toradex i.MX 95-based Modules | Toradex Developer Center for deploying a model on the NPU and the yocto build fails with error below. Documentation needs to be updated or otherwise NPU functionality made available on latest OS releases.

WARNING: tzn-mqtt-0.0+git-r0 do_fetch: Failed to fetch URL crate://crates.io/addr2line/0.21.0, attempting MIRRORS if available
ERROR: tzn-mqtt-0.0+git-r0 do_fetch: Fetcher failure: Fetch command export PSEUDO_DISABLED=1; export PATH=“/workspace/imx95-build/tmp/sysroots-uninative/x86_64-linux/usr/bin:/workspace/imx95-build/tmp/work/cortexa55-tdx-linux/tzn-mqtt/0.0+git/recipe-sysroot-native/usr/bin/python3-native:/workspace/layers/openembedded-core/scripts:/workspace/imx95-build/tmp/work/cortexa55-tdx-linux/tzn-mqtt/0.0+git/recipe-sysroot-native/usr/bin/aarch64-tdx-linux:/workspace/imx95-build/tmp/work/cortexa55-tdx-linux/tzn-mqtt/0.0+git/recipe-sysroot/usr/bin/crossscripts:/workspace/imx95-build/tmp/work/cortexa55-tdx-linux/tzn-mqtt/0.0+git/recipe-sysroot-native/usr/sbin:/workspace/imx95-build/tmp/work/cortexa55-tdx-linux/tzn-mqtt/0.0+git/recipe-sysroot-native/usr/bin:/workspace/imx95-build/tmp/work/cortexa55-tdx-linux/tzn-mqtt/0.0+git/recipe-sysroot-native/sbin:/workspace/imx95-build/tmp/work/cortexa55-tdx-linux/tzn-mqtt/0.0+git/recipe-sysroot-native/bin:/workspace/layers/openembedded-core/bitbake/bin:/workspace/imx95-build/tmp/hosttools”; export HOME=“/home/builder”; /usr/bin/env wget --tries=2 --timeout=100 --output-document=/workspace/downloads/addr2line-0.21.0.crate.tmp --continue --directory-prefix=/workspace/downloads ‘https://crates.io/api/v1/crates/addr2line/0.21.0/download’ --progress=dot --verbose failed with exit code 8, see logfile for output
ERROR: tzn-mqtt-0.0+git-r0 do_fetch: Bitbake Fetcher Error: FetchError(‘Unable to fetch URL from any source.’, ‘crate://crates.io/addr2line/0.21.0’)
ERROR: Logfile of failure stored in: /workspace/imx95-build/tmp/work/cortexa55-tdx-linux/tzn-mqtt/0.0+git/temp/log.do_fetch.5919
ERROR: Task (/workspace/layers/meta-toradex-torizon/recipes-sota/tzn-mqtt/tzn-mqtt_git.bb:do_fetch) failed with exit code ‘1’
WARNING: rac-0.0+git-r0 do_fetch: Failed to fetch URL crate://crates.io/addr2line/0.21.0, attempting MIRRORS if available
ERROR: rac-0.0+git-r0 do_fetch: Fetcher failure: Fetch command export PSEUDO_DISABLED=1; export PATH=“/workspace/imx95-build/tmp/sysroots-uninative/x86_64-linux/usr/bin:/workspace/imx95-build/tmp/work/cortexa55-tdx-linux/rac/0.0+git/recipe-sysroot-native/usr/bin/python3-native:/workspace/layers/openembedded-core/scripts:/workspace/imx95-build/tmp/work/cortexa55-tdx-linux/rac/0.0+git/recipe-sysroot-native/usr/bin/aarch64-tdx-linux:/workspace/imx95-build/tmp/work/cortexa55-tdx-linux/rac/0.0+git/recipe-sysroot/usr/bin/crossscripts:/workspace/imx95-build/tmp/work/cortexa55-tdx-linux/rac/0.0+git/recipe-sysroot-native/usr/sbin:/workspace/imx95-build/tmp/work/cortexa55-tdx-linux/rac/0.0+git/recipe-sysroot-native/usr/bin:/workspace/imx95-build/tmp/work/cortexa55-tdx-linux/rac/0.0+git/recipe-sysroot-native/sbin:/workspace/imx95-build/tmp/work/cortexa55-tdx-linux/rac/0.0+git/recipe-sysroot-native/bin:/workspace/layers/openembedded-core/bitbake/bin:/workspace/imx95-build/tmp/hosttools”; export HOME=“/home/builder”; /usr/bin/env wget --tries=2 --timeout=100 --output-document=/workspace/downloads/addr2line-0.21.0.crate.tmp --continue --directory-prefix=/workspace/downloads ‘https://crates.io/api/v1/crates/addr2line/0.21.0/download’ --progress=dot --verbose failed with exit code 8, see logfile for output
ERROR: rac-0.0+git-r0 do_fetch: Bitbake Fetcher Error: FetchError(‘Unable to fetch URL from any source.’, ‘crate://crates.io/addr2line/0.21.0’)
ERROR: Logfile of failure stored in: /workspace/imx95-build/tmp/work/cortexa55-tdx-linux/rac/0.0+git/temp/log.do_fetch.6100
ERROR: Task (/workspace/layers/meta-toradex-torizon/recipes-sota/rac/rac_git.bb:do_fetch) failed with exit code ‘1’

I follow the blog instructions carefully but it looks like some dependencies aren’t available. How to proceed? Some additional info is below:

For reproducible result I’m using docker and docker compose. Files and instructions to reproduce are below:

Step 1 Init

docker compose build && docker compose run --rm init-yocto

Step 2 Build

docker compose run --rm build-yocto

Files

docker/yocto-build.Dockerfile:

# syntax=docker/dockerfile:1
# Torizon OS / Yocto build environment (Ubuntu 22.04 = a Yocto-validated host).
# No UID/GID build args and no .env: the entrypoint reads the owner of the mounted
# /workspace at runtime and runs the build as that UID/GID (bitbake refuses root),
# so files it creates are owned by you on the host.
FROM ubuntu:22.04

ARG DEBIAN_FRONTEND=noninteractive

RUN apt-get update && apt-get install -y --no-install-recommends \
      gawk wget git diffstat unzip texinfo gcc build-essential chrpath \
      socat cpio python3 python3-pip python3-pexpect xz-utils debianutils \
      iputils-ping python3-git python3-jinja2 python3-subunit zstd liblz4-tool \
      file locales libacl1 sudo curl ca-certificates bzip2 lz4 \
      python-is-python3 git-lfs gosu \
 && rm -rf /var/lib/apt/lists/*

RUN locale-gen en_US.UTF-8 && update-locale LANG=en_US.UTF-8
ENV LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8

# Auto-accept the NXP/Freescale EULA so 'setup-environment' doesn't block on a prompt
# (this is an ENV var; local.conf's ACCEPT_FSL_EULA only covers bitbake parse time).
ENV ACCEPT_FSL_EULA=1

# Google 'repo' launcher
RUN curl -fsSL https://storage.googleapis.com/git-repo-downloads/repo -o /usr/local/bin/repo \
 && chmod a+x /usr/local/bin/repo

# Allow git in the bind-mounted tree, and pre-seed repo's identity + color into the
# GLOBAL gitconfig (repo reads ~/.gitconfig, NOT /etc/gitconfig) via /etc/skel so that
# useradd -m drops it into builder's home and 'repo init' never prompts.
RUN git config --system --add safe.directory '*' \
 && printf '[user]\n\tname = Torizon Builder\n\temail = builder@example.com\n[color]\n\tui = false\n' > /etc/skel/.gitconfig

# Entrypoint: bitbake refuses root, so run as a fixed non-root 'builder' (uid 1000)
# and make the workspace writable by it. Works under rootful AND rootless Docker
# (where the host user maps to container root, so reading the mount owner is useless).
RUN cat > /usr/local/bin/entrypoint <<'EOF'
#!/bin/bash
set -e
getent passwd 1000 >/dev/null || useradd -m -u 1000 -s /bin/bash builder
export HOME=$(getent passwd 1000 | cut -d: -f6)
chown 1000:1000 /workspace 2>/dev/null || true
exec gosu 1000:1000 "$@"
EOF
RUN chmod +x /usr/local/bin/entrypoint

WORKDIR /workspace
ENTRYPOINT ["/usr/local/bin/entrypoint"]
CMD ["bash"]

docker-compose.yml

services:
  init-yocto:
    image: torizon-builder
    network_mode: host
    build:
      context: docker
      dockerfile: yocto-build.Dockerfile
    security_opt:
      - apparmor=unconfined
      - seccomp=unconfined
    tty: true
    stdin_open: true
    working_dir: /workspace
    volumes:
      - ./build:/workspace:rw
    environment:
      - MACHINE=verdin-imx95
      - EULA=1
    command:
      - bash
      - -c
      - |
        repo init -u git://git.toradex.com/toradex-manifest.git -b walnascar -m torizon/default.xml
        repo sync -j 10
        . setup-environment imx95-build

  build-yocto:
    image: torizon-builder
    network_mode: host
    build:
      context: docker
      dockerfile: yocto-build.Dockerfile
    security_opt:
      - apparmor=unconfined
      - seccomp=unconfined
    tty: true
    stdin_open: true
    working_dir: /workspace
    volumes:
      - ./build:/workspace:rw
      - ./conf:/tmp/conf:ro
    environment:
      - MACHINE=verdin-imx95
    command:
      - bash
      - -c
      - |
        . setup-environment imx95-build
        cp /tmp/conf/local.conf /tmp/conf/bblayers.conf /workspace/imx95-build/conf/
        bitbake torizon-minimal

conf/local.conf

# CONF_VERSION is increased each time build/conf/ changes incompatibly
CONF_VERSION = "2"

# Which files do we want to parse:
BBMASK = ""

# Disable build time patch resolution. This would lauch a devshell
# and wait for manual intervention. We disable it.
PATCHRESOLVE = "noop"

# Customisations
ACCEPT_FSL_EULA = "1"
IMAGE_INSTALL:append = " packagegroup-fsl-ml"
RDEPENDS:torizon-minimal:remove = "tzn-mqtt rac"
#
# Parallelism Options
#
# These two options control how much parallelism BitBake should use. The first
# option determines how many tasks bitbake should run in parallel:
# Default to setting automatically based on cpu count
BB_NUMBER_THREADS ?= "${@oe.utils.cpu_count()}"
#
# The second option controls how many processes make should run in parallel when
# running compile tasks:
# Default to setting automatically based on cpu count
PARALLEL_MAKE ?= "-j ${@oe.utils.cpu_count()}"

# Uncomment the lines below for graphics to work on QEMU builds
# Obs.: make sure you have libsdl2 installed in your host machine
#PACKAGECONFIG:append:pn-qemu-system-native = " sdl"
#PACKAGECONFIG:append:pn-nativesdk-qemu = " sdl"
#ASSUME_PROVIDED += "libsdl2-native"

# The following variables are required to build a software that can
# be debugged with GDB. Just substitute <PKG> with the package name
# that is producing the software you want to debug.
#SECURITY_CFLAGS_pn-<PKG> = "-no-pie -fno-PIE"
#DEBUG_BUILD_pn-<PKG> = "1"

#
# Shared-state files from other locations
#
# Shared state files are prebuilt cache data objects which can
# used to accelerate build time. This variable can be used to configure the system
# to search other mirror locations for these objects before it builds the data itself.
#
# This can be a filesystem directory, or a remote url such as http or ftp. These
# would contain the sstate-cache results from previous builds (possibly from other
# machines). This variable works like fetcher MIRRORS/PREMIRRORS and points to the
# cache locations to check for the shared objects.
#SSTATE_MIRRORS ?= "\
#file://.* http://someserver.tld/share/sstate/PATH;downloadfilename=PATH \n \
#file://.* file:///some/local/dir/sstate/PATH"

# enable PR service on build machine itself
# its good for a case when this is the only builder
# generating the feeds
#PRSERV_HOST = "localhost:0"

#
# Scale Provisioning
#
# The goal of this feature is to add provisioning data to the generated Toradex
# Easy Installer image allowing a device to provision itself to the OTA platform
# (Torizon Cloud) and/or accept offline updates at runtime.
#
# For the regular usage, one would simply set variables:
#
# - TORIZON_SOTA_PROV_MODE: allowed values are:
#   a) "": for no provisioning (default);
#   b) "offline": for offline provisioning in which case the device would be able
#      to accept offline updates (load updates from Lockboxes);
#   c) "online": for online provisioning where the device would provision itself
#      to the OTA platform (Torizon Cloud).
# - TORIZON_SOTA_PROV_CREDENTIALS: this should point to the location of the
#   credentials file (normally obtained from the platform); if this variable is
#   not set, it will take the value of SOTA_PACKED_CREDENTIALS (when set).
#
# As an alternative to setting TORIZON_SOTA_PROV_CREDENTIALS, one could instead
# set the following two variables:
#
# - TORIZON_SOTA_PROV_SHARED_DATA: path to shared data tarball.
# - TORIZON_SOTA_PROV_ONLINE_DATA: string containing the online provisioning data
#   which is generally deemed sensitive information; this is only needed in the
#   "online" provisioning case.
#
# Both pieces of information can be obtained with TorizonCore Builder; see:
# https://developer.toradex.com/torizon/torizoncore/production-programming-in-torizon/#getting-provisioning-data
#
# The advantage of this alternative method is that it does not require a
# credentials file during the build process which can be considered more
# secure. This could be particularly useful in CI. The recommended approach for
# setting TORIZON_SOTA_PROV_ONLINE_DATA is taking its value from the OS environment
# as done in the second example below with variable ONLINE_PROV_DATA which is
# assumed to be set; for this to work bitbake must be set up appropriately by
# adding the name of that variable to BB_ENV_PASSTHROUGH_ADDITIONS like so:
#
# $ export BB_ENV_PASSTHROUGH_ADDITIONS="ONLINE_PROV_DATA"
# $ bitbake torizon-docker
#
# Example (regular usage):
#TORIZON_SOTA_PROV_MODE = "online"
#TORIZON_SOTA_PROV_CREDENTIALS = "/home/someuser/credentials.zip"
#
# Example (without a credentials file); ONLINE_PROV_DATA is supposed to contain
# the online provisioning data (sensitive information):
#TORIZON_SOTA_PROV_MODE = "online"
#TORIZON_SOTA_PROV_SHARED_DATA ?= "${WORKDIR}/prov/shared-data.tar.gz"
#TORIZON_SOTA_PROV_ONLINE_DATA ?= "${ONLINE_PROV_DATA}"

include conf/machine/include/${MACHINE}.inc

conf/bblayers.conf

# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "7"
OEROOT := "/workspace"

BBPATH = "${TOPDIR}"

BBFILES = ""

# These layers hold recipe metadata not found in OE-core, but lack any machine or distro content
BASELAYERS ?= " \
  ${OEROOT}/layers/meta-openembedded/meta-oe \
  ${OEROOT}/layers/meta-openembedded/meta-networking \
  ${OEROOT}/layers/meta-openembedded/meta-filesystems \
  ${OEROOT}/layers/meta-openembedded/meta-python \
  ${OEROOT}/layers/meta-openembedded/meta-perl \
  ${OEROOT}/layers/meta-openembedded/meta-multimedia \
  ${OEROOT}/layers/meta-virtualization \
  ${OEROOT}/layers/meta-updater \
  ${OEROOT}/layers/meta-cyclonedx \
"

# These layers hold machine specific content, aka Board Support Packages
BSPLAYERS ?= " \
  ${OEROOT}/layers/meta-toradex-nxp \
  ${OEROOT}/layers/meta-freescale \
  ${OEROOT}/layers/meta-freescale-3rdparty \
  ${OEROOT}/layers/meta-freescale-ml \
  ${OEROOT}/layers/meta-yocto/meta-yocto-bsp \
  ${OEROOT}/layers/meta-yocto/meta-poky \
  ${OEROOT}/layers/meta-security \
  ${OEROOT}/layers/meta-arm/meta-arm-toolchain \
  ${OEROOT}/layers/meta-arm/meta-arm \
  ${OEROOT}/layers/meta-imx/meta-imx-ml \
"

# Add your overlay location to EXTRALAYERS
# Make sure to have a conf/layers.conf in there
EXTRALAYERS ?= ""

BBLAYERS = " \
  ${OEROOT}/layers/meta-toradex-torizon \
  ${OEROOT}/layers/meta-toradex-distro \
  ${OEROOT}/layers/meta-toradex-bsp-common \
  ${OEROOT}/layers/meta-security/meta-tpm \
  ${BASELAYERS} \
  ${BSPLAYERS} \
  ${EXTRALAYERS} \
  ${OEROOT}/layers/openembedded-core/meta \
"

ToradexAI · June 25, 2026, 6:57am

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.

The error you’re encountering is a network fetch failure when BitBake tries to download Rust crate dependencies from crates.io. The specific error shows:

ERROR: tzn-mqtt-0.0+git-r0 do_fetch: Fetcher failure: Fetch command ... failed with exit code 8
ERROR: Bitbake Fetcher Error: FetchError('Unable to fetch URL from any source.', 'crate://crates.io/addr2line/0.21.0')

This indicates that the build system cannot reach https://crates.io/api/v1/crates/addr2line/0.21.0/download.

Workaround

Based on your configuration, you’ve already taken a good step by removing the problematic packages from the build:

RDEPENDS:torizon-minimal:remove = "tzn-mqtt rac"

However, the fetch is still being attempted. To fully resolve this, you need to ensure these recipes are not being built at all.

Solution Steps:

Verify Network Connectivity: Ensure your Docker container has proper network access to external resources. Since you’re using network_mode: host, this should work, but verify:
- Can the container reach crates.io?
- Are there any firewall or proxy restrictions?
Use BBMASK to Skip Problematic Recipes: Add to your conf/local.conf:

BBMASK += "meta-toradex-torizon/recipes-sota/tzn-mqtt/tzn-mqtt_git.bb"
BBMASK += "meta-toradex-torizon/recipes-sota/rac/rac_git.bb"

This will prevent BitBake from parsing these recipes entirely(1).

Alternative: Use Pre-built Torizon OS Images: For NPU functionality, you may want to consider using the pre-built Torizon OS images and deploying your TensorFlow Lite application as a container, as described in the NPU documentation(2).

Additional Considerations

The walnascar branch represents development work for iMX95 support. If you continue to experience build issues, you may want to:

Check if there are newer commits in the walnascar branch
Verify all prerequisites are installed in your build environment(3)
Consider using the Toradex-provided build infrastructure or CROPS containers for a validated build environment(3)

If the network fetch continues to fail and you need NPU support, I recommend reaching out on the Toradex Community with your specific build logs, or consider using pre-built Torizon OS images with containerized applications for NPU workloads.

Best regards,
Toradex AI Assistant.

Did you like my answer?

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

hai.tx · June 25, 2026, 9:22am

Hi Harry，

We have already found some know issues on the article you mentioned, and here in the attachment is a documentation with fix solution, please check if this works.

Hai Qin
Toradex

Hi Harry，

We have already found some know issues on the article you mentioned, and here in the attachment is a doc\numentation with fix solution, please check if this works.

Hai Qin
Toradex

Attachment(s):
AI