(适用于所有 TI Sitara 和 Jacinto 器件、如 AM62x、AM62Ax、AM64x、AM65x 等)
症状
当按照 SDK 说明进行 Yocto 编译时、例如下面这样的 SDK 默认映像...
MACHINE=am62xx-evm bitbake -k tisdk-default-image
....建立开始,但一段时间后,它似乎不再继续进行任何方式。 显示正在运行的任务及其状态未更新的进度显示。 当检查 CPU 负载/活动时(例如、使用'htop'实用程序)、没有显著的系统负载。 这似乎尤其在构建较大的图像(例如 tisdk-默认-图像 与 tisdk-base-image )的 SDK 中、尤其是对于更高版本/更高版本的 SDK、例如 SDK v8.6或 SDK v9.0。
例如、编译控制台可能如下图所示(小时数不变)：
NOTE: recipe python3-tensorflow-lite-2.8.0-r0: task do_compile: Started NOTE: recipe open62541-1.0.1+gitAUTOINC+e4309754fc-r0: task do_compile: Started NOTE: recipe powervr-graphics-5.8-r1: task do_compile: Started NOTE: recipe gtk+3-3.24.14-r0: task do_compile: Started NOTE: recipe glmark2-20191226+AUTOINC+72dabc5d72-r0.arago0: task do_compile: Started
问题分析、讨论和解决方案
Yocto 构建、尤其是用于更复杂/更大配方的构建、可能会使用大量的系统资源。 当启用了重构建并行功能时会出现这种情况-默认情况下是这样。 如果 Yocto 编译进程尝试使用的内存(RAM)超过可用的容量、则 负责防止进程耗尽 编译机器内存的 Linux 内核内存(oom)无效程序将终止关键的 Yocto 编译进程、 Yocto 编译本身无法检测到的方式、使整个编译挂起。 要查看您的编译是否确实受到此问题的影响、请终止您的 Yocto 编译(Ctrl+C 应多次执行此操作)、然后在内核日志中搜索运行程序已激活的符号。 如果您的内核日志与以下示例中最近的条目类似、则您的构建失败可能是由于运行错误所致。
$ sudo dmesg | grep oom [sudo] password for a0797059: [3024499.564459] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/user.slice/user-1001.slice/session-2.scope,task=Cooker,pid=2364037,uid=1001 [3024499.564480] Out of memory: Killed process 2364037 (Cooker) total-vm:1302284kB, anon-rss:36840kB, file-rss:0kB, shmem-rss:24kB, UID:1001 pgtables:2284kB oom_score_adj:0 [3085219.883311] xz invoked oom-killer: gfp_mask=0x140dca(GFP_HIGHUSER_MOVABLE|__GFP_COMP|__GFP_ZERO), order=0, oom_score_adj=0 [3085219.883338] oom_kill_process.cold+0xb/0x10 [3085219.883342] __alloc_pages_may_oom+0x117/0x1e0 [3085219.883473] [ pid ] uid tgid total_vm rss pgtables_bytes swapents oom_score_adj name [3085219.883492] [ 668] 108 668 3706 32 65536 179 -900 systemd-oomd [3085219.884409] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/user.slice/user-1001.slice/session-2.scope,task=cc1plus,pid=3120743,uid=1001 [3085219.884423] Out of memory: Killed process 3120743 (cc1plus) total-vm:4242032kB, anon-rss:4094828kB, file-rss:0kB, shmem-rss:0kB, UID:1001 pgtables:8232kB oom_score_adj:0
可以通过增加可用于构建的 RAM 数量(添加物理 RAM 模块、增加交换空间、不加载包含其他任务的构建机器)来解决该问题。 或者、由于这可能并不总是实用、因此通过重新配置 Yocto 构建并行功能来构建较少的并行内容。 请注意、之前的示例 来自一个具有64GB RAM、20 CPU 内核的构建机器、构建一个 AM64 SDK v9.0 tisdk-default-image、展示如果你认为你有一个相当强大的机器也可能会发生这种情况。
Yocto 编译并行性是通过 BBBB_Number_threads 和 parallel_make 变量控制的、可以通过更新(取消注释和更改)编译的以下部分来轻松更改(取消注释和更改) conf/local.conf 文件：
# # Parallelism Options # # These two options control how much parallelism BitBake should use. The first # option determines how many tasks bitbake should run in parallel: # # BB_NUMBER_THREADS ?= "1" # # The second option controls how many processes make should run in parallel when # running compile tasks: # # PARALLEL_MAKE ?= "-j 1" # # For a quad-core machine, BB_NUMBER_THREADS = "4", PARALLEL_MAKE = "-j 4" would # be appropriate for example # # NOTE: By default, bitbake will choose the number of processeors on your host # so you should not need to set this unless you are wanting to lower the number # allowed. #
如果出现编译问题、请尝试设置 BB_编号_主题帖 至 "1" 出于调试目的、并查看现在的编译是否可以进行此操作。 请注意、在重新尝试构建之前、您可能首先需要手动清除/终止计算机上可能仍在运行的任何剩余 Yocto 进程 (如 bitbake-server)。 如果此操作有效，则您可以尝试为该变量找到更合适(更快)的设置，该设置在给定的计算机上仍然有效，方法是使用小于可用 CPU 数量(但大于1)的值。