Yocto build of imx-5.10.52-2.1.0 with eIQ support for I.MX8M Plus fails

[mbrundler]

Hi,

I'im trying to build the BSP 5.10.52-2.1.0 release for an I.MX8M Plus EVK board :

repo init -u https://source.codeaurora.org/external/imx/imx-manifest -b imx-linux-hardknott -m imx-5.10.52-2.1.0.xml
repo sync

run OK, then

DISTRO=fsl-imx-wayland MACHINE=imx8mpevk source imx-setup-release.sh -b build

then add :

UBOOT_CONFIG = "sd fspi ecc"
TOOLCHAIN_TARGET_TASK_append += " tensorflow-lite-staticdev tensorflow-lite-dev armnn-dev onnxruntime-dev"
IMAGE_ROOTFS_EXTRA_SPACE = "1048576"

to conf/local.conf then :

bitbake imx-image-full # So as to have machine learning support

It runs for more than a day without problem (executed 70 % of the tasks), then fails on the "imx-boot_1.0.bb:do_compile" task with this message :

cp: target '/home/mb/IMX8/yocto_5.10.52.2.1.0/build/tmp/work/imx8mpevk-poky-linux/imx-boot/1.0-r0/git/iMX8M/u-boot-spl.bin' is not a directory

I attach the logs to this message.

I'm totally new to yocto/bitbake so I would appreciate some help.

Regards,

Marc

[danmartzla]

Hi there!

I also have an error when building this latest Yocto Linux for the i.MX8M Plus. In my case, I'm just building the "imx-image-full" option with all configs by default. The error shows up during one of the last tasks:

ERROR: imx-image-full-1.0-r0 do_rootfs: Error executing a python function in exec_python_func() autogenerated:

The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function: <module>
     0001:
 *** 0002:do_rootfs(d)
     0003:
File: '/home/user/L5.10.52_2.1.0/sources/poky/meta/classes/image.bbclass', lineno: 247, function: do_rootfs
     0243:    progress_reporter.next_stage()
     0244:
     0245:    # generate rootfs
     0246:    d.setVarFlag('REPRODUCIBLE_TIMESTAMP_ROOTFS', 'export', '1')
 *** 0247:    create_rootfs(d, progress_reporter=progress_reporter, logcatcher=logcatcher)
     0248:
     0249:    progress_reporter.finish()
     0250:}
     0251:do_rootfs[dirs] = "${TOPDIR}"
File: '/home/user/L5.10.52_2.1.0/sources/poky/meta/lib/oe/rootfs.py', lineno: 373, function: create_rootfs
     0369:
     0370:    img_type = d.getVar('IMAGE_PKGTYPE')
     0371:
     0372:    cls = get_class_for_type(img_type)
 *** 0373:    cls(d, manifest_dir, progress_reporter, logcatcher).create()
     0374:    os.environ.clear()
     0375:    os.environ.update(env_bkp)
     0376:
     0377:
File: '/home/user/L5.10.52_2.1.0/sources/poky/meta/lib/oe/package_manager/deb/rootfs.py', lineno: 137, function: __init__
     0133:        bb.utils.remove(self.d.getVar('MULTILIB_TEMP_ROOTFS'), True)
     0134:        self.manifest = PkgManifest(d, manifest_dir)
     0135:        self.pm = DpkgPM(d, d.getVar('IMAGE_ROOTFS'),
     0136:                         d.getVar('PACKAGE_ARCHS'),
 *** 0137:                         d.getVar('DPKG_ARCH'))
     0138:
     0139:
     0140:    def _create(self):
     0141:        pkgs_to_install = self.manifest.parse_initial_manifest()
File: '/home/user/L5.10.52_2.1.0/sources/poky/meta/lib/oe/package_manager/deb/__init__.py', lineno: 171, function: __init__
     0167:    def __init__(self, d, target_rootfs, archs, base_archs, apt_conf_dir=None, deb_repo_workdir="oe-rootfs-repo", filterbydependencies=True):
     0168:        super(DpkgPM, self).__init__(d, target_rootfs)
     0169:        self.deploy_dir = oe.path.join(self.d.getVar('WORKDIR'), deb_repo_workdir)
     0170:
 *** 0171:        create_packages_dir(self.d, self.deploy_dir, d.getVar("DEPLOY_DIR_DEB"), "package_write_deb", filterbydependencies)
     0172:
     0173:        if apt_conf_dir is None:
     0174:            self.apt_conf_dir = self.d.expand("${APTCONF_TARGET}/apt")
     0175:        else:
File: '/home/user/L5.10.52_2.1.0/sources/poky/meta/lib/oe/package_manager/__init__.py', lineno: 508, function: create_packages_dir
     0504:            bb.fatal("No manifest generated from: %s in %s" % (c, taskdepdata[dep][2]))
     0505:        if not os.path.exists(manifest):
     0506:            continue
     0507:        with open(manifest, "r") as f:
 *** 0508:            for l in f:
     0509:                l = l.strip()
     0510:                deploydir = os.path.normpath(deploydir)
     0511:                if bb.data.inherits_class('packagefeed-stability', d):
     0512:                    dest = l.replace(deploydir + "-prediff", "")
File: '/usr/lib/python3.6/codecs.py', lineno: 321, function: decode
     0317:
     0318:    def decode(self, input, final=False):
     0319:        # decode input (taking the buffer into account)
     0320:        data = self.buffer + input
 *** 0321:        (result, consumed) = self._buffer_decode(data, self.errors, final)
     0322:        # keep undecoded input until the next call
     0323:        self.buffer = data[consumed:]
     0324:        return result
     0325:
Exception: UnicodeDecodeError: 'utf-8' codec can't decode byte 0x9f in position 35: invalid start byte

ERROR: Logfile of failure stored in: /home/user/L5.10.52_2.1.0/Hardknott_2.1.0/tmp/work/imx8mpevk-poky-linux/imx-image-full/1.0-r0/temp/log.do_rootfs.24544
ERROR: Task (/home/user/L5.10.52_2.1.0/sources/meta-imx/meta-sdk/dynamic-layers/qt5-layer/recipes-fsl/images/imx-image-full.bb:do_rootfs) failed with exit code '1'

I've googled the exception message and it seems it's related to a byte to char decoding problem. It seems a Python script is reading a file as text but throws this exception when it finds a byte it cannot decode as char. As I said, I did not add any custom configuration for building Yocto, it's all by default.

There is an interesting fact. If I simply ran "bitbake imx-image-full" again, the same "UnicodeDecodeError" exception error shows up but referencing a different byte and position.

Thanks.

[bernhardfink]

Hi Dani,

I expect this to be a resource problem on your build machine. Can you give it a try with a reduced number of threads and parallel tasks?

Regards,
Bernhard.

[danmartzla]

Hi Bernhard,

I tried again following your suggestion and it did not work as well. However, a different error showed up. It was very suspicious so I ran "fcsk" for disk scan/repair and it turned out that was the cause. After it fixed some disk errors, Yocto compiled everything with no errors.

Thank you,

Dani.-

[bernhardfink]

Hi Dani,

good to know, the command fsck will be added to my list of "How to fix Yocto build problems"

Yocto generates hundred thousands of files, this is a challenge for a hard disk and the file system.

Regards,
Bernhard.

[bernhardfink]

Hi Marc,

sometimes bitbake runs into resource issues on the build machine and this results in random errors with mostly misleading error messages.

Can you please simply restart the build. If this does not work, please reduce the number of threads and the number of make processes running in parallel, for example to 2 (depends on your build machine).

Add this to local.conf:

BB_NUMBER_THREADS ?= "2"
PARALLEL_MAKE ?= "-j 2"

However, I can't exclude a problem in the build environment, until I tested it by myself.

Regards,
Bernhard.

[mbrundler]

Thank you for your answer Bernhard,

1) I re-executed bitbake without change -> same failure

2) I re-executed bitbake after applying you fix (and source setup-environment build - don't know if useful) -> same failure

However, I tried yur fix on another failed bitbake (imx-5.10.35-2.0.0) and it solved the issue.

Regards

Marc

[bernhardfink]

Hi Marc,

I started a build on my computer using the same configuration and I'll come back to you when it's finished.

Regards,
Bernhard.

[bernhardfink · Accepted solution]

Hi Marc,

my normal imx-image-full build started with 8 threads and 8 parallel tasks and I ran into one of these UTF-8 compilation errors. I restarted with 2 / 2 and ran into a reparsing problem ("The metadata is not deterministic and this needs to be fixed"), but simply with another restart of bitbake the build finished.

I added the 3 lines in local.conf

UBOOT_CONFIG = "sd fspi ecc"
TOOLCHAIN_TARGET_TASK_append += " tensorflow-lite-staticdev tensorflow-lite-dev armnn-dev onnxruntime-dev"
IMAGE_ROOTFS_EXTRA_SPACE = "1048576"

and got the same error as you got.

The root cause is the parameter list "sd fspi ecc". It is documented this way in the Yocto User's Manual, but somehow it doesn't work. If only "sd" xor "spi" xor "ecc" is given, the build finishes (or nothing, then it's "sd"), but not if there are 2 or three together.

Workaround:  just use the one which you need.

I assume something in the machine config files in /sources/meta-freescale/conf/machine is not correct for the 8mp-evk.

I will check this with our BSP team.

Regards,
Bernhard.

[mbrundler]

Thank you Bernhard. You fix solved the uboot issue.

... waiting for the next !

Regards

Marc