TorizonCore 5.7.2 on imx6ull/256/256. Host Ubuntu 22.04.2 LTS
Following Build TorizonCore from Source With Yocto Project/OpenEmbedded | Toradex Developer Center, “bitbake” runs OK, generated image boots and runs as expected.
Trying to understand device trees (enabling two more UARTs, and enabling 250kbps/1.25mbps), found following thread: imx6ULL custom device tree. The most interesting part here was using bitbake to compile the kernel. However, this produces following:
[~/oe-core/build]$ bitbake virtual/kernel -c devshell
ERROR: Execution of event handler 'toradex_check_sanity_eventhandler' failed
Traceback (most recent call last):
File "/home/XXX/oe-core/build/../layers/meta-toradex-bsp-common/classes/toradex-sanity.bbclass", line 66, in toradex_check_sanity_eventhandler(e=<bb.event.SanityCheck object at 0x7f079991f790>):
if bb.event.getName(e) == "SanityCheck":
> sanity_data = copy_data(e)
if e.generateevents:
NameError: name 'copy_data' is not defined
ERROR: Command execution failed: Traceback (most recent call last):
File "/home/XXX/oe-core/layers/openembedded-core/bitbake/lib/bb/command.py", line 108, in runAsyncCommand
self.cooker.updateCache()
File "/home/XXX/oe-core/layers/openembedded-core/bitbake/lib/bb/cooker.py", line 1547, in updateCache
bb.event.fire(bb.event.SanityCheck(False), self.databuilder.mcdata[mc])
File "/home/XXX/oe-core/layers/openembedded-core/bitbake/lib/bb/event.py", line 214, in fire
fire_class_handlers(event, d)
File "/home/XXX/oe-core/layers/openembedded-core/bitbake/lib/bb/event.py", line 121, in fire_class_handlers
execute_handler(name, handler, event, d)
File "/home/XXX/oe-core/layers/openembedded-core/bitbake/lib/bb/event.py", line 93, in execute_handler
ret = handler(event)
File "/home/XXX/oe-core/build/../layers/meta-toradex-bsp-common/classes/toradex-sanity.bbclass", line 66, in toradex_check_sanity_eventhandler
sanity_data = copy_data(e)
NameError: name 'copy_data' is not definedThe strangest moment is that after that, even “normal” bitbake tdx-reference-minimal-image fails with exactly the same error.
Of course, I can (and probably will) start from scratch, but would like to know what happens, and how to use this seemingly useful feature. It’s completely different question that the whole devicetree concept (as implemented by NXP/TDX) is poorly documented, to say the least.