下次只需一条wsl bash /mnt/d/tmp2/run_build10.sh。若环境被重置导致 wrapper 丢失先跑wsl bash /mnt/d/tmp2/install_armlink_v3.sh再编译。run_build10.s#!/bin/bash set -x ROOT/home/jc/ar1/aliso-la-1-0_amss_standard_oem/BOOT.MXF.2.2 PYBIN/home/jc/py3bin mkdir -p $PYBIN if [ -e $PYBIN/python ] || [ -L $PYBIN/python ]; then rm -f $PYBIN/python; fi ln -s /usr/bin/python3.8 $PYBIN/python export PATH$PYBIN:$PATH echo python now resolves to: $(which python) python --version cd $ROOT/boot_images if [ ! -e /home/jc/bin/sectools ] [ ! -L /home/jc/bin/sectools ]; then ln -s /home/jc/bin/sectools_wrapper /home/jc/bin/sectools fi ls -la /home/jc/bin/sectools python -u boot_tools/buildex.py -t Aliso -v LAA -r RELEASE /mnt/d/tmp2/xbl_build_run10.log 21 echo BUILD EXIT CODE: $?install_armlink_v3.sh#!/bin/bash # Install arm-link v3 (comment-aware ASSERT stripping) and verify against # both GccBase.lds (multi-line comments, no ASSERT) and generated DevPrgD.ld # (orphan trailing */ on ASSERT line multi-line ASSERT). set -e BIN/pkg/qct/software/llvm/release/arm/14.0.0/bin SRC/mnt/d/tmp2/new_arm-link_v3.sh ROOT/home/jc/ar1/aliso-la-1-0_amss_standard_oem/BOOT.MXF.2.2 echo backup current arm-link as arm-link.bak.v2 if [ -f $BIN/arm-link.bak.v2 ]; then echo arm-link.bak.v2 already exists, overwriting fi cp -f $BIN/arm-link $BIN/arm-link.bak.v2 echo install v3 (strip CR from Windows drive copy) tr -d \r $SRC /tmp/arm-link.v3.lf cp -f /tmp/arm-link.v3.lf $BIN/arm-link chmod x $BIN/arm-link echo verify line endings (must be ASCII text, LF only) file $BIN/arm-link if grep -q $\r $BIN/arm-link; then echo ERROR: CR still present in installed arm-link exit 1 else echo OK: no CR characters fi echo direct python test of v3 preprocess logic cat /tmp/preprocess_v3.py PYEOF import sys src, dst sys.argv[1], sys.argv[2] out [] in_comment False in_assert False def strip_trailing_comment_close(s): while s.rstrip().endswith(*/): s s.rstrip()[:-2].rstrip() return s for ln in open(src, r).read().splitlines(): s ln if in_assert: out.append(/* stripped ASSERT cont: s.strip() */) code strip_trailing_comment_close(s) if ); in code: in_assert False continue parts [] i 0 n len(s) while i n: if in_comment: j s.find(*/, i) if j -1: parts.append((comment, s[i:])) i n else: parts.append((comment, s[i:j 2])) i j 2 in_comment False else: j s.find(/*, i) if j -1: parts.append((code, s[i:])) i n else: parts.append((code, s[i:j])) parts.append((comment, s[j:j 2])) i j 2 in_comment True code_str .join(t for k, t in parts if k code) comments_str .join(t for k, t in parts if k comment) if ASSERT in code_str: code_c strip_trailing_comment_close(code_str) out.append(/* stripped ASSERT: code_c.strip() */) if comments_str: out.append(comments_str) if not code_c.rstrip().endswith();): in_assert True continue out.append(.join(t for k, t in parts)) open(dst, w).write(\n.join(out) \n) PYEOF echo --- Test 1: GccBase.lds (multi-line comments) --- GCC$ROOT/boot_images/edk2/BaseTools/Scripts/GccBase.lds python3.8 /tmp/preprocess_v3.py $GCC /tmp/GccBase.v3.test.ld sed -n 15,30p /tmp/GccBase.v3.test.ld echo ... echo --- verify no stray directives / balanced comments --- grep -n stripped orphan\|unknown /tmp/GccBase.v3.test.ld echo PROBLEM || echo OK: no orphan marks echo echo --- Test 2: generated DevPrgD.ld (ASSERT orphan */) --- LD$ROOT/boot_images/Build/AlisoLAA/DevprogD/RELEASE_CLANG140LINUX/AARCH64/DevPrgD.ld python3.8 /tmp/preprocess_v3.py $LD /tmp/DevPrgD.v3.test.ld echo --- lines 44-66 --- sed -n 44,66p /tmp/DevPrgD.v3.test.ld echo echo --- check Image\$\\\$DEVPRG_DATA_RO\\\$\\\$Base present --- grep -n DEVPRG_DATA_RO.*Base /tmp/DevPrgD.v3.test.ld || echo MISSING! echo DONE 问题原因这套构建工具链CLANG140LINUX实际指向的是 clang/LLD 16.1.2。EDK2 构建系统调用arm-link链接本应是 ARM 的 armlink但系统里安装的是一个把它翻译成 GNUld.lld的 wrapper 脚本。这个 wrapper 是问题根源因为ld.lld与 ARM 工具链行为不同构建脚本喂给它的参数和链接脚本内容它都处理不了。问题 1DevprogD 链接失败第一次 build 的硬错误报错ld.lld: error: /tmp/DevPrgD.ld.noassert.*.ld:60: symbol not found: Image$$DEVPRG_DATA_RO$$Base排查过程我先写了check_noassert.sh检查 wrapper 生成的中间脚本定位到根因。生成的DevPrgD.ld第 50 行是一条被注释掉的 ASSERT格式为ASSERT(...); */—— clang -E 预处理时把开头的/*剥掉了只留下孤儿的*/。v2 wrapper 的in_assert状态机逻辑是进入 ASSERT 后检查行尾是否以);结束来退出断言状态。但这一行以*/结尾而不是);导致in_assert一直卡在 True把后面紧跟的DEVPRG_DATA_RO段整段吞掉于是Image$$DEVPRG_DATA_RO$$Base符号缺失。解决重写为v3 注释感知 wrapperarm-link备份为arm-link.bak.v2。核心逻辑用strip_trailing_comment_close()先剥掉行尾孤儿*/再做);完整性判断 → 不再误吞后续 section。同时覆盖单行、多行第 107-108 行、带孤儿*/三种 ASSERT 形态。问题 2Core Sec.dll 链接失败修完问题 1 后暴露的下一个错误报错ld.lld: error: /tmp/GccBase.lds.noassert.651580.ld:23: unknown directive: */排查过程这发生在Core.dsc的 Sec 模块链接用的是 EDK2 标准脚本GccBase.lds。关键发现GccBase.lds里有真实的多行注释第 18 行/*打开第 23 行*/闭合里面没有 ASSERT。我 v3 第一版的“孤儿*/处理”写得太激进只要检测到*/就剥掉。结果把合法的闭合*/也剥了留下悬空的/*导致第 23 行出现unknown directive: */。解决把 v3 重写为完整的注释感知状态机用标志位in_comment跟踪/* */块注释含多行跨行合法的注释原样透传、保持顺序只在非注释代码中剥离ASSERT(...)分别用GccBase.lds验证注释完整保留和生成的DevPrgD.ld验证 ASSERT 剥离 DEVPRG_DATA_RO保留做了单元验证通过后才重新跑 build。问题 3Windows 换行符CRLF破坏 wrapper现象从 Windows 盘D:\tmp2拷贝 wrapper 到 WSL 工具链目录后脚本无法执行shebang 被\r污染。解决安装时统一用tr -d \r去除 CR安装脚本里还带自检grep -q $\r检查并报错。这是后续所有脚本安装的固定套路。问题 4xbl_config 签名警告非致命现象构建日志出现No Sectools Folder provided. SKIPPING IMAGE SIGNING和ERROR: Could not generate Signed XBL Config。判定非致命—— 构建继续执行并最终报告全部 8 个镜像成功含 xbl_config。属于开发环境签名路径配置为空的行为走的是 unsigned 路径。不影响产物无需修复。最终结果修复完问题 12即 v3 注释感知 wrapper后run10完整编译成功0:36mins 产出全部 8 个镜像XBL_S、XBL_RAMDUMP、UEFI、XBL_S_DEVPRG_NS、JtagProgrammer、xbl_config、SHRM、ImageFv。关键经验总结报错根因修复symbol not found: Image$$DEVPRG_DATA_RO$$Basev2 状态机被“孤儿*/结尾的注释 ASSERT”卡死吞掉后续 sectionv3 加strip_trailing_comment_close()先剥*/再判断unknown directive: */v3 第一版把合法的多行注释闭合符*/也剥掉了v3 重写为完整注释感知状态机合法注释透传wrapper 无法执行Windows CRLF 污染 shebangtr -d \r 自检SKIPPING IMAGE SIGNING开发环境无签名路径非致命忽略本次改动完整总结一、GPIO 修改产品功能改动文件pinctrl.dtsiWSL 路径.../boot_images/boot/Settings/Soc/Aliso/Core/SocInfra/TLMM/pinctrl.dtsi改动内容把GPIO 150–153SSC_QUP_2 的 SSC_4–7从原配置改为Hi-Z高阻/浮空(GPIO_INPUT | GPIO_NO_PULL | GPIO_OUT_LOW | GPIO_PRG_YES) /* PIN 150 */ (GPIO_INPUT | GPIO_NO_PULL | GPIO_OUT_LOW | GPIO_PRG_YES) /* PIN 151 */ (GPIO_INPUT | GPIO_NO_PULL | GPIO_OUT_LOW | GPIO_PRG_YES) /* PIN 152 */ (GPIO_INPUT | GPIO_NO_PULL | GPIO_OUT_LOW | GPIO_PRG_YES) /* PIN 153 */关键区别原来 150–153 和 148–149 一样是GPIO_PRG_NO现在改为GPIO_PRG_YES程序可配置 Hi-Z/浮空。数值 0x151 INPUT(0x1) | NO_PULL(0x10) | OUT_LOW(0x40) | PRG_YES(0x100)。该配置编译进post-ddr dtb最终打入xbl_config.elf已反复验证源码 → dtb → ELF 三段链路全部确认 150–153 0x151。二、为了编译通过所做的修改这些是本地工具链替换带来的问题不是高通源码问题问题原因解决DevprogDASSERT 失败GNU LLD 链接器不支持 ARM armlink 的ASSERT()语法修改链接脚本去掉/改写 ASSERTGccBase.lds注释报错源码注释跨了 tokenGNU 语法解析不了调整注释写法CRLF 行尾问题从 Windows 拷文件导致行尾混乱统一用tr -d \r转 LFsectools 找不到/home/jc/bin/sectools不存在建软链指向 wrapper核心背景高通原版用 ARMarmlink编译原生支持-march、ASSERT()等语法。本地换成 GNU clang/LLDCLANG140LINUX 16.1.2后需要通过一个注释感知的 arm-link v3 wrapper来适配所以才会出现这些原版不该有的问题。三、启动失败问题本次重点修复现象烧写后 SBL1 加载完 APDP 后报Error code 9c001008 at boot_elf_driver.c Line 363。根因完整链条0x9C001008 BL_ERROR_GROUP_XBL_CONFIG | INITIALIZATION_ERROR—— SBL1 加载 xbl_config.elf 初始化失败构建日志出现SKIPPING IMAGE SIGNING签名被跳过buildconfig.json引用$SECTOOLSROOT/sectools_dir但/home/jc/bin/sectools_dir当时不存在→GenConfigImage.py的isdir检查失败 → 不签名而签名时pboot_gen_elf()elf_gen_tools.py才会补上头部 NULL 段 尾部 hash NULL 段并把e_phnum 2未签名版本只有 9 个 LOAD 段、没有 NULL 头段135604 字节→ SBL1 加载器初始化失败。修复永久修复建好缺失目录以后编译自动签名ln -sfn /pkg/sectools/v2/latest/Linux/sectools_dir /home/jc/bin/sectools_dir已确认软链存在且指向正确。手动重新签名本次产物得到可烧写文件大小 143544 字节11 段NULL 头 9 LOAD NULL hash 尾与已知可用版xbl_config_fp.elf结构完全一致post-ddr dtb 段中 GPIO 150–153 0x151Hi-Z确认保留已复制到D:\tmp\xbl_config.elfmd5653a3d14f12c51cf01b044589e27fd16可直接烧写。四、下次重新编译步骤前置/home/jc/bin/sectools_dir软链已建好无需再手动签名。在 Windows 打开D:\tmp2\run_build10.sh按需确认顶部路径当前为BOOT.MXF.2.2ROOT/home/jc/ar1/aliso-la-1-0_amss_standard_oem/BOOT.MXF.2.2在 WSL 执行bash /mnt/d/tmp2/run_build10.sh脚本会自动建/home/jc/py3bin/python软链→ python3.8、把 py3bin 加进 PATH、确保/home/jc/bin/sectools软链存在、然后跑python -u boot_tools/buildex.py -t Aliso -v LAA -r RELEASE完整日志写到D:\tmp2\xbl_build_run10.log。编译后校验可选但建议确认日志中 xbl_config 步骤没有SKIPPING IMAGE SIGNING检查产物程序头数readelf -l .../Build/AlisoLAA/xblconfig/auto_gen/elf_files/create_cli/xbl_config.elf应为11 段LOAD segments: 9NULL segments: 2产物路径.../boot_images/Build/AlisoLAA/xblconfig/auto_gen/elf_files/create_cli/xbl_config.elf如果是从 Windows 拷贝/编辑过任何 .dtsi/.py/.c 源文件再拷回 WSL务必先tr -d \r去掉 CR避免 CRLF 编译问题。现在就可以先用D:\tmp\xbl_config.elf已签名修复版重新烧写验证启动。 高通学习24--XBL（TODO）
下次只需一条wsl bash /mnt/d/tmp2/run_build10.sh。若环境被重置导致 wrapper 丢失先跑wsl bash /mnt/d/tmp2/install_armlink_v3.sh再编译。run_build10.s#!/bin/bash set -x ROOT/home/jc/ar1/aliso-la-1-0_amss_standard_oem/BOOT.MXF.2.2 PYBIN/home/jc/py3bin mkdir -p $PYBIN if [ -e $PYBIN/python ] || [ -L $PYBIN/python ]; then rm -f $PYBIN/python; fi ln -s /usr/bin/python3.8 $PYBIN/python export PATH$PYBIN:$PATH echo python now resolves to: $(which python) python --version cd $ROOT/boot_images if [ ! -e /home/jc/bin/sectools ] [ ! -L /home/jc/bin/sectools ]; then ln -s /home/jc/bin/sectools_wrapper /home/jc/bin/sectools fi ls -la /home/jc/bin/sectools python -u boot_tools/buildex.py -t Aliso -v LAA -r RELEASE /mnt/d/tmp2/xbl_build_run10.log 21 echo BUILD EXIT CODE: $?install_armlink_v3.sh#!/bin/bash # Install arm-link v3 (comment-aware ASSERT stripping) and verify against # both GccBase.lds (multi-line comments, no ASSERT) and generated DevPrgD.ld # (orphan trailing */ on ASSERT line multi-line ASSERT). set -e BIN/pkg/qct/software/llvm/release/arm/14.0.0/bin SRC/mnt/d/tmp2/new_arm-link_v3.sh ROOT/home/jc/ar1/aliso-la-1-0_amss_standard_oem/BOOT.MXF.2.2 echo backup current arm-link as arm-link.bak.v2 if [ -f $BIN/arm-link.bak.v2 ]; then echo arm-link.bak.v2 already exists, overwriting fi cp -f $BIN/arm-link $BIN/arm-link.bak.v2 echo install v3 (strip CR from Windows drive copy) tr -d \r $SRC /tmp/arm-link.v3.lf cp -f /tmp/arm-link.v3.lf $BIN/arm-link chmod x $BIN/arm-link echo verify line endings (must be ASCII text, LF only) file $BIN/arm-link if grep -q $\r $BIN/arm-link; then echo ERROR: CR still present in installed arm-link exit 1 else echo OK: no CR characters fi echo direct python test of v3 preprocess logic cat /tmp/preprocess_v3.py PYEOF import sys src, dst sys.argv[1], sys.argv[2] out [] in_comment False in_assert False def strip_trailing_comment_close(s): while s.rstrip().endswith(*/): s s.rstrip()[:-2].rstrip() return s for ln in open(src, r).read().splitlines(): s ln if in_assert: out.append(/* stripped ASSERT cont: s.strip() */) code strip_trailing_comment_close(s) if ); in code: in_assert False continue parts [] i 0 n len(s) while i n: if in_comment: j s.find(*/, i) if j -1: parts.append((comment, s[i:])) i n else: parts.append((comment, s[i:j 2])) i j 2 in_comment False else: j s.find(/*, i) if j -1: parts.append((code, s[i:])) i n else: parts.append((code, s[i:j])) parts.append((comment, s[j:j 2])) i j 2 in_comment True code_str .join(t for k, t in parts if k code) comments_str .join(t for k, t in parts if k comment) if ASSERT in code_str: code_c strip_trailing_comment_close(code_str) out.append(/* stripped ASSERT: code_c.strip() */) if comments_str: out.append(comments_str) if not code_c.rstrip().endswith();): in_assert True continue out.append(.join(t for k, t in parts)) open(dst, w).write(\n.join(out) \n) PYEOF echo --- Test 1: GccBase.lds (multi-line comments) --- GCC$ROOT/boot_images/edk2/BaseTools/Scripts/GccBase.lds python3.8 /tmp/preprocess_v3.py $GCC /tmp/GccBase.v3.test.ld sed -n 15,30p /tmp/GccBase.v3.test.ld echo ... echo --- verify no stray directives / balanced comments --- grep -n stripped orphan\|unknown /tmp/GccBase.v3.test.ld echo PROBLEM || echo OK: no orphan marks echo echo --- Test 2: generated DevPrgD.ld (ASSERT orphan */) --- LD$ROOT/boot_images/Build/AlisoLAA/DevprogD/RELEASE_CLANG140LINUX/AARCH64/DevPrgD.ld python3.8 /tmp/preprocess_v3.py $LD /tmp/DevPrgD.v3.test.ld echo --- lines 44-66 --- sed -n 44,66p /tmp/DevPrgD.v3.test.ld echo echo --- check Image\$\\\$DEVPRG_DATA_RO\\\$\\\$Base present --- grep -n DEVPRG_DATA_RO.*Base /tmp/DevPrgD.v3.test.ld || echo MISSING! echo DONE 问题原因这套构建工具链CLANG140LINUX实际指向的是 clang/LLD 16.1.2。EDK2 构建系统调用arm-link链接本应是 ARM 的 armlink但系统里安装的是一个把它翻译成 GNUld.lld的 wrapper 脚本。这个 wrapper 是问题根源因为ld.lld与 ARM 工具链行为不同构建脚本喂给它的参数和链接脚本内容它都处理不了。问题 1DevprogD 链接失败第一次 build 的硬错误报错ld.lld: error: /tmp/DevPrgD.ld.noassert.*.ld:60: symbol not found: Image$$DEVPRG_DATA_RO$$Base排查过程我先写了check_noassert.sh检查 wrapper 生成的中间脚本定位到根因。生成的DevPrgD.ld第 50 行是一条被注释掉的 ASSERT格式为ASSERT(...); */—— clang -E 预处理时把开头的/*剥掉了只留下孤儿的*/。v2 wrapper 的in_assert状态机逻辑是进入 ASSERT 后检查行尾是否以);结束来退出断言状态。但这一行以*/结尾而不是);导致in_assert一直卡在 True把后面紧跟的DEVPRG_DATA_RO段整段吞掉于是Image$$DEVPRG_DATA_RO$$Base符号缺失。解决重写为v3 注释感知 wrapperarm-link备份为arm-link.bak.v2。核心逻辑用strip_trailing_comment_close()先剥掉行尾孤儿*/再做);完整性判断 → 不再误吞后续 section。同时覆盖单行、多行第 107-108 行、带孤儿*/三种 ASSERT 形态。问题 2Core Sec.dll 链接失败修完问题 1 后暴露的下一个错误报错ld.lld: error: /tmp/GccBase.lds.noassert.651580.ld:23: unknown directive: */排查过程这发生在Core.dsc的 Sec 模块链接用的是 EDK2 标准脚本GccBase.lds。关键发现GccBase.lds里有真实的多行注释第 18 行/*打开第 23 行*/闭合里面没有 ASSERT。我 v3 第一版的“孤儿*/处理”写得太激进只要检测到*/就剥掉。结果把合法的闭合*/也剥了留下悬空的/*导致第 23 行出现unknown directive: */。解决把 v3 重写为完整的注释感知状态机用标志位in_comment跟踪/* */块注释含多行跨行合法的注释原样透传、保持顺序只在非注释代码中剥离ASSERT(...)分别用GccBase.lds验证注释完整保留和生成的DevPrgD.ld验证 ASSERT 剥离 DEVPRG_DATA_RO保留做了单元验证通过后才重新跑 build。问题 3Windows 换行符CRLF破坏 wrapper现象从 Windows 盘D:\tmp2拷贝 wrapper 到 WSL 工具链目录后脚本无法执行shebang 被\r污染。解决安装时统一用tr -d \r去除 CR安装脚本里还带自检grep -q $\r检查并报错。这是后续所有脚本安装的固定套路。问题 4xbl_config 签名警告非致命现象构建日志出现No Sectools Folder provided. SKIPPING IMAGE SIGNING和ERROR: Could not generate Signed XBL Config。判定非致命—— 构建继续执行并最终报告全部 8 个镜像成功含 xbl_config。属于开发环境签名路径配置为空的行为走的是 unsigned 路径。不影响产物无需修复。最终结果修复完问题 12即 v3 注释感知 wrapper后run10完整编译成功0:36mins 产出全部 8 个镜像XBL_S、XBL_RAMDUMP、UEFI、XBL_S_DEVPRG_NS、JtagProgrammer、xbl_config、SHRM、ImageFv。关键经验总结报错根因修复symbol not found: Image$$DEVPRG_DATA_RO$$Basev2 状态机被“孤儿*/结尾的注释 ASSERT”卡死吞掉后续 sectionv3 加strip_trailing_comment_close()先剥*/再判断unknown directive: */v3 第一版把合法的多行注释闭合符*/也剥掉了v3 重写为完整注释感知状态机合法注释透传wrapper 无法执行Windows CRLF 污染 shebangtr -d \r 自检SKIPPING IMAGE SIGNING开发环境无签名路径非致命忽略本次改动完整总结一、GPIO 修改产品功能改动文件pinctrl.dtsiWSL 路径.../boot_images/boot/Settings/Soc/Aliso/Core/SocInfra/TLMM/pinctrl.dtsi改动内容把GPIO 150–153SSC_QUP_2 的 SSC_4–7从原配置改为Hi-Z高阻/浮空(GPIO_INPUT | GPIO_NO_PULL | GPIO_OUT_LOW | GPIO_PRG_YES) /* PIN 150 */ (GPIO_INPUT | GPIO_NO_PULL | GPIO_OUT_LOW | GPIO_PRG_YES) /* PIN 151 */ (GPIO_INPUT | GPIO_NO_PULL | GPIO_OUT_LOW | GPIO_PRG_YES) /* PIN 152 */ (GPIO_INPUT | GPIO_NO_PULL | GPIO_OUT_LOW | GPIO_PRG_YES) /* PIN 153 */关键区别原来 150–153 和 148–149 一样是GPIO_PRG_NO现在改为GPIO_PRG_YES程序可配置 Hi-Z/浮空。数值 0x151 INPUT(0x1) | NO_PULL(0x10) | OUT_LOW(0x40) | PRG_YES(0x100)。该配置编译进post-ddr dtb最终打入xbl_config.elf已反复验证源码 → dtb → ELF 三段链路全部确认 150–153 0x151。二、为了编译通过所做的修改这些是本地工具链替换带来的问题不是高通源码问题问题原因解决DevprogDASSERT 失败GNU LLD 链接器不支持 ARM armlink 的ASSERT()语法修改链接脚本去掉/改写 ASSERTGccBase.lds注释报错源码注释跨了 tokenGNU 语法解析不了调整注释写法CRLF 行尾问题从 Windows 拷文件导致行尾混乱统一用tr -d \r转 LFsectools 找不到/home/jc/bin/sectools不存在建软链指向 wrapper核心背景高通原版用 ARMarmlink编译原生支持-march、ASSERT()等语法。本地换成 GNU clang/LLDCLANG140LINUX 16.1.2后需要通过一个注释感知的 arm-link v3 wrapper来适配所以才会出现这些原版不该有的问题。三、启动失败问题本次重点修复现象烧写后 SBL1 加载完 APDP 后报Error code 9c001008 at boot_elf_driver.c Line 363。根因完整链条0x9C001008 BL_ERROR_GROUP_XBL_CONFIG | INITIALIZATION_ERROR—— SBL1 加载 xbl_config.elf 初始化失败构建日志出现SKIPPING IMAGE SIGNING签名被跳过buildconfig.json引用$SECTOOLSROOT/sectools_dir但/home/jc/bin/sectools_dir当时不存在→GenConfigImage.py的isdir检查失败 → 不签名而签名时pboot_gen_elf()elf_gen_tools.py才会补上头部 NULL 段 尾部 hash NULL 段并把e_phnum 2未签名版本只有 9 个 LOAD 段、没有 NULL 头段135604 字节→ SBL1 加载器初始化失败。修复永久修复建好缺失目录以后编译自动签名ln -sfn /pkg/sectools/v2/latest/Linux/sectools_dir /home/jc/bin/sectools_dir已确认软链存在且指向正确。手动重新签名本次产物得到可烧写文件大小 143544 字节11 段NULL 头 9 LOAD NULL hash 尾与已知可用版xbl_config_fp.elf结构完全一致post-ddr dtb 段中 GPIO 150–153 0x151Hi-Z确认保留已复制到D:\tmp\xbl_config.elfmd5653a3d14f12c51cf01b044589e27fd16可直接烧写。四、下次重新编译步骤前置/home/jc/bin/sectools_dir软链已建好无需再手动签名。在 Windows 打开D:\tmp2\run_build10.sh按需确认顶部路径当前为BOOT.MXF.2.2ROOT/home/jc/ar1/aliso-la-1-0_amss_standard_oem/BOOT.MXF.2.2在 WSL 执行bash /mnt/d/tmp2/run_build10.sh脚本会自动建/home/jc/py3bin/python软链→ python3.8、把 py3bin 加进 PATH、确保/home/jc/bin/sectools软链存在、然后跑python -u boot_tools/buildex.py -t Aliso -v LAA -r RELEASE完整日志写到D:\tmp2\xbl_build_run10.log。编译后校验可选但建议确认日志中 xbl_config 步骤没有SKIPPING IMAGE SIGNING检查产物程序头数readelf -l .../Build/AlisoLAA/xblconfig/auto_gen/elf_files/create_cli/xbl_config.elf应为11 段LOAD segments: 9NULL segments: 2产物路径.../boot_images/Build/AlisoLAA/xblconfig/auto_gen/elf_files/create_cli/xbl_config.elf如果是从 Windows 拷贝/编辑过任何 .dtsi/.py/.c 源文件再拷回 WSL务必先tr -d \r去掉 CR避免 CRLF 编译问题。现在就可以先用D:\tmp\xbl_config.elf已签名修复版重新烧写验证启动。