Before I build the yocto os project fully without an error but now Im cleaned thebuild and again rebuild the OS it were causing the error in meta-qt5 layer, why?
Have any suggestions to clear this error as new build, but this was works fine at the early build, How?
bitbake -k tdx-reference-multimedia-image Error Build.txt (45.9 KB)
Hi, I’m the Toradex AI Assistant.
I might make mistakes or occasionally get you wrong. Our support team will step in if needed.
Based on the information provided, I’d like to help you troubleshoot this meta-qt5 layer error. To provide the most accurate guidance, I need to understand your specific setup better.
Could you please provide the following details:
Hardware platform: Which SoM and carrier board are you using? You can run tdx-info on your device to get this information. For more details, see: tdx-info documentation
OS version: Which BSP version are you building?
Build configuration: What’s your current MACHINE and DISTRO settings in your conf/local.conf?
While I await your platform details, here are some common approaches for meta-qt5 build issues after cleaning:
Ensure your repositories are properly synchronized (1):
$ repo sync
If you encounter persistent errors after cleaning, try these steps (2):
$ bitbake -c clean <failing-recipe>
$ bitbake tdx-reference-multimedia-image
Verify your build configuration matches the supported combinations. The tdx-reference-multimedia-image includes Qt5 packages through the packagegroup-tdx-qt5 (3).
If you’re experiencing persistent Qt5 issues, you might consider transitioning to Qt6. The community has reported success with meta-qt6 layer integration (4), though this requires removing all Qt5 modules and building from scratch.
Once you provide your platform details, I can give you more specific guidance for your particular setup.
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.
Hi @ToradexAI,
here the device info, build info and local conf details are available,
Software summary
------------------------------------------------------------
Bootloader: U-Boot
Kernel version: 6.6.101-7.5.0-devel #1 SMP PREEMPT Mon Oct 27 12:24:20 UTC 2025
Kernel command line: root=PARTUUID=aa4ec312-3310-48d6-8cf7-a5851f2ec790 ro rootwait console=tty1 console=ttymxc2,115200 quiet loglevel=0 vt.global_cursor_default=0 vt.default_redraw=0
Distro name: NAME="TDX Wayland with XWayland"
Distro version: VERSION_ID=7.5.0-devel-20251114145026-build.0
Distro variant: -
Hostname: verdin-imx8mp-15722251
------------------------------------------------------------
Hardware info
------------------------------------------------------------
HW model: Toradex Verdin iMX8M Plus WB on Ivy
Toradex version: 0070 V1.1A
Serial number: 15722251
Processor arch: aarch64
------------------------------------------------------------
root@verdin-imx8mp-15722251:~# cat /etc/os-release
ID=tdx-xwayland
NAME="TDX Wayland with XWayland"
VERSION="7.5.0-devel-20251114145026+build.0 (scarthgap)"
VERSION_ID=7.5.0-devel-20251114145026-build.0
VERSION_CODENAME="scarthgap"
PRETTY_NAME="TDX Wayland with XWayland 7.5.0-devel-20251114145026+build.0 (scarthgap)"
CPE_NAME="cpe:/o:openembedded:tdx-xwayland:7.5.0-devel-20251114145026+build.0"
BSP version : Scarthgap 7.5.0
MACHINE ?= "verdin-imx8mp"
# MACHINE SELECTION FOR DISTRO
MACHINES_DOWNSTREAM_DISTRO_DEFAULT = "\
apalis-imx8 \
aquila-am69 \
aquila-am69-k3r5 \
colibri-imx8x \
toradex-smarc-imx8mp \
toradex-smarc-imx95 \
verdin-am62 \
verdin-am62-k3r5 \
verdin-am62p \
verdin-am62p-k3r5 \
verdin-imx8mm \
verdin-imx8mp \
verdin-imx95 \
"
DISTRO ?= "${@bb.utils.contains('MACHINES_DOWNSTREAM_DISTRO_DEFAULT', d.getVar('MACHINE') or '', 'tdx-xwayland', 'tdx-xwayland-upstream', d)}"
\
Thank you for providing the detailed platform information! Based on your setup (Verdin iMX8MP with BSP 7.5.0 Scarthgap), I can help you resolve this Qt5 build issue.
Your configuration looks correct for the Verdin iMX8MP with the tdx-xwayland distro(1). The Qt5 build failures after cleaning are often related to dependency resolution or temporary build state issues.
Since you’re building tdx-reference-multimedia-image which includes Qt5 packages, clean all Qt5-related recipes first(1):
$ bitbake -c cleansstate qtbase
$ bitbake -c cleansstate qtdeclarative
$ bitbake -c cleansstate qtmultimedia
$ bitbake -c cleansstate meta-toolchain-qt5
If you plan to develop Qt applications, ensure you have the proper SDK setup. The Qt5 SDK can be generated using(2):
$ bitbake meta-toolchain-qt5
For Qt5 development, you may need to add Qt5 tools to your SDK. Add this to your image recipe if developing Qt applications(2):
inherit populate_sdk populate_sdk_qt5
Try building with reduced parallelism to avoid resource conflicts(1):
$ PARALLEL_MAKE="-j 4" BB_NUMBER_THREADS="6" bitbake tdx-reference-multimedia-image
Based on community feedback, Qt package warnings are common but often don’t prevent successful builds(3). If you encounter buildpaths warnings, these are typically non-critical and the build should complete successfully.
After applying the fixes:
If the issue persists, you may want to start with a completely fresh build environment, as Qt5 builds can be sensitive to cached state after major cleanups.
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.
Hi @ToradexAI,
These are my bblayer and meta layer availabel in the yocto build OS,
hari@Administrator:~/oe-core/layers$ ls
meta-arm meta-freescale-3rdparty meta-openembedded meta-toradex-bsp-common meta-toradex-nxp
meta-browser meta-freescale-distro meta-qt5 meta-toradex-chromium meta-toradex-ti
meta-custom meta-imx meta-security meta-toradex-demos meta-yocto
meta-freescale meta-lokbest meta-ti meta-toradex-distro openembedded-core
hari@Administrator:~/oe-core/layers$ cat ../build/conf/bblayers.conf
# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
LCONF_VERSION = "7"
BBPATH = "${TOPDIR}"
BBFILES ?= ""
BBLAYERS_NXP ?= " \
${TOPDIR}/../layers/meta-toradex-nxp \
${TOPDIR}/../layers/meta-freescale \
${TOPDIR}/../layers/meta-freescale-3rdparty \
"
BBLAYERS_TI ?= " \
${TOPDIR}/../layers/meta-toradex-ti \
${TOPDIR}/../layers/meta-arm/meta-arm-toolchain \
${TOPDIR}/../layers/meta-arm/meta-arm \
${TOPDIR}/../layers/meta-ti/meta-ti-bsp \
${TOPDIR}/../layers/meta-ti/meta-ti-extras \
"
BBLAYERS ?= " \
${BBLAYERS_NXP} \
${BBLAYERS_TI} \
${TOPDIR}/../layers/meta-toradex-bsp-common \
${TOPDIR}/../layers/meta-openembedded/meta-oe \
${TOPDIR}/../layers/meta-openembedded/meta-filesystems \
${TOPDIR}/../layers/meta-openembedded/meta-networking \
${TOPDIR}/../layers/meta-openembedded/meta-multimedia \
${TOPDIR}/../layers/meta-openembedded/meta-python \
${TOPDIR}/../layers/meta-freescale-distro \
${TOPDIR}/../layers/meta-toradex-demos \
${TOPDIR}/../layers/meta-qt5 \
${TOPDIR}/../layers/meta-security/meta-tpm \
${TOPDIR}/../layers/meta-toradex-distro \
${TOPDIR}/../layers/meta-yocto/meta-poky \
${TOPDIR}/../layers/openembedded-core/meta \
/home/hari/oe-core/layers/meta-toradex-chromium \
${TOPDIR}/../layers/meta-custom \
"
BBLAYERS += " ${TOPDIR}/../layers/meta-browser/meta-chromium"
BBLAYERS += " ${TOPDIR}/../layers/meta-openembedded/meta-clang"
BBLAYERS += "/home/hari/oe-core/layers/meta-lokbest"
hari@Administrator:~/oe-core/layers$
Thank you for providing your layer configuration! I can see your setup includes the necessary Qt5 layers and some custom additions. Let me analyze potential issues with your configuration.
Your bblayers.conf shows you have the essential layers for Qt5 development(1):
meta-qt5 layer is properly includedmeta-toradex-demos contains the Qt5 packagesmeta-openembedded/meta-multimedia provides multimedia supportYour configuration includes several custom layers that might conflict:
meta-custommeta-lokbestmeta-toradex-chromiummeta-browser/meta-chromiumThese custom layers could override Qt5 recipes or introduce dependency conflicts.
For BSP 7 with the Multimedia Reference Image, ensure your Qt5 packages are properly configured(1). The tdx-reference-multimedia-image comes with Qt5 packages included in packagegroup-tdx-qt5.bb.
Temporarily remove custom layers to isolate the issue:
# Comment out these lines in bblayers.conf:
# ${TOPDIR}/../layers/meta-custom \
# /home/hari/oe-core/layers/meta-toradex-chromium \
# /home/hari/oe-core/layers/meta-lokbest
# BBLAYERS += " ${TOPDIR}/../layers/meta-browser/meta-chromium"
$ bitbake -c cleansstate tdx-reference-multimedia-image
$ bitbake tdx-reference-multimedia-image
Verify that your custom layers don’t have conflicting Qt5 recipes:
$ bitbake-layers show-overlayed
If Qt5 continues to cause issues, the community has successfully integrated Qt6(2). This requires:
meta-qt5 from bblayers.confmeta-qt6 layerWhen using custom layers with Toradex BSP(1):
Try the minimal configuration approach first, as this will help determine if the issue is related to your custom layers or the core Qt5 build system.
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.
Hi @ToradexAI,
I have followed that custom layer are noww commented and run the basic layer but now I got an new erro accquired in the build!
| /home/hari/oe-core/build/tmp/work/armv8a-tdx-linux/mozjs-115/115.8.0/firefox-115.8.0/js/src/jsapi.cpp:2683:29: note: 'ar.mozilla::Maybe<js::AutoRealm>::<unnamed>.mozilla::detail::MaybeStorage<js::AutoRealm, false>::<unnamed>.mozilla::detail::MaybeStorageBase<js::AutoRealm, false>::mStorage.mozilla::detail::MaybeStorageBase<js::AutoRealm, false>::Union::val.js::AutoRealm::origin_' was declared here
| 2683 | mozilla::Maybe<AutoRealm> ar;
| | ^~
| In file included from /home/hari/oe-core/build/tmp/work/armv8a-tdx-linux/mozjs-115/115.8.0/build/dist/include/js/CallArgs.h:73,
| from /home/hari/oe-core/build/tmp/work/armv8a-tdx-linux/mozjs-115/115.8.0/firefox-115.8.0/js/src/jsfriendapi.h:12,
| from /home/hari/oe-core/build/tmp/work/armv8a-tdx-linux/mozjs-115/115.8.0/firefox-115.8.0/js/src/vm/ErrorReporting.h:12,
| from /home/hari/oe-core/build/tmp/work/armv8a-tdx-linux/mozjs-115/115.8.0/firefox-115.8.0/js/src/vm/Warnings.cpp:16,
| from Unified_cpp_js_src25.cpp:2:
| In member function 'void JS::Rooted<T>::registerWithRootLists(JS::RootedListHeads&) [with T = JSObject*]',
| inlined from 'JS::Rooted<T>::Rooted(const RootingContext&, S&&) [with RootingContext = JSContext*; S = JS::Handle<JSObject*>&; T = JSObject*]' at /home/hari/oe-core/build/tmp/work/armv8a-tdx-linux/mozjs-115/115.8.0/build/dist/include/js/RootingAPI.h:1174:26,
| inlined from 'bool ReshapeForProtoMutation(JSContext*, JS::HandleObject)' at /home/hari/oe-core/build/tmp/work/armv8a-tdx-linux/mozjs-115/115.8.0/firefox-115.8.0/js/src/vm/Watchtower.cpp:158:28,
| inlined from 'bool WatchProtoChangeImpl(JSContext*, JS::HandleObject)' at /home/hari/oe-core/build/tmp/work/armv8a-tdx-linux/mozjs-115/115.8.0/firefox-115.8.0/js/src/vm/Watchtower.cpp:176:31:
| /home/hari/oe-core/build/tmp/work/armv8a-tdx-linux/mozjs-115/115.8.0/build/dist/include/js/RootingAPI.h:1141:18: warning: storing the address of local variable 'pobj' in '((js::StackRootedBase**)cx)[3]' [-Wdangling-pointer=]
| 1141 | *this->stack = this;
| | ~~~~~~~~~~~~~^~~~~~
| In file included from Unified_cpp_js_src25.cpp:11:
| /home/hari/oe-core/build/tmp/work/armv8a-tdx-linux/mozjs-115/115.8.0/firefox-115.8.0/js/src/vm/Watchtower.cpp: In function 'bool WatchProtoChangeImpl(JSContext*, JS::HandleObject)':
| /home/hari/oe-core/build/tmp/work/armv8a-tdx-linux/mozjs-115/115.8.0/firefox-115.8.0/js/src/vm/Watchtower.cpp:158:16: note: 'pobj' declared here
| 158 | RootedObject pobj(cx, obj);
| | ^~~~
| /home/hari/oe-core/build/tmp/work/armv8a-tdx-linux/mozjs-115/115.8.0/firefox-115.8.0/js/src/vm/Watchtower.cpp:172:45: note: 'cx' declared here
| 172 | static bool WatchProtoChangeImpl(JSContext* cx, HandleObject obj) {
| | ~~~~~~~~~~~^~
| In member function 'void JS::Rooted<T>::registerWithRootLists(JS::RootedListHeads&) [with T = JSString*]',
| inlined from 'JS::Rooted<T>::Rooted(const RootingContext&, S&&) [with RootingContext = JSContext*; S = JSLinearString*; T = JSString*]' at /home/hari/oe-core/build/tmp/work/armv8a-tdx-linux/mozjs-115/115.8.0/build/dist/include/js/RootingAPI.h:1174:26,
| inlined from 'bool AddToWatchtowerLog(JSContext*, const char*, JS::HandleObject, JS::HandleValue)' at /home/hari/oe-core/build/tmp/work/armv8a-tdx-linux/mozjs-115/115.8.0/firefox-115.8.0/js/src/vm/Watchtower.cpp:31:62:
| /home/hari/oe-core/build/tmp/work/armv8a-tdx-linux/mozjs-115/115.8.0/build/dist/include/js/RootingAPI.h:1141:18: warning: storing the address of local variable 'kindString' in '((js::StackRootedBase**)cx)[6]' [-Wdangling-pointer=]
| 1141 | *this->stack = this;
| | ~~~~~~~~~~~~~^~~~~~
| /home/hari/oe-core/build/tmp/work/armv8a-tdx-linux/mozjs-115/115.8.0/firefox-115.8.0/js/src/vm/Watchtower.cpp: In function 'bool AddToWatchtowerLog(JSContext*, const char*, JS::HandleObject, JS::HandleValue)':
| /home/hari/oe-core/build/tmp/work/armv8a-tdx-linux/mozjs-115/115.8.0/firefox-115.8.0/js/src/vm/Watchtower.cpp:31:16: note: 'kindString' declared here
| 31 | RootedString kindString(cx, NewStringCopyZ<CanGC>(cx, kind));
| | ^~~~~~~~~~
| /home/hari/oe-core/build/tmp/work/armv8a-tdx-linux/mozjs-115/115.8.0/firefox-115.8.0/js/src/vm/Watchtower.cpp:24:43: note: 'cx' declared here
| 24 | static bool AddToWatchtowerLog(JSContext* cx, const char* kind,
| | ~~~~~~~~~~~^~
| In member function 'void JS::Rooted<T>::registerWithRootLists(JS::RootedListHeads&) [with T = JSObject*]',
| inlined from 'JS::Rooted<T>::Rooted(const RootingContext&, S&&) [with RootingContext = JSContext*; S = JSObject*; T = JSObject*]' at /home/hari/oe-core/build/tmp/work/armv8a-tdx-linux/mozjs-115/115.8.0/build/dist/include/js/RootingAPI.h:1174:26,
| inlined from 'bool ReshapeForShadowedProp(JSContext*, JS::Handle<js::NativeObject*>, JS::HandleId)' at /home/hari/oe-core/build/tmp/work/armv8a-tdx-linux/mozjs-115/115.8.0/firefox-115.8.0/js/src/vm/Watchtower.cpp:73:48,
| inlined from 'static bool js::Watchtower::watchPropertyAddSlow(JSContext*, JS::Handle<js::NativeObject*>, JS::HandleId)' at /home/hari/oe-core/build/tmp/work/armv8a-tdx-linux/mozjs-115/115.8.0/firefox-115.8.0/js/src/vm/Watchtower.cpp:109:32:
| /home/hari/oe-core/build/tmp/work/armv8a-tdx-linux/mozjs-115/115.8.0/build/dist/include/js/RootingAPI.h:1141:18: warning: storing the address of local variable 'proto' in '((js::StackRootedBase**)cx)[3]' [-Wdangling-pointer=]
| 1141 | *this->stack = this;
| | ~~~~~~~~~~~~~^~~~~~
| /home/hari/oe-core/build/tmp/work/armv8a-tdx-linux/mozjs-115/115.8.0/firefox-115.8.0/js/src/vm/Watchtower.cpp: In static member function 'static bool js::Watchtower::watchPropertyAddSlow(JSContext*, JS::Handle<js::NativeObject*>, JS::HandleId)':
| /home/hari/oe-core/build/tmp/work/armv8a-tdx-linux/mozjs-115/115.8.0/firefox-115.8.0/js/src/vm/Watchtower.cpp:73:16: note: 'proto' declared here
| 73 | RootedObject proto(cx, obj->staticPrototype());
| | ^~~~~
| /home/hari/oe-core/build/tmp/work/armv8a-tdx-linux/mozjs-115/115.8.0/firefox-115.8.0/js/src/vm/Watchtower.cpp:104:50: note: 'cx' declared here
| 104 | bool Watchtower::watchPropertyAddSlow(JSContext* cx, Handle<NativeObject*> obj,
| | ~~~~~~~~~~~^~
| In member function 'void JS::Rooted<T>::registerWithRootLists(JS::RootedListHeads&) [with T = js::PropMap*]',
| inlined from 'JS::Rooted<T>::Rooted(const RootingContext&, S&&) [with RootingContext = JSContext*; S = js::PropMap*; T = js::PropMap*]' at /home/hari/oe-core/build/tmp/work/armv8a-tdx-linux/mozjs-115/115.8.0/build/dist/include/js/RootingAPI.h:1174:26,
| inlined from 'static bool js::Watchtower::watchPropertyChangeSlow(JSContext*, JS::Handle<js::NativeObject*>, JS::HandleId, js::PropertyFlags)' at /home/hari/oe-core/build/tmp/work/armv8a-tdx-linux/mozjs-115/115.8.0/firefox-115.8.0/js/src/vm/Watchtower.cpp:242:70:
| /home/hari/oe-core/build/tmp/work/armv8a-tdx-linux/mozjs-115/115.8.0/build/dist/include/js/RootingAPI.h:1141:18: warning: storing the address of local variable 'map' in '((js::StackRootedBase**)cx)[11]' [-Wdangling-pointer=]
| 1141 | *this->stack = this;
| | ~~~~~~~~~~~~~^~~~~~
| /home/hari/oe-core/build/tmp/work/armv8a-tdx-linux/mozjs-115/115.8.0/firefox-115.8.0/js/src/vm/Watchtower.cpp: In static member function 'static bool js::Watchtower::watchPropertyChangeSlow(JSContext*, JS::Handle<js::NativeObject*>, JS::HandleId, js::PropertyFlags)':
| /home/hari/oe-core/build/tmp/work/armv8a-tdx-linux/mozjs-115/115.8.0/firefox-115.8.0/js/src/vm/Watchtower.cpp:242:22: note: 'map' declared here
| 242 | Rooted<PropMap*> map(cx, obj->shape()->lookup(cx, id, &propIndex));
| | ^~~
| /home/hari/oe-core/build/tmp/work/armv8a-tdx-linux/mozjs-115/115.8.0/firefox-115.8.0/js/src/vm/Watchtower.cpp:228:53: note: 'cx' declared here
| 228 | bool Watchtower::watchPropertyChangeSlow(JSContext* cx,
| | ~~~~~~~~~~~^~
| In file included from /home/hari/oe-core/build/tmp/work/armv8a-tdx-linux/mozjs-115/115.8.0/build/dist/include/js/CallArgs.h:73,
| from /home/hari/oe-core/build/tmp/work/armv8a-tdx-linux/mozjs-115/115.8.0/build/dist/include/js/CallNonGenericMethod.h:12,
| from /home/hari/oe-core/build/tmp/work/armv8a-tdx-linux/mozjs-115/115.8.0/firefox-115.8.0/js/src/NamespaceImports.h:15,
| from /home/hari/oe-core/build/tmp/work/armv8a-tdx-linux/mozjs-115/115.8.0/firefox-115.8.0/js/src/vm/NativeObject.h:17,
| from /home/hari/oe-core/build/tmp/work/armv8a-tdx-linux/mozjs-115/115.8.0/firefox-115.8.0/js/src/builtin/AtomicsObject.h:15,
| from /home/hari/oe-core/build/tmp/work/armv8a-tdx-linux/mozjs-115/115.8.0/firefox-115.8.0/js/src/vm/JSContext.h:17,
| from /home/hari/oe-core/build/tmp/work/armv8a-tdx-linux/mozjs-115/115.8.0/firefox-115.8.0/js/src/threading/ProtectedData.cpp:10,
| from Unified_cpp_js_src9.cpp:2:
| In member function 'void JS::Rooted<T>::registerWithRootLists(JS::RootedListHeads&) [with T = JSObject*]',
| inlined from 'JS::Rooted<T>::Rooted(const RootingContext&, S&&) [with RootingContext = JSContext*; S = JSObject*; T = JSObject*]' at /home/hari/oe-core/build/tmp/work/armv8a-tdx-linux/mozjs-115/115.8.0/build/dist/include/js/RootingAPI.h:1174:26,
| inlined from 'static bool js::UnmappedArgumentsObject::obj_resolve(JSContext*, JS::HandleObject, JS::HandleId, bool*)' at /home/hari/oe-core/build/tmp/work/armv8a-tdx-linux/mozjs-115/115.8.0/firefox-115.8.0/js/src/vm/ArgumentsObject.cpp:962:70:
| /home/hari/oe-core/build/tmp/work/armv8a-tdx-linux/mozjs-115/115.8.0/build/dist/include/js/RootingAPI.h:1141:18: warning: storing the address of local variable 'throwTypeError' in '((js::StackRootedBase**)cx)[3]' [-Wdangling-pointer=]
| 1141 | *this->stack = this;
| | ~~~~~~~~~~~~~^~~~~~
| In file included from Unified_cpp_js_src9.cpp:47:
| /home/hari/oe-core/build/tmp/work/armv8a-tdx-linux/mozjs-115/115.8.0/firefox-115.8.0/js/src/vm/ArgumentsObject.cpp: In static member function 'static bool js::UnmappedArgumentsObject::obj_resolve(JSContext*, JS::HandleObject, JS::HandleId, bool*)':
| /home/hari/oe-core/build/tmp/work/armv8a-tdx-linux/mozjs-115/115.8.0/firefox-115.8.0/js/src/vm/ArgumentsObject.cpp:961:18: note: 'throwTypeError' declared here
| 961 | RootedObject throwTypeError(
| | ^~~~~~~~~~~~~~
| /home/hari/oe-core/build/tmp/work/armv8a-tdx-linux/mozjs-115/115.8.0/firefox-115.8.0/js/src/vm/ArgumentsObject.cpp:943:54: note: 'cx' declared here
| 943 | bool UnmappedArgumentsObject::obj_resolve(JSContext* cx, HandleObject obj,
| | ~~~~~~~~~~~^~
| In member function 'void JS::Rooted<T>::registerWithRootLists(JS::RootedListHeads&) [with T = js::SharedShape*]',
| inlined from 'JS::Rooted<T>::Rooted(const RootingContext&, S&&) [with RootingContext = JSContext*; S = js::SharedShape*; T = js::SharedShape*]' at /home/hari/oe-core/build/tmp/work/armv8a-tdx-linux/mozjs-115/115.8.0/build/dist/include/js/RootingAPI.h:1174:26,
| inlined from 'static js::ArgumentsObject* js::ArgumentsObject::createTemplateObject(JSContext*, bool)' at /home/hari/oe-core/build/tmp/work/armv8a-tdx-linux/mozjs-115/115.8.0/firefox-115.8.0/js/src/vm/ArgumentsObject.cpp:240:65:
| /home/hari/oe-core/build/tmp/work/armv8a-tdx-linux/mozjs-115/115.8.0/build/dist/include/js/RootingAPI.h:1141:18: warning: storing the address of local variable 'shape' in '((js::StackRootedBase**)cx)[5]' [-Wdangling-pointer=]
| 1141 | *this->stack = this;
| | ~~~~~~~~~~~~~^~~~~~
| /home/hari/oe-core/build/tmp/work/armv8a-tdx-linux/mozjs-115/115.8.0/firefox-115.8.0/js/src/vm/ArgumentsObject.cpp: In static member function 'static js::ArgumentsObject* js::ArgumentsObject::createTemplateObject(JSContext*, bool)':
| /home/hari/oe-core/build/tmp/work/armv8a-tdx-linux/mozjs-115/115.8.0/firefox-115.8.0/js/src/vm/ArgumentsObject.cpp:238:24: note: 'shape' declared here
| 238 | Rooted<SharedShape*> shape(cx, SharedShape::getInitialShape(
| | ^~~~~
| /home/hari/oe-core/build/tmp/work/armv8a-tdx-linux/mozjs-115/115.8.0/firefox-115.8.0/js/src/vm/ArgumentsObject.cpp:230:67: note: 'cx' declared here
| 230 | ArgumentsObject* ArgumentsObject::createTemplateObject(JSContext* cx,
| | ~~~~~~~~~~~^~
| make[3]: Leaving directory '/home/hari/oe-core/build/tmp/work/armv8a-tdx-linux/mozjs-115/115.8.0/build/js/src'
| make[2]: Leaving directory '/home/hari/oe-core/build/tmp/work/armv8a-tdx-linux/mozjs-115/115.8.0/build'
| make[1]: *** [/home/hari/oe-core/build/tmp/work/armv8a-tdx-linux/mozjs-115/115.8.0/firefox-115.8.0/config/recurse.mk:34: compile] Error 2
| make[1]: Leaving directory '/home/hari/oe-core/build/tmp/work/armv8a-tdx-linux/mozjs-115/115.8.0/build'
| make: *** [/home/hari/oe-core/build/tmp/work/armv8a-tdx-linux/mozjs-115/115.8.0/firefox-115.8.0/config/rules.mk:361: default] Error 2
| ERROR: oe_runmake failed
| WARNING: exit code 1 from a shell command.
ERROR: Task (/home/hari/oe-core/build/../layers/meta-openembedded/meta-oe/recipes-extended/mozjs/mozjs-115_115.8.0.bb:do_compile) failed with exit code '1'
Setscene tasks: 5770 of 5770
Currently 6 running tasks (7478 of 11854) 63% |############################################## |
0: linux-toradex-6.6.101+git-r0 do_compile - 25m40s (pid 3302273)
1: qtxmlpatterns-native-5.15.13+git-r0 do_compile - 3m11s (pid 3519872)
2: librsvg-native-2.57.1-r0 do_compile - 2m39s (pid 3527506)
3: coreutils-native-9.4-r0 do_configure - 2m23s (pid 3530114)
4: boost-1.84.0-r0 do_package - 2m19s (pid 3530424)
5: alsa-utils-1.2.11-r0 do_install - 12s (pid 3544336)
Why the basic bsp layer’s are failing for the bsp version 7.5.0 given in the toradex docs i have followed that to build the OS.
The error you’re encountering is now related to the Mozilla JavaScript engine (mozjs-115) compilation, not Qt5. This is a different build issue that has emerged after removing your custom layers.
The error shows compilation warnings and failures in the mozjs-115 package(1). The warnings about “dangling pointers” and the compilation failure indicate a compiler compatibility issue with the JavaScript engine build.
This mozjs-115 build failure suggests:
meta-browser layer dependencies might be causing conflictsThe failing package is from meta-openembedded/meta-oe/recipes-extended/mozjs/mozjs-115_115.8.0.bb. This suggests you may have browser-related packages in your build.
Since you’re building tdx-reference-multimedia-image, check if you need browser components(1). If not, remove them from your configuration:
# In your local.conf, remove any browser-related packages
IMAGE_INSTALL:remove = " firefox chromium "
$ bitbake -c cleansstate mozjs-115
$ bitbake -c cleanall mozjs-115
Mozilla components are memory-intensive to compile(1):
$ PARALLEL_MAKE="-j 2" BB_NUMBER_THREADS="4" bitbake tdx-reference-multimedia-image
If browser functionality isn’t required, consider building the minimal reference image first(1):
$ bitbake tdx-reference-minimal-image
This will help isolate whether the issue is specific to multimedia components or affects the entire build system.
Verify that your current bblayers.conf doesn’t include browser-related layers that might be pulling in mozjs-115 as a dependency. The error suggests that even with custom layers commented out, some browser components are still being built.
The build should complete successfully with the core Toradex BSP layers for the Verdin iMX8MP without requiring JavaScript engine compilation unless specifically needed for your application.
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.
Your configuration appears clean, but the mozjs-115 build failure indicates that this JavaScript engine is being pulled in as a dependency by one of the core layers, even without browser-specific configurations.
The mozjs-115 package is being built as a dependency of another component in your multimedia image(1). Even with a clean layer configuration, the tdx-reference-multimedia-image includes packages that may depend on JavaScript engines.
The issue stems from the multimedia image’s package groups. The tdx-reference-multimedia-image includes comprehensive multimedia support(1), which can pull in web-related dependencies through:
Test with the minimal reference image to isolate the issue(1):
$ bitbake tdx-reference-minimal-image
$ bitbake -c cleansstate mozjs-115
$ bitbake -c cleansstate gstreamer1.0-plugins-bad
$ bitbake -c cleansstate qtwebengine
Check what’s pulling in mozjs-115:
$ bitbake -g tdx-reference-multimedia-image
$ grep -r "mozjs-115" pn-buildlist
Add to your local.conf(1):
# Explicitly remove web-related packages
IMAGE_INSTALL:remove = " qtwebengine qtwebkit "
PACKAGECONFIG:remove:pn-gstreamer1.0-plugins-bad = " webrtc "
Modify your image to include only essential multimedia components:
IMAGE_INSTALL:append = " \
gstreamer1.0 \
gstreamer1.0-plugins-base \
gstreamer1.0-plugins-good \
"
Your current layer configuration looks correct for BSP 7.5.0(2). The issue isn’t with layer ordering but with package dependencies within the multimedia image.
For BSP 7.5.0 Scarthgap, ensure your host system meets the requirements(2):
The minimal image should build successfully, confirming that your core BSP setup is correct. The multimedia image issue can then be resolved by selectively adding only the multimedia components you actually need, avoiding the JavaScript engine dependency.
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.
Hi @ToradexAI,
Check my local conf file for the new fresh build from the start without the multimedia once it will complete than i will add it,
local_conf.txt (4.7 KB)
I cannot access the uploaded local.conf file you’ve attached. However, I can guide you on the correct configuration for a fresh minimal build based on your Verdin iMX8MP setup.
For your Verdin iMX8MP with BSP 7.5.0 Scarthgap, your local.conf should include these essential settings(1):
MACHINE ?= "verdin-imx8mp"
ACCEPT_FSL_EULA = "1"
Your DISTRO should automatically select tdx-xwayland for the Verdin iMX8MP(1), but you can explicitly set it:
DISTRO ?= "tdx-xwayland"
For the initial clean build, use the minimal image(1):
$ bitbake tdx-reference-minimal-image
Once your minimal image builds successfully, you can then incrementally add multimedia components:
# After successful minimal build
$ bitbake tdx-reference-multimedia-image
If you continue experiencing build issues, try building with reduced parallelism(1):
$ PARALLEL_MAKE="-j 4" BB_NUMBER_THREADS="6" bitbake tdx-reference-minimal-image
This approach will help isolate whether the build issues are related to your configuration or system resources, and provide a solid foundation before adding multimedia components.
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.
Hi @ToradexAI,
I have build the fresh build without the custom components successfully now I need integrate the custom components with the order one by one to complete the build. so guide the order list that I have given below to start fro first to last in the local.conf file and bblayers and meta-layers that I have added.
# Include machine-specific configuration
include conf/machine/include/${MACHINE}.inc
ACCEPT_FSL_EULA = "1"
# ===== Basic Tools and System Utilities =====
# IMAGE_INSTALL:append = " \
# nano \
# curl wget \
# weston wayland-utils \
# modemmanager \
# ppp \
# ppp-dialin \
# ppp-tools \
# libqmi \
# libmbim \
# usb-modeswitch \
# ppp \
# xdg-utils \
# unclutter-xfixes \
# "
# Production Runtime Tools
# IMAGE_INSTALL:append = " zip tree parted smartmontools dnsmasq"
# Disable Demo Media
# IMAGE_INSTALL:remove = "media-files"
# Enable required features
# DISTRO_FEATURES:append = " cellular ppp"
# Add PSplash Support
# CORE_IMAGE_EXTRA_INSTALL += "psplash"
# IMAGE_INSTALL:append = " psplash"
# Add Plymouth Support
# CORE_IMAGE_EXTRA_INSTALL += "plymouth"
# Plymouth without dracut dependency
# CORE_IMAGE_EXTRA_INSTALL += "plymouth plymouth-lite"
# Alternative: Use psplash instead of Plymouth
# CORE_IMAGE_EXTRA_INSTALL += "psplash"
# Chromium Browser (GPU accelerated)
# CORE_IMAGE_EXTRA_INSTALL += "chromium-ozone-wayland"
# Accept commercial licensed codecs for Chromium
# LICENSE_FLAGS_ACCEPTED += "commercial commercial_libav commercial_x264"
# ===== GPU Acceleration =====
# PREFERRED_PROVIDER_virtual/egl = "imx-gpu-viv"
# PREFERRED_PROVIDER_virtual/libgl = "imx-gpu-viv"
# PREFERRED_PROVIDER_virtual/libgles2 = "imx-gpu-viv"
# Fix GStreamer preferred version warnings
# PREFERRED_VERSION_gstreamer1.0-plugins-ugly = "1.24.0.imx"
# PREFERRED_VERSION_gstreamer1.0-plugins-ugly-dev = "1.24.0.imx"
# PREFERRED_VERSION_gstreamer1.0-plugins-ugly-meta = "1.24.0.imx"
# PREFERRED_VERSION_gstreamer1.0-plugins-ugly-asf = "1.24.0.imx"
# PREFERRED_VERSION_gstreamer1.0-libav = "1.24.0.imx"
# PREFERRED_VERSION_gstreamer1.0-libav-dev = "1.24.0.imx"
# Test Suite Service
# IMAGE_INSTALL:append = " test-suite"
# Lokbest Project Service
# IMAGE_INSTALL:append = " lokbest-project"
# Ensure TEZI image format
# IMAGE_FSTYPES += "teziimg"
# Remove Media File for Production Files
# IMAGE_INSTALL:append = " rootfs-cleanup"
# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
LCONF_VERSION = "7"
BBPATH = "${TOPDIR}"
BBFILES ?= ""
BBLAYERS_NXP ?= " \
${TOPDIR}/../layers/meta-toradex-nxp \
${TOPDIR}/../layers/meta-freescale \
${TOPDIR}/../layers/meta-freescale-3rdparty \
"
BBLAYERS_TI ?= " \
${TOPDIR}/../layers/meta-toradex-ti \
${TOPDIR}/../layers/meta-arm/meta-arm-toolchain \
${TOPDIR}/../layers/meta-arm/meta-arm \
${TOPDIR}/../layers/meta-ti/meta-ti-bsp \
${TOPDIR}/../layers/meta-ti/meta-ti-extras \
"
BBLAYERS ?= " \
${BBLAYERS_NXP} \
${BBLAYERS_TI} \
${TOPDIR}/../layers/meta-toradex-bsp-common \
${TOPDIR}/../layers/meta-openembedded/meta-oe \
${TOPDIR}/../layers/meta-openembedded/meta-filesystems \
${TOPDIR}/../layers/meta-openembedded/meta-networking \
${TOPDIR}/../layers/meta-openembedded/meta-multimedia \
${TOPDIR}/../layers/meta-openembedded/meta-python \
${TOPDIR}/../layers/meta-freescale-distro \
${TOPDIR}/../layers/meta-toradex-demos \
${TOPDIR}/../layers/meta-qt5 \
${TOPDIR}/../layers/meta-security/meta-tpm \
${TOPDIR}/../layers/meta-toradex-distro \
${TOPDIR}/../layers/meta-yocto/meta-poky \
${TOPDIR}/../layers/openembedded-core/meta \
"
hari@Administrator:~/oe-core/layers$ ls
meta-arm meta-freescale-3rdparty meta-openembedded meta-toradex-bsp-common meta-toradex-nxp
meta-browser meta-freescale-distro meta-qt5 meta-toradex-chromium meta-toradex-ti
meta-custom meta-imx meta-security meta-toradex-demos meta-yocto
meta-freescale meta-lokbest meta-ti meta-toradex-distro openembedded-core
hari@Administrator:~/oe-core/layers$
/home/hari/oe-core/layers/meta-toradex-chromium \
${TOPDIR}/../layers/meta-custom \
"
BBLAYERS += " ${TOPDIR}/../layers/meta-browser/meta-chromium"
BBLAYERS += " ${TOPDIR}/../layers/meta-openembedded/meta-clang"
BBLAYERS += "/home/hari/oe-core/layers/meta-lokbest"
# Incremental Integration Guide for Custom Layers and Components
Excellent! Now that your base build is working, let’s add your custom components incrementally to avoid build conflicts. Here’s the recommended integration order:
Add this to your bblayers.conf first, as it’s a dependency for other components(1):
BBLAYERS += " ${TOPDIR}/../layers/meta-openembedded/meta-clang"
Test build:
$ bitbake tdx-reference-minimal-image
Once meta-clang builds successfully, add the browser layer(2):
BBLAYERS += " ${TOPDIR}/../layers/meta-browser/meta-chromium"
Uncomment these lines in your local.conf(2):
# Chromium Browser (GPU accelerated)
CORE_IMAGE_EXTRA_INSTALL += "chromium-ozone-wayland"
# Accept commercial licensed codecs for Chromium
LICENSE_FLAGS_ACCEPTED += "commercial commercial_libav commercial_x264"
Test build after each addition:
$ bitbake tdx-reference-minimal-image
Add your custom Chromium layer(2):
${TOPDIR}/../layers/meta-toradex-chromium \
Add your custom layer(1):
${TOPDIR}/../layers/meta-custom \
Add your project-specific layer last:
BBLAYERS += "/home/hari/oe-core/layers/meta-lokbest"
Uncomment these essential tools in local.conf:
IMAGE_INSTALL:append = " \
nano \
curl wget \
weston wayland-utils \
"
Add cellular and networking support:
IMAGE_INSTALL:append = " \
modemmanager \
ppp \
ppp-dialin \
ppp-tools \
libqmi \
libmbim \
usb-modeswitch \
"
# Enable required features
DISTRO_FEATURES:append = " cellular ppp"
Add production utilities:
IMAGE_INSTALL:append = " zip tree parted smartmontools dnsmasq"
Finally, add your custom services:
# Test Suite Service
IMAGE_INSTALL:append = " test-suite"
# Lokbest Project Service
IMAGE_INSTALL:append = " lokbest-project"
After each phase:
Your final bblayers.conf should look like this(1):
BBLAYERS ?= " \
${BBLAYERS_NXP} \
${BBLAYERS_TI} \
${TOPDIR}/../layers/meta-toradex-bsp-common \
${TOPDIR}/../layers/meta-openembedded/meta-oe \
${TOPDIR}/../layers/meta-openembedded/meta-filesystems \
${TOPDIR}/../layers/meta-openembedded/meta-networking \
${TOPDIR}/../layers/meta-openembedded/meta-multimedia \
${TOPDIR}/../layers/meta-openembedded/meta-python \
${TOPDIR}/../layers/meta-freescale-distro \
${TOPDIR}/../layers/meta-toradex-demos \
${TOPDIR}/../layers/meta-qt5 \
${TOPDIR}/../layers/meta-security/meta-tpm \
${TOPDIR}/../layers/meta-toradex-distro \
${TOPDIR}/../layers/meta-yocto/meta-poky \
${TOPDIR}/../layers/openembedded-core/meta \
${TOPDIR}/../layers/meta-toradex-chromium \
${TOPDIR}/../layers/meta-custom \
"
BBLAYERS += " ${TOPDIR}/../layers/meta-browser/meta-chromium"
BBLAYERS += " ${TOPDIR}/../layers/meta-openembedded/meta-clang"
BBLAYERS += "/home/hari/oe-core/layers/meta-lokbest"
bitbake -c cleansstate <failing-recipe> for specific failuresPARALLEL_MAKE="-j 4" BB_NUMBER_THREADS="6"This incremental approach will help you identify exactly which component causes issues if they arise.
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.
Hi @ToradexAI,
Here the demo and ti bblayers and meta layers are really needed for the verdin imx8mp toradex bsp 7.5.0 scarthgap version build board.
If any unwanted layers and configs are there means remove that and give me the final local.conf and bblayers and mention the exact meta layers for these board Image OS build.
Based on the Verdin iMX8MP specifications and BSP 7.5.0 requirements, here’s the streamlined configuration removing unnecessary layers:
# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
LCONF_VERSION = "7"
BBPATH = "${TOPDIR}"
BBFILES ?= ""
BBLAYERS_NXP ?= " \
${TOPDIR}/../layers/meta-toradex-nxp \
${TOPDIR}/../layers/meta-freescale \
${TOPDIR}/../layers/meta-freescale-3rdparty \
"
BBLAYERS ?= " \
${BBLAYERS_NXP} \
${TOPDIR}/../layers/meta-toradex-bsp-common \
${TOPDIR}/../layers/meta-openembedded/meta-oe \
${TOPDIR}/../layers/meta-openembedded/meta-filesystems \
${TOPDIR}/../layers/meta-openembedded/meta-networking \
${TOPDIR}/../layers/meta-openembedded/meta-multimedia \
${TOPDIR}/../layers/meta-openembedded/meta-python \
${TOPDIR}/../layers/meta-freescale-distro \
${TOPDIR}/../layers/meta-toradex-demos \
${TOPDIR}/../layers/meta-qt5 \
${TOPDIR}/../layers/meta-security/meta-tpm \
${TOPDIR}/../layers/meta-toradex-distro \
${TOPDIR}/../layers/meta-yocto/meta-poky \
${TOPDIR}/../layers/openembedded-core/meta \
"
TI Layers Removed (not needed for iMX8MP):
meta-toradex-timeta-arm/meta-arm-toolchainmeta-arm/meta-armmeta-ti/meta-ti-bspmeta-ti/meta-ti-extrasThe TI layers are only required for AM62/AM69 platforms, not for NXP iMX8MP (1).
# Machine Configuration
MACHINE ?= "verdin-imx8mp"
# NXP EULA Acceptance (Required for iMX8MP)
ACCEPT_FSL_EULA = "1"
# Distribution automatically selects tdx-xwayland for Verdin iMX8MP
DISTRO ?= "tdx-xwayland"
# Basic system utilities
IMAGE_INSTALL:append = " \
nano \
curl wget \
weston wayland-utils \
"
# GPU Acceleration (Essential for iMX8MP)
PREFERRED_PROVIDER_virtual/egl = "imx-gpu-viv"
PREFERRED_PROVIDER_virtual/libgl = "imx-gpu-viv"
PREFERRED_PROVIDER_virtual/libgles2 = "imx-gpu-viv"
Essential layers only:
meta-arm # Not needed for iMX8MP - REMOVE
meta-browser # Optional - only if browser needed
meta-custom # Your custom layer
meta-freescale # Essential for iMX8MP
meta-freescale-3rdparty # Essential for iMX8MP
meta-freescale-distro # Essential for iMX8MP
meta-imx # Not directly needed - covered by meta-freescale
meta-lokbest # Your project layer
meta-openembedded # Essential
meta-qt5 # Essential for multimedia
meta-security # Essential
meta-ti # Not needed for iMX8MP - REMOVE
meta-toradex-bsp-common # Essential
meta-toradex-chromium # Optional - only if Chromium needed
meta-toradex-demos # Essential
meta-toradex-distro # Essential
meta-toradex-nxp # Essential for iMX8MP
meta-toradex-ti # Not needed for iMX8MP - REMOVE
meta-yocto # Essential
openembedded-core # Essential
Remove these from your layers directory as they’re not needed:
meta-arm (ARM-specific, not needed for iMX8MP)meta-ti (Texas Instruments only)meta-toradex-ti (Texas Instruments only)For minimal image:
$ bitbake tdx-reference-minimal-image
For multimedia image (after minimal succeeds):
$ bitbake tdx-reference-multimedia-image
If adding your custom layers back:
meta-custommeta-lokbestmeta-toradex-chromium (if browser needed)This streamlined configuration removes all TI-specific layers and focuses only on what’s required for the Verdin iMX8MP with BSP 7.5.0 Scarthgap.
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.
Hi @ToradexAI,
The meta-arm chain will used for the cross compilation toolchain or not. if yes it need for the build right?
meta-arm/meta-arm-toolchainmeta-arm/meta-armFor Verdin iMX8MP specifically: NO, meta-arm layers are NOT required.
The Verdin iMX8MP uses NXP’s iMX8M Plus SoC, which is built using standard ARM GNU toolchains that are already provided by the core Yocto layers(1). The cross-compilation setup for iMX8MP uses:
$ wget -O arm-gnu-toolchain-12.3.rel1-x86_64-aarch64-none-linux-gnu.tar.xz "https://developer.arm.com/-/media/Files/downloads/gnu/12.3.rel1/binrel/arm-gnu-toolchain-12.3.rel1-x86_64-aarch64-none-linux-gnu.tar.xz?rev=cf8baa0ef2e54e9286f0409cdda4f66c&hash=4E1BA6BFC2C09EA04DBD36C393C9DD3A"
$ tar xvf arm-gnu-toolchain-12.3.rel1-x86_64-aarch64-none-linux-gnu.tar.xz
The meta-arm layers are only required for Texas Instruments platforms(3):
BBLAYERS_TI ?= " \
${TOPDIR}/../layers/meta-toradex-ti \
${TOPDIR}/../layers/meta-arm/meta-arm-toolchain \
${TOPDIR}/../layers/meta-arm/meta-arm \
${TOPDIR}/../layers/meta-ti/meta-ti-bsp \
${TOPDIR}/../layers/meta-ti/meta-ti-extras \
"
BBLAYERS_NXP only - no meta-arm neededBBLAYERS_TI which includes meta-arm layers(3)BBLAYERS_TI which includes meta-arm layers(4)Your bblayers.conf should use only NXP-specific layers:
BBLAYERS_NXP ?= " \
${TOPDIR}/../layers/meta-toradex-nxp \
${TOPDIR}/../layers/meta-freescale \
${TOPDIR}/../layers/meta-freescale-3rdparty \
"
BBLAYERS ?= " \
${BBLAYERS_NXP} \
${TOPDIR}/../layers/meta-toradex-bsp-common \
# ... other core layers
"
The cross-compilation toolchain for iMX8MP is handled automatically by the NXP-specific layers and doesn’t require the meta-arm toolchain layers.
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.
Hi @ToradexAI,
I have retreived the machine id and serial number of the som and how can I retreive the unique Id for the Carrier Board as serial number is printed on it or any specific unique id is there to retreive or any id for identify the carrier board with som.
root@verdin-imx8mp-15722251:~# cat /etc/machine-id
87fcbb479afe49b5a2c6a314a57b2247
root@verdin-imx8mp-15722251:~# cat /proc/device-tree/serial-number
15722251root@verdin-imx8mp-15722251:~#
The serial number you retrieved (15722251) is specific to the SoM (System on Module) only(1). For carrier board identification, Toradex uses different approaches:
The serial number can be read from userspace using these methods(1):
cat /proc/cpuinfo | grep Serial
# or
cat /proc/cpuinfo | grep Serial | cut -d ':' -f2
For device-tree enabled modules, the serial number is available in(1):
cat /proc/device-tree/serial-number
Carrier boards do NOT have unique serial numbers like SoMs. Instead, they are identified by:
Carrier boards use a standardized product numbering scheme(2). For example, the Aster Carrier Board uses PID8 format where:
Carrier boards have printed labels showing:
You can identify the carrier board through the device tree compatible string. Check your current setup:
cat /proc/device-tree/compatible
This will show strings like toradex,verdin-imx8mp-ivy which indicates you’re using the Ivy Carrier Board.
From your output, you have:
The most comprehensive way to get all hardware information is(1):
tdx-info
This provides complete hardware identification including both SoM and carrier board details.
Key Point: Unlike SoMs, carrier boards don’t have individual serial numbers - they’re identified by their product model, revision, and compatibility information in the device tree.
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.
Hi @ToradexAI,
I have the question like I have multiple Carrier Board and SOM if fixed one board to one carrier board then I change the board any of one, I’ll create the unique ID from SOM and Carrier Board Combination if any of the board is changed, then I can find the registered one is not connected different board is there so far I need the unique ID from the Carrier Board anything mac address or uuid , but in the carrier board in the printed sticker has the serial number then why it is not retreived by the code?