feat(ostool): 支持 ELF/BIN FIT 生成

[MRNIU]

支持生成包含 ELF 或 BIN 的 FIT 镜像；选择 BIN 时自动转换，无需手工处理。

• 可选择 Linux 或 ELF OS，指定设备树和输出路径。
• ELF OS 模式需要显式指定安全的加载地址，入口指向 ELF 文件头；目标 U-Boot 需启用 CONFIG_BOOTM_ELF。
• BIN 地址支持自动获取或显式指定；地址映射不明确时要求显式填写，支持 LoongArch Linux 镜像头入口换算。
• 现有 U-Boot 默认生成行为保持兼容。

本 PR 提供内部生成能力，暂未新增命令或用户配置入口；入口由 PR 3 接入。

依赖 #193，仅包含其上的 FIT 增量。

[mai-team-app]

审查结论

本 PR 新增 crate-private FitConfig 与 ELF 元数据解析，支持生成 ELF/BIN FIT、自动或显式设置 load/entry、可选 FDT 和输出路径；旧的 Linux U-Boot FIT 生成路径仍保留，且 PR 明确暂不新增 CLI 或用户配置入口。变更主要影响后续 boot-prepare 调用方，不改变当前默认 U-Boot 流程。

验证与上下文

• GitHub check check (stable, x86_64-unknown-linux-gnu) 在目标 head f2bcdaaa73422520483acd8ba3b8fc1f80f91a41 上成功。
• git diff --check origin/main...HEAD 通过，HEAD 与审查目标一致。
• 本地 cargo fmt --check、cargo clippy --manifest-path ostool/Cargo.toml --all-features -- -D warnings 和 cargo test --manifest-path ostool/Cargo.toml --all-features 均因审查环境没有 cargo（退出码 127）未能运行；这不是 PR 代码导致的失败。
• 当前 PR 没有既有 review、review comment 或 issue comment 需要处理。相近的 PR #193 是本 PR 声明的依赖，相关的 FIT/boot 边界重构 PR #123 仅作为实现模式参考。

需要修复的问题

1. 配置化 BIN 路径没有复用 LoongArch Linux 镜像头部的入口地址换算，见行内评论。对于带 MZ 头的原始 LoongArch Linux BIN，FIT entry 必须按镜像头部相对偏移计算。
2. BIN 自动 entry 直接使用 ELF e_entry，但 BIN load base 按 PT_LOAD.p_paddr/section LMA 推导；VMA 与 LMA 不同的合法 ELF 会被加载到一个地址却跳到另一个地址，见行内评论。

这两项都会导致生成的 FIT 在目标设备上无法正确启动。当前新增测试覆盖了地址解析的简单合成数据和旧生成路径，但没有覆盖 configured BIN/LoongArch 或 VMA/LMA 不同的 ELF；实际 U-Boot/硬件启动也未在本次环境验证。

Powered by gpt-5.6-luna

[ZR233]

当前 PR 只增加 crate 内部的 FIT 配置和生成入口；.build.toml、.uboot.toml 以及既有 U-Boot runner 的配置解析与调用点均未改动，旧配置仍走原来的 Linux FIT 生成路径。CI 通过证明了现有检查通过，但新增的 generate_configured_fit 尚未被用户入口调用，不能据此认定 ELF/BIN 新路径已经可启动。

请先修复下面两处地址语义问题，并增加从真实 ELF 生成 FIT、检查 FIT 属性与 payload 的回归验证。当前已有审查指出 LoongArch 及 BIN entry 的问题；这里的两处是额外发现。

后续接入用户配置时，建议在父配置使用可选字段，以“未填写继续走旧 generate_fit_image、显式填写才使用新生成路径”为语义。不要仅凭 FitConfig 的字段默认值切换旧流程：Auto 地址和空 FDT 可能覆盖旧的 kernel_load_addr、dtb_file。若字段放入 .uboot.toml，还需同步 UbootConfigWire 的反序列化；若板卡流程也要使用，需同步 .board.toml 到 UbootConfig 的映射。

[mai-team-app]

审查结论

REQUEST_CHANGES。本 PR 在 base 之上新增 crate-private FitConfig（ostool/src/boot/fit_config.rs）、给 ElfMetadata 增加 load_sections、新增 generate_configured_fit，并把 FIT 写文件拆成 write_fit_image，使后续入口能按 ELF 元数据推导 load/entry 并生成 ELF 或 BIN payload 的 FIT；旧的 generate_fit_image（U-Boot Linux 路径）行为未变。

影响面

• 旧路径未变：generate_fit_image 仍是 os = "linux"，仍对 LoongArch 调 resolve_kernel_entry_addr，ostool/src/run/uboot.rs:1327 的调用点未改。
• 新增的 generate_configured_fit 与 fit_config 模块本 PR 内仍是 #[allow(dead_code)]，没有调用方，所以本 PR 不改变任何现有用户可见行为；真正受影响的是“FIT load/entry/os 如何被 U-Boot 解释”这一契约语义，即下面三个行内问题。

验证

• CI：head f33dbd5386f42759e79aff110ebb541bf9250be3 的 check (stable, x86_64-unknown-linux-gnu) 为 success（2026-10-09 完成），因此 fmt/clippy/build/test 在该 head 上是通过的。
• 本地：git diff --check origin/main...HEAD 通过，HEAD 与审查目标一致。本审查环境没有 cargo（which cargo 未找到，退出码 127），未能本地复跑 cargo fmt --check、clippy、cargo test；这不是本 PR 导致的失败，但也意味着新增地址推导只由 CI 中的合成单测覆盖。未做任何硬件/U-Boot 实机启动验证。

需要修复（阻塞）

1. F-001：os = "elf" 的 FIT entry 语义不成立（fit_config.rs:24，行内）。
2. F-002：BIN 的 load 优先采用 __executable_start（VMA）（fit_config.rs:83，行内）。
3. F-003：BIN 的 entry 直接采用 e_entry，与 LMA 推导的 load 不在同一地址空间（fit_config.rs:92，行内）。

上一轮 review 的处理情况

两条既有 review 均为 CHANGES_REQUESTED（提交于 f2bcdaa），其行内评论经 GitHub 迁移后仍锚定当前 head，当前 head 既未修复也未回复（f2bcdaa、f33dbd5 两个提交都只是与 main 的合并冲突同步）：

• mai-team-app[bot]：LoongArch 入口换算被绕过（fit.rs:164）；BIN Auto entry 用 e_entry（fit_config.rs:92）。第二条技术成立，保留为 F-003；第一条按 F-004 记为 advisory，需要作者确认派生 BIN 是否仍带历史 MZ 头。
• ZR233：[P1] bootelf 需要 ELF 头地址而不是 e_entry，以及 os = "elf" 与 format = "bin" 组合问题；[P2] __executable_start 是 VMA 却用于 BIN load。两条我都按 U-Boot 源码复核后确认成立（do_bootm_elf() → bootelf(bmi->images->ep, ...)，images->ep 来自 FIT entry；boot/image.c 的 uimage_os[] 中 {IH_OS_ELF, "elf"} 被 #ifdef CONFIG_CMD_ELF 包裹），分别保留为 F-001 与 F-002。唯一需要修正的是“os = "elf" 不被 U-Boot 支持”的部分：IH_OS_ELF/"elf" 确实存在，但依赖目标 U-Boot 开启 CONFIG_CMD_ELF，并且必须给出正确的 entry。
• ZR233 的 review body 还要求补真实 ELF 的回归验证，当前仍未提供（见下）。

遗留风险与测试缺口

• F-004（advisory）：配置化路径没有复用 resolve_kernel_entry_addr，两条路径对“以 MZ 开头的二进制 payload”的 entry 语义可能不一致；请确认派生 BIN 是否仍带该头部，否则应复用同一换算或说明原因。
• F-005（advisory）：新增路径没有调用方也没有端到端测试；fit_config.rs 的合成夹具恰好把 executable_start 设为 None、把 entry 设为按 LMA 推导出的值，正好绕开了 F-002/F-003 的分支。建议在接线 PR 前补“真实 ELF → 生成 FIT → 断言 kernel 的 os/load/entry 与 payload”的测试，并明确 format/os 的合法组合矩阵。
• 复核后未发现问题的地方：NamedTempFile + persist 的输出替换、输出与输入同路径/符号链接的保护、validate_elf_load_data 的溢出与截断检查、section_lma() 与 objcopy/BFD 的 LMA 规则一致性、toml/json 往返测试（CI 覆盖）、以及旧路径的兼容性。

相近工作

本 PR 声明依赖 #193；相关既有改动为 FIT 边界重构 #122/#123（其中已说明 os = "elf" 应作为独立功能处理）与 FIT 修复 #194/#201/#207。未发现与本 PR 重复的开放 PR。

Powered by deepseek-flash

[mai-team-app]

审查结论

REQUEST_CHANGES。本 head 修掉了上一轮的三个阻塞项中的两个半，地址语义整体比 f33dbd5 明显更严谨；但 FitFormat::Elf 的自动 load 仍沿用“优先取 VMA 符号”的旧写法，与本次刚在 BIN 分支建立的规则自相矛盾，会在 VMA≠LMA 或首个 PT_LOAD 偏移非零时生成放错位置的 ELF payload，属于同一类会“生成成功但启动不了”的问题，建议一并收敛。

本 PR 做了什么、影响面

• 新增 crate-private FitConfig/FitAddress/FitFormat/FitOs（ostool/src/boot/fit_config.rs）与 ElfMetadata.load_sections，新增内部入口 generate_configured_fit，并把写 FIT 的部分拆成 write_fit_image；write_fit_image 接受 os，因此旧路径 generate_fit_image 依然固定写 os = "linux"。
• 影响面：generate_configured_fit 与 fit_config 模块在本 PR 内仍是 #[allow(dead_code)]（ostool/src/boot/mod.rs），用户入口、.uboot.toml/.board.toml 解析和 ostool/src/run/uboot.rs:1327 的调用点都未改，所以本 PR 不改变现有用户可见行为；真正被固定下来的是“FIT 的 load/entry 如何按 ELF 元数据推导”这一契约，供 PR 3 接入时依赖。旧路径行为等价（仅 build_default_fit_config → build_fit_config 加参、测试同步更新）。

上一轮 review 的处理情况

• mai-team-app[bot]（F-001）：os = "elf" 的 entry 语义 → 已修。resolve_entry 现在对 FitOs::Elf 返回 load，并拒绝与 load 不一致的显式 entry；同时 resolve_load 拒绝 os = elf + format = bin。与 U-Boot do_bootm_elf() → bootelf() 需要“内存中 ELF 头地址”的语义一致。
• mai-team-app[bot]（F-002）：BIN load 优先用 __executable_start（VMA） → 已修。现在先用 bin_load_base()（按 section LMA 推导），符号只在与该基址一致时被接受，冲突则报错要求显式 load。
• mai-team-app[bot]（F-003）：BIN entry 直接用 e_entry（VMA） → 已修。bin_entry() 现在要求 load == bin_load_base()，且 entry 必须落在某个 LMA==VMA 的 file-backed section 内，否则要求显式 entry。
• mai-team-app[bot]（F-004，advisory）：LoongArch 入口换算被绕过 → 已修。generate_configured_fit 对 LoongArch64 + BIN + os = linux + payload 带 MZ 头且 entry = auto 时复用 resolve_kernel_entry_addr，与旧路径同一公式。
• ZR233 的两条（bootelf 需要 ELF 头地址、__executable_start 是 VMA）都已按上面两点修复；其 review body 里“补真实 ELF 生成 FIT 的回归验证”仍未落地（见下 F-103）。

验证

• CI：head 8076e5d40c1e32c148c5c2b6d4daad73896f683d 的 check (stable, x86_64-unknown-linux-gnu) 为 success（2026-10-09T07:06:45Z 完成，check run 113708984995），因此该 head 的 cargo fmt/clippy/build/test 在 CI 环境是通过的；未发现与本 PR 相关的失败 CI。
• 本地：git rev-parse HEAD = 8076e5d…、git rev-parse origin/main = 787943d…，工作区干净，与审查目标一致；git diff --check origin/main...HEAD 通过。本审查环境没有 cargo（/bin/sh: 1: cargo: not found，退出码 127），cargo fmt --check、cargo clippy --manifest-path ostool/Cargo.toml --all-features -- -D warnings、cargo test --manifest-path ostool/Cargo.toml --all-features 均未能运行，这不是本 PR 导致的失败。未做任何 U-Boot/硬件启动验证，以下地址语义判断基于 U-Boot bootm（FIT load 为 payload 落点、entry 为跳转地址）与 objcopy -O binary 的 LMA 布局规则。

需要修复（阻塞）

1. F-101（ostool/src/boot/fit_config.rs:101-104，行内）：FitFormat::Elf + FitAddress::Auto 仍优先采用 VMA 符号 __executable_start，只在符号缺失时退回 elf_load_base()（= p_paddr - p_offset）。ELF payload 的 load 必须是“文件首字节地址”，而符号是 VMA；与本次 BIN 分支刚建立的规则不一致。详见行内评论。

遗留风险与建议（均非阻塞）

• F-102（advisory）：LoongArch 的 entry 换算在 ostool/src/boot/fit.rs:145-153 由调用方完成，FitConfig::resolve_entry() 的返回值会被按 payload 字节静默覆盖，“Auto entry”的解析不再有唯一入口；建议收敛到一个函数，避免后续接入时两处不一致。
• F-103（advisory）：仍无“真实 ELF → 生成 FIT → 断言 os/load/entry/payload”的端到端回归；现有夹具把 executable_start 设为 None（ostool/src/boot/fit_config.rs:291），恰好跳过 F-101 所在分支。
• F-104（advisory）：write_fit_image 从参数取 kernel_entry_addr、却从 input.kernel_load_addr 取 load，并忽略 input.kernel_entry_addr；建议统一来源或加断言。
• F-105（advisory）：新写出路径用 NamedTempFile + persist，会把 image.fit 权限固定为 0600（旧 fs::write 路径遵循 umask）；请确认下游（TFTP/ostool-server/其它用户）是否需要可读权限。
• 复核后未发现问题的地方：os = elf/format = bin 组合拒绝、validate_elf_load_data 的截断与溢出检查、输出与输入同路径/符号链接的保护（含 rename 不破坏硬链接的说明）、bin_load_base/section_lma 与 objcopy LMA 规则的一致性、toml/json 往返测试、以及旧 U-Boot Linux 路径的兼容性。

相近工作

本 PR 声明依赖 #193；相关既有工作为 FIT 边界重构 #122/#123、FIT 修复 #194/#201/#207。未发现与本 PR 重复的开放 PR。

Powered by gpt-5.6-luna

Powered by deepseek-flash

[mai-team-app]

审查结论

COMMENT（未发现阻塞问题）：在 head e7b566e 上未发现阻塞性缺陷——没有 fmt/clippy/test 失败，也没有安全、数据丢失、panic、竞态或行为回退类问题。上一轮唯一的阻塞项（format = "elf" 的 Auto load 仍优先采用 VMA 符号 __executable_start，见 c926f0c0 的 F-101）已在本 head 修复，且比建议更完整：符号只在与 ELF 容器基址一致时才被接受，同时 FitAddress::Auto 的 entry 统一改走 direct_entry()，会校验“entry 落在 LMA==VMA 的 file-backed section 内”。下面 4 条均为 advisory，可作为合并前或接线 PR 中的跟进项。

本 PR 做了什么

• 新增 ostool/src/boot/fit_config.rs：crate-private FitConfig/FitFormat/FitOs/FitAddress/FitFdt，以及地址推导 resolve_load()/resolve_entry() 与 bin_load_base()/elf_load_base()/section_lma()。
• ostool/src/artifact/elf_metadata.rs：新增 LoadSection 与 load_sections（SHF_ALLOC、非 SHT_NOBITS、file_range() 存在且 size≠0）。
• ostool/src/boot/fit.rs：新增内部入口 generate_configured_fit() 与 validate_elf_load_data()；写文件部分抽成 write_fit_image(..., os)；旧 generate_fit_image() 仍固定 os = "linux"、仍对 LoongArch 镜像头调用 resolve_kernel_entry_addr()，最终 entry 统一经 FitInput.kernel_entry_addr 传递。
• ostool/src/boot/mod.rs：注册 fit_config 模块并标注 #[allow(dead_code)]（用户入口由后续 PR 接入）。

影响面

• 旧路径等价：build_default_fit_config → build_fit_config(..., FitOs::Linux) 只是加参数；ostool/src/run/uboot.rs:1327 的调用点、.uboot.toml/.board.toml 解析与用户可见行为均未改。
• 本 PR 内 generate_configured_fit 与 fit_config 没有调用方，改动完全内部化；真正被固定下来的是“FIT load/entry 如何由 ELF 元数据推导”这一契约，供下一个接线 PR 依赖。
• 复核后未发现问题的部分：os = "elf" 必须 format = "elf" 且 entry 必须等于 load（与 U-Boot do_bootm_elf() → bootelf() 需要内存中 ELF 头地址一致）；os = "elf" 的 Auto load 明确拒绝并要求显式 staging 地址；BIN/ELF 两种 payload 的 load 都以实际落盘布局为准，符号地址冲突时要求显式指定；validate_elf_load_data() 的文件范围/溢出检查；输出用 NamedTempFile + persist 原子替换，hard link 输入不会被截断（相对旧 fs::write 是改进），输入别名检查覆盖 source/runtime ELF 与 FDT；Builder::permissions(0o666) 在 unix 上受 umask 收窄（tempfile 文档：permissions & !umask），新建输出与 fs::write 语义一致、已有输出保留原权限；生产路径无 unwrap()/expect()/unsafe；BIN 派生使用独立 tempdir()，成功/失败路径都会清理。

验证

• CI：head e7b566e 的 check (stable, x86_64-unknown-linux-gnu) 为 success（check run 113718682003，2026-10-09T07:37:57Z 完成），该工作流包含 cargo fmt --all -- --check、cargo clippy、cargo build、cargo test。未发现与本 PR 相关的失败 CI。
• 本地：git rev-parse HEAD = e7b566e…、git rev-parse origin/main = 787943d…，工作区干净，git diff --check origin/main...HEAD 通过。本审查环境没有 cargo（which cargo 未找到，退出码 127），cargo fmt --check / cargo clippy --all-features -- -D warnings / cargo test --all-features 未能本地复跑；这不是本 PR 导致的失败。
• 未做 U-Boot/硬件实机启动验证。

上一轮 review 的处理情况

• 3f79b038（F-001/F-002/F-003）与 ZR233 的 [P1]/[P2]：均已修复——os = "elf" 的 entry 语义、BIN load 按 section LMA 推导、BIN entry 与 load 落在同一地址空间。
• c926f0c0（F-101，阻塞）：已修复（elf_load_base() 优先，符号不一致则报错要求显式 load）。
• c926f0c0 的 F-104（write_fit_image 的 entry 参数与 input.kernel_entry_addr 来源不一致）与 F-105（NamedTempFile 把输出固定为 0600）：本 head 一并修掉。
• ZR233 的 review body 仍要求“真实 ELF → 生成 FIT → 断言属性/payload”的回归验证，本 head 未提供（见 F-201；提交信息已记录人工验收，按 /project/repo/AGENTS.md“通过测试或记录过的手动验证覆盖”有人工依据，故不作为阻塞）。

遗留风险与测试缺口（均非阻塞，对应行内评论）

1. F-201（无端到端回归，body-only）：generate_configured_fit/fit_config 在本 PR 内无调用方，覆盖仅靠合成 ElfMetadata 夹具与 build_fit_config 单测；建议在接线 PR 前补“真实 ELF（CI 已装 llvm-objcopy/cargo-binutils）→ 生成 FIT → 断言 os/load/entry 与 payload”的用例，至少覆盖 format=bin / format=elf / os=elf 三个分支。
2. F-202（entry 策略两处解析，fit.rs:146-155）：LoongArch 镜像头换算内联在生成入口，FitConfig::resolve_entry() 在该分支不被调用，也跳过 Bin 的落点校验。
3. F-203（ELF 容器 Auto load 偏严，fit_config.rs:101-112）：elf_load_base() 要求所有 file-backed PT_LOAD 共享同一 p_paddr - p_offset，否则要求显式 load（fail-closed，但带 gap 的真实内核 ELF 基本无法用 Auto）。
4. F-204（fit_config.rs:144-161）：format = "elf" + 默认 os = "linux" 下只校验 entry 所在 section 的 LMA==VMA，其余 section 的 VMA≠LMA 不会被拒绝。

相近工作

本 PR 声明依赖 #193；相关既有改动为 FIT 边界重构 #122/#123（其结论已声明“os = "elf" 应作为独立功能处理”）、boot readiness #129、以及 FIT 修复 #194/#201/#207。未发现与本 PR 重复的开放 PR。

Powered by deepseek-flash

[mai-team-app]

审查结论

COMMENT（未发现阻塞问题）。 本 head ecfaef5 相对上一轮已审的 e7b566e 只多一个小提交（refactor(ostool): 精简 FIT 输入读取与成功日志，仅 ostool/src/boot/fit.rs，+24/-15）：把“source ELF 与 runtime ELF 同路径”时改写为复用已读字节，并把 FIT image ok 日志从 write_fit_image 移到两个生成入口。地址解析、FitConfig 与旧 U-Boot 路径均未改动，因此上一轮结论继续成立：无阻塞问题，剩余 3 条既有 advisory 仍然成立。

本 head 的具体改动与评价

1. ostool/src/boot/fit.rs:81-100：prepared.source_elf() == prepared.elf() 时直接复用 source_data，路径不同时保留 arch/entry/load_segments/load_sections 的完整一致性校验。prepare_runtime_artifacts() 会对输入 ELF 做 canonicalize（ostool/src/artifact/runtime.rs:90），所以同路径判断在两者确为同一文件时可靠；行为等价，省掉一次 ELF 读取。
2. ostool/src/boot/fit.rs:217、ostool/src/boot/fit.rs:280-282：成功日志移出 write_fit_image，改为在最终输出 persist 成功之后由调用入口记录，配置化路径不再显示临时文件路径。这修掉了此前“写到临时文件就报告成功、且打印临时路径”的问题。

影响面

• 旧路径等价：generate_fit_image 仍固定 os = linux、仍对 LoongArch 调 resolve_kernel_entry_addr；ostool/src/run/uboot.rs:1327 的调用点、.uboot.toml/.board.toml 解析和用户可见行为均未改。
• generate_configured_fit 与 fit_config 模块在本 PR 内仍无调用方（ostool/src/boot/mod.rs:6-7），改动完全内部化；被固定下来的仍是“FIT load/entry 如何由 ELF 元数据推导”这一契约，供接线 PR 依赖。

验证

• CI：head ecfaef5 的 check (stable, x86_64-unknown-linux-gnu) 为 success（check run 116208233208，2026-10-15T02:12:49Z 完成），该工作流包含 cargo fmt --all -- --check、cargo clippy、cargo build、cargo test。未发现与本 PR 相关的失败 CI。
• 本地：git rev-parse HEAD = ecfaef5…、git rev-parse origin/main = 787943d…、工作区干净、git diff --check origin/main...HEAD 通过。本审查环境没有 Rust 工具链（cargo/rustc/objcopy/readelf 均不存在），cargo fmt --check、cargo clippy、cargo test 未能本地复跑；这不是本 PR 导致的失败，也意味着地址推导目前只由 CI 中的合成单测覆盖。未做任何 U-Boot/硬件启动验证。

上一轮 review 的处理情况

• F-001/F-002/F-003 与 ZR233 的 [P1]/[P2]：均在 8076e5d 修复（os = "elf" 的 entry 语义、BIN load 按 section LMA 推导、BIN entry 与 load 同地址空间），本 head 未回退。
• c926f0c0 的 F-101（阻塞）已修复；F-104（entry 参数来源不一致）与 F-105（输出权限）也已修复。
• ZR233 要求的“真实 ELF → 生成 FIT → 断言属性/payload”回归仍缺失（见 F-301）：ecfaef5 的提交信息记录了本地人工验收（同路径/独立 runtime ELF、写入失败无成功日志），按 /project/repo/AGENTS.md“通过测试或记录过的手动验证覆盖”可以接受，因此不阻塞。

遗留问题（均非阻塞）

1. F-301（advisory，ostool/src/boot/fit.rs:81，行内）：本 head 新增的同路径分支与整个 generate_configured_fit 没有自动化测试覆盖，建议接线前补真实 ELF 的端到端回归。
2. F-302（advisory，ostool/src/boot/fit.rs:153-160，body-only；同一位置的既有行内评论 4227846823 已锚定本 head）：LoongArch MZ 镜像头的 entry 换算内联在生成入口，FitAddress::Auto 有两个解析点，并绕过 resolve_entry() 对 BIN 的 entry 校验；建议把 payload 相关换算收敛进 FitConfig。
3. F-303（advisory，ostool/src/boot/fit_config.rs:101-112，body-only；既有行内评论 4227846828）：elf_load_base() 要求所有 file-backed PT_LOAD 共享同一 p_paddr - p_offset，fail-closed 但偏严，带 gap 的内核 ELF 只能显式 load。
4. F-304（advisory，ostool/src/boot/fit_config.rs:144-168，body-only；既有行内评论 4227846833）：direct_entry() 只校验 entry 所在 section 的 LMA == VMA；format = "elf" + 默认 os = "linux" 下其余段若 VMA≠LMA 仍会生成成功。
5. 复核后未发现问题的地方：NamedTempFile + persist 的原子替换与权限保留（新输出走 umask、已有输出保留原权限）、输出与输入别名/硬链接保护、validate_elf_load_data() 的截断与溢出检查、section_lma() 与 objcopy/BFD LMA 规则的一致性、toml/json 往返测试、以及旧 U-Boot Linux 路径的兼容性。

相近工作

本 PR 声明依赖 #193；相关既有工作为 FIT 边界重构 #122/#123、boot readiness #129、FIT 修复 #194/#201/#207。未发现与本 PR 重复的开放 PR。

Powered by deepseek-flash

[mai-team-app]

审查结论

COMMENT（未发现阻塞问题）。 本 head 57dab0c 相对上一轮已审的 ecfaef5 只有一个提交（fix(ostool): 明确 FIT 自动地址推导的诊断边界），内容仅为 ostool/src/boot/fit_config.rs 的注释与错误文案调整（direct_entry() 注释、elf_load_base() 的冲突诊断文案、first_segment/first 变量拆分），无逻辑变化。因此上一轮（ecfaef5，review 5527255778）“无阻塞问题”的结论继续成立；本轮在此基础上新增 1 条 advisory（诊断归属），既有 4 条 advisory 仍成立。

本 PR 做了什么、影响面

• 新增 ostool/src/boot/fit_config.rs：crate-private FitConfig/FitFormat/FitOs/FitAddress/FitFdt，以及 resolve_load()/resolve_entry()/bin_load_base()/elf_load_base()/section_lma() 地址推导。
• ostool/src/artifact/elf_metadata.rs：新增 LoadSection 与 load_sections（SHF_ALLOC、非 SHT_NOBITS、file_range() 存在且 size≠0）。
• ostool/src/boot/fit.rs：新增内部入口 generate_configured_fit() 与 validate_elf_load_data()，把写文件拆为 write_fit_image(..., os)；旧 generate_fit_image() 语义不变（仍固定 os = "linux"，仍对 LoongArch 调用 resolve_kernel_entry_addr()，ostool/src/run/uboot.rs:1327 调用点未改）。
• ostool/src/boot/mod.rs：注册 fit_config 模块并保留 #[allow(dead_code)]（用户入口由后续 PR 接入）。

影响面：generate_configured_fit 与 fit_config 在本 PR 内仍无调用方，.uboot.toml/.board.toml 解析与用户可见行为均未改动，所以本 PR 不改变现有用户可见行为，属于完全内部化的改动；真正被固定下来的是“FIT load/entry 如何由 ELF 元数据推导”这一契约，供接线 PR 依赖。

验证

• CI：head 57dab0c7bbda0ec3b580c25374a4fe706058b504 的 check (stable, x86_64-unknown-linux-gnu) 为 success（check run 116216269135，2026-10-15T02:40:33Z 完成）；该工作流包含 cargo fmt --all -- --check、cargo clippy、cargo build、cargo test。未发现与本 PR 相关的失败 CI。
• 本地：git rev-parse HEAD = 57dab0c…（与审查目标一致）、git rev-parse origin/main = 787943d…，工作区干净，git diff --check origin/main...HEAD 通过。本审查环境没有 Rust 工具链（which cargo、which rustc 均未找到），cargo fmt --check、cargo clippy --manifest-path ostool/Cargo.toml --all-features -- -D warnings、cargo test --manifest-path ostool/Cargo.toml --all-features 未能本地复跑；这不是本 PR 导致的失败。
• 未做 U-Boot/硬件实机启动验证。section_lma()/bin_load_base() 与 objcopy -O binary 的 LMA 布局一致性本轮仅做代码复核（环境无 llvm-objcopy/cargo-binutils）。

上一轮 review 的处理情况

• 3f79b038（F-001/F-002/F-003）与 ZR233 的 [P1]/[P2]：已在 8076e5d 修复——os = "elf" 的 entry 语义改为等于 payload load，并拒绝与 load 不一致的显式 entry；BIN load 改为按 section LMA 推导、符号仅在与之一致时被接受；BIN entry 要求落在 LMA == VMA 的 file-backed section 内。
• c926f0c0 的 F-101（阻塞）已在 e7b566e 修复；其 F-104（entry 参数来源不一致）、F-105（输出权限）同期修掉。
• fit.rs:81（评论 4278335719）、fit.rs:153（4227846823）、fit_config.rs:102（4227846828）、fit_config.rs:155（4227846833）四处既有行内评论在本 head 未回复、未改动，技术判断仍然成立；为避免重复提交同位置评论，状态汇总见下（F-002 ~ F-005），本轮只为新增发现提交 1 条行内评论。

遗留问题（均非阻塞）

1. F-001（新增，advisory，行内 ostool/src/boot/fit_config.rs:263）：错误诊断把调用上下文硬编码为 BIN/load。详见行内评论。
2. F-002（advisory，沿用行内评论 4227846823，ostool/src/boot/fit.rs:153-160）：LoongArch MZ 镜像头 entry 换算仍内联在 generate_configured_fit()，FitAddress::Auto 出现两个解析点，并绕过 direct_entry() 的落点校验。建议在接线 PR 前收敛进 FitConfig。
3. F-003（advisory，沿用行内评论 4227846828，fit_config.rs:171-191）：elf_load_base() 要求所有 file-backed PT_LOAD 共享同一 p_paddr - p_offset，fail-closed 且不会写出错误基址，但带 gap 的真实内核 ELF 只能显式 load，使 format = "elf" + 默认 Auto 的可用面偏窄。
4. F-004（advisory，沿用行内评论 4227846833，fit_config.rs:134-168）：direct_entry() 只校验 entry 所在 section 的 LMA == VMA；format = "elf" + 默认 os = "linux" 下其余段 VMA≠LMA 仍会生成成功（Linux 自身早期启动代码会建立映射/重定位，且本 head 已用注释记录该取舍，因此不作为阻塞项）。建议在接线 PR 的用户文档中固定该 flatten 契约。
5. F-005（advisory，沿用行内评论 4278335719，fit.rs:64-256、mod.rs:6-7）：新增生成路径仍无调用方与端到端回归，CI 只覆盖合成 ElfMetadata 夹具（其 executable_start = None，恰好跳过符号冲突分支）。建议接线前补“真实 ELF → 生成 FIT → 断言 os/load/entry/payload”的用例，覆盖 format=bin、format=elf、os=elf 与 source/runtime 同路径与不同路径两个分支。

复核后未发现问题的地方

NamedTempFile + persist 的原子替换与权限保留（新输出 0666 受 umask 收窄、已有输出保留原权限）、输出与输入别名/硬链接保护、validate_elf_load_data() 的截断与溢出检查、bin_load_base()/section_lma() 的 p_paddr + file_delta LMA 规则、toml/json 往返测试、旧 U-Boot Linux 路径的等价性，以及新增生产代码中无 unwrap()/expect()/unsafe。

相近工作

本 PR 声明依赖 #193；仓库内相关既有工作为 FIT 边界重构 #122/#123、boot readiness #129、raw BIN 准备 #125、FIT 修复 #194/#201/#207。以 repo:drivercraft/ostool type:pr FIT ELF BIN 搜索未发现与本 PR 重复的开放 PR。

Powered by deepseek-flash

[mai-team-app]

审查结论

COMMENT（未发现阻塞问题）。 本 head cf308f4 相对上一轮已审的 57dab0c 只有一个提交（fix(ostool): 按地址解析阶段报告 FIT 错误），仅改 ostool/src/boot/fit_config.rs（+56/-38），内容是把 elf_load_base()/bin_load_base()/section_lma()/checked_end()/elf_container_base() 里硬编码的错误文案改为中性描述，并在调用点用 .context("cannot derive BIN FIT load address; set load explicitly") / .context("cannot derive ELF FIT load address") / .context("cannot derive FIT entry; set entry explicitly") 归属语义，另补一段断言两路径 root cause 一致的测试。地址推导逻辑、FitConfig 语义、fit.rs 与旧 U-Boot 路径均未改，因此上一轮结论继续成立：无阻塞问题；本轮新增 1 条 advisory（组合校验只挂在 resolve_load()），另有 4 条既有 advisory 仍未处理。

本 PR 做了什么、影响面

• 新增 ostool/src/boot/fit_config.rs：crate-private FitConfig/FitFormat/FitOs/FitAddress/FitFdt，以及 resolve_load()/resolve_entry()/direct_entry()/bin_load_base()/elf_load_base()/section_lma() 地址推导。
• ostool/src/artifact/elf_metadata.rs：新增 LoadSection 与 load_sections（SHF_ALLOC、非 SHT_NOBITS、file_range() 存在且 size≠0），用于按 LMA 推导裸 BIN 落点。
• ostool/src/boot/fit.rs：新增内部入口 generate_configured_fit() 与 validate_elf_load_data()；写 FIT 拆为 write_fit_image(..., os)；旧 generate_fit_image() 语义不变（仍固定 os = "linux"、仍对 LoongArch 调 resolve_kernel_entry_addr()，ostool/src/run/uboot.rs:1327 调用点未改）。
• ostool/src/boot/mod.rs：注册 fit_config 模块并保留 #[allow(dead_code)]。
• 影响面：generate_configured_fit 与 fit_config 在本 PR 内仍无调用方（mod.rs:6-7），.uboot.toml/.board.toml 解析与用户可见行为均未改动，改动完全内部化；真正被固定下来的是“FIT load/entry 如何由 ELF 元数据推导”这一契约，供接线 PR 依赖。未发现对现有 U-Boot Linux 流程的行为回退。

验证

• CI：head cf308f48ec1a2d8eb83a60901088fee94a873c36 的 check (stable, x86_64-unknown-linux-gnu) 为 success（check run 116221906486，2026-10-15T03:02:36Z 完成），该工作流包含 cargo fmt --all -- --check、cargo clippy --target x86_64-unknown-linux-gnu --all-features、cargo build、cargo test -- --nocapture。未发现与本 PR 相关的失败 CI。
• 本地：git rev-parse HEAD = cf308f4…（与审查目标一致）、git rev-parse origin/main = 787943d…、工作区干净，git diff --check origin/main...HEAD 通过。本审查环境没有 Rust 工具链（which cargo/which rustc 均未找到），cargo fmt --check、cargo clippy、cargo test 未能本地复跑；这不是本 PR 导致的失败，也意味着地址推导目前只由 CI 中的合成单测覆盖。未做任何 U-Boot/硬件实机启动验证。

上一轮 review 的处理情况

• 57dab0c 一轮的唯一 advisory（F-001，review comment 4278498269：section_lma()/checked_end() 把诊断上下文硬编码成 BIN/load，ELF entry 推导失败时会建议错误方向）：已修——helper 文案改为中性、上下文由调用点 .context(...) 归属，并新增单测断言 entry 错误文案不含 “BIN FIT load” 且两路径 root cause 相同。该条中“组合校验只挂在 resolve_load()”的剩余部分未修，本轮记为 F-001 行内评论。
• 更早的阻塞项与 ZR233 的 [P1]/[P2]（os = "elf" 的 entry 语义、BIN load 按 section LMA 推导、BIN entry 与 load 同地址空间、format = "elf" 的 Auto load 不再信 VMA 符号）在 8076e5d/e7b566e 已修复，本 head 未回退。
• ZR233 在 review body 里要求的“真实 ELF → 生成 FIT → 断言属性/payload”回归仍缺失，见 F-002（按 AGENTS.md 的人工验证条款不阻塞）。

遗留问题（均非阻塞）

1. F-001（本轮新增，advisory，行内 ostool/src/boot/fit_config.rs:119）：os = elf ⇒ format = elf 的组合校验只在 resolve_load()（78-81 行），resolve_entry() 没有；详见行内评论。
2. F-002（advisory，沿用既有行内评论 4278335719，ostool/src/boot/fit.rs:81）：新增生成路径与地址推导契约仍无端到端回归，CI 只覆盖合成 ElfMetadata 夹具（其 executable_start = None 恰好跳过符号冲突分支）与 build_fit_config 单测。建议接线前补“真实 ELF → 生成 FIT → 断言 kernel 的 os/load/entry 与 payload”用例，覆盖 format=bin/format=elf/os=elf 与 source/runtime 同路径与不同路径两个分支。
3. F-003（advisory，沿用既有行内评论 4227846823，ostool/src/boot/fit.rs:145-160）：LoongArch MZ 镜像头的 entry 换算仍内联在 generate_configured_fit()，Auto entry 有两个解析点，并绕过 direct_entry() 的落点校验。建议把 payload 相关换算收敛进 FitConfig。
4. F-004（advisory，沿用既有行内评论 4227846828，ostool/src/boot/fit_config.rs:169-190）：elf_load_base() 要求所有 file-backed PT_LOAD 共享同一 p_paddr - p_offset，fail-closed 但偏严，带 gap 的内核 ELF 只能显式 load。
5. F-005（advisory，沿用既有行内评论 4227846833，ostool/src/boot/fit_config.rs:136-166）：direct_entry() 只校验 entry 所在 section 的 LMA == VMA；format = "elf" + 默认 os = "linux" 下其余段 VMA≠LMA 仍会生成成功。建议在文档中固定 format = "elf" 的 flatten 契约。
6. 复核后未发现问题的地方：NamedTempFile + persist 的原子替换与权限保留（新输出 0666 受 umask 收窄、已有输出保留原权限）、输出与输入别名保护（含 rename 不破坏硬链接）、validate_elf_load_data() 的截断与溢出检查、bin_load_base()/section_lma() 的 p_paddr + file_delta LMA 规则、toml/json 往返测试、旧 U-Boot Linux 路径的等价性，以及新增生产代码中无 unwrap()/expect()/unsafe。

相近工作

本 PR 声明依赖 #193；仓库内相关既有工作为 FIT 边界重构 #122/#123、boot readiness #129、raw BIN 准备 #125、FIT 修复 #194/#201/#207。以 repo:drivercraft/ostool is:pr is:open FIT 搜索未发现与本 PR 重复的开放 PR（该搜索只命中 PR #196 自身）。

Powered by deepseek-flash

[ZR233]

为什么需要改动

本次更新继续提供内部 FIT 生成能力，目标是让后续接线能够安全区分 ELF 容器、裸 BIN、FIT 的 load/ entry 和 U-Boot 的 os 语义。当前提交仍未修改 .build.toml、.uboot.toml、.board.toml、CLI 或既有 U-Boot runner，因此没有发现现有配置解析或默认启动流程的回归。

改动收益

相对上一轮审查，当前 head 已修复会导致生成镜像无法启动的地址问题：

• os = "elf" 现在要求 format = "elf"，并把 FIT entry 约束为 ELF 在内存中的容器地址（等于 load），而不是 ELF 的 e_entry。
• BIN 的自动 load 按实际 section LMA/物理加载布局推导，__executable_start 不一致时拒绝静默采用。
• BIN 的自动 entry 不再直接使用 VMA 的 e_entry，会检查入口所在的文件段是否与加载地址空间一致。
• 配置化 LoongArch Linux BIN 在自动入口场景复用已有镜像头换算；旧路径仍使用原有 Linux 语义。
• 输出暂存后再持久化，保留既有输出权限并避免写入输入别名。

改动前逻辑（基准分支）

基准分支只有 generate_fit_image() 路径。U-Boot runner 在 ostool/src/run/uboot.rs 中调用它，读取 BIN/DTB/ramdisk，固定生成 os = "linux" 的 FIT；地址来自现有 runner 逻辑。仓库中没有这次新增的 FitConfig 地址解析层。

改动后逻辑（当前拉取请求）

当前提交把公共写 FIT 部分抽成 write_fit_image(..., FitOs)，旧入口仍显式传入 FitOs::Linux，所以既有 U-Boot 流程保持原调用链和 Linux FIT 行为。新增的 generate_configured_fit() 与 fit_config 仍是 crate-private、由后续 boot-prepare PR 接入；它先解析并校验 source/runtime ELF 的布局，再解析地址、选择 ELF 或 BIN payload，最后写出 FIT。当前 PR 没有把这些字段暴露到用户配置，因此不会凭 FitConfig 默认值改变已有配置。

验证与覆盖

• 当前精确 head：cf308f48ec1a2d8eb83a60901088fee94a873c36。
• GitHub Actions Quality Check run 38673550429、job check (stable, x86_64-unknown-linux-gnu) 116221906486 均为 completed/success；日志包含 format、clippy、build、unit test（ostool 二进制 333 tests passed）、Web UI unit/integration tests 和 publish dry run。
• git diff --check refs/remotes/upstream/main...HEAD 通过；所有现有 review threads 均已 resolved。
• CI 当前执行了地址解析合成单测和旧生成路径测试，但没有执行“真实 ELF → generate_configured_fit → FIT 属性/payload → U-Boot 启动”的端到端路径，也没有实体板卡/U-Boot 实机证据。该边界不会掩盖现有配置兼容性结论，接线 PR 必须补齐。

后续接线边界

以下保留为非阻塞跟进项：接线时应使用可选父配置，缺省时继续调用旧 generate_fit_image()；若字段放入 .uboot.toml，要同步 UbootConfigWire 和远程板卡映射；应补真实 ELF 覆盖 format=bin、format=elf、os=elf 以及 source/runtime 两种路径；并考虑把 LoongArch 入口特判和组合校验收敛到单一配置解析入口，明确带 gap ELF 的显式 load 限制和 format=elf, os=linux 的 flatten 契约。

结论

在当前提交和声明范围内未发现新的阻塞问题：旧配置与默认 U-Boot 流程保持兼容，上一轮地址语义阻塞项已修复，当前 CI 证据与精确 head 一致。因此本次审查通过；上述端到端覆盖和用户入口属于后续接线 PR 的验收条件。

[MRNIU]

hi @ZR233 ，bot 的 changes requested block 似乎没有更新

[mai-team-app]

审查结论

APPROVE（未发现阻塞问题）。 在 head 168b9501b690306301871fb135f067bf732044ca 上逐文件复核了全部 5 个改动文件（+1100/-64）。相对上一轮已审的 cf308f4，本 head 的 fix(ostool): close FIT review gaps 一并收口了此前遗留的全部 review 项（组合校验统一、Auto entry 单一解析点、真实 ELF 端到端回归），其余为已在本 head 用注释固定的设计取舍或属于后续接线 PR 的范围。因此给出通过结论。

本 PR 做了什么、影响面

• 新增 ostool/src/boot/fit_config.rs（crate-private FitConfig/FitFormat/FitOs/FitAddress/FitFdt，以及 validate()、resolve_load()、resolve_entry()、loongarch_image_entry()、bin_load_base()/elf_load_base()/section_lma()）。
• ostool/src/artifact/elf_metadata.rs：新增 LoadSection/load_sections（SHF_ALLOC、非 SHT_NOBITS、file_range() 存在且 size≠0），用于按 LMA 推导裸 BIN 落点。
• ostool/src/boot/fit.rs：新增内部入口 generate_configured_fit() 与 validate_elf_load_data()；把写 FIT 拆为 write_fit_image(..., os)；旧 generate_fit_image() 仍固定 os = "linux"。
• ostool/src/boot/mod.rs：注册 fit_config 模块并保留 #[allow(dead_code)]（用户入口由接线 PR 接入）。
• 影响面：generate_configured_fit 与 fit_config 在本 PR 内没有生产调用方，.uboot.toml/.board.toml 解析、ostool/src/run/uboot.rs 的调用点以及用户可见 CLI/配置均未改动，属完全内部化改动；被固定下来的是“FIT load/entry 如何由 ELF 元数据推导”这一契约。旧路径经复核语义等价：resolve_kernel_entry_addr(arch, data, load, fallback) 由等价的 loongarch_image_entry(...)?.unwrap_or(kernel_entry_addr) 取代；build_default_fit_config → build_fit_config(..., FitOs::Linux) 仅增加参数；成功日志从写临时文件处移到两个入口 persist 之后。

验证

• CI：head 168b950 的 check (stable, x86_64-unknown-linux-gnu)（check run 116811223443，Actions run 38850760828）completed/success（2026-10-16T04:40:31Z）。该工作流执行 cargo fmt --all -- --check、cargo clippy --target x86_64-unknown-linux-gnu --all-features、cargo build、cargo test --target x86_64-unknown-linux-gnu（包含本 head 新增的真实 ELF 端到端测试，依赖工作流安装的 llvm-tools）、webui 测试与 cargo publish --workspace --dry-run --locked。未发现与本 PR 相关的失败 CI；该 check run 上的 2 条 ENOENT .../target/tests/target 注解属 e2e 工具链噪声，与本 PR（不涉及 webui）无关。
• 本地：git rev-parse HEAD = 168b950…（与审查目标一致）、git rev-parse origin/main = 787943d…、工作区干净、git diff --check origin/main...HEAD 通过。本审查环境没有 Rust 工具链（cargo/rustc/objcopy/llvm-objcopy 均不存在），cargo fmt --check、cargo clippy、cargo test 未能本地复跑；这不是本 PR 导致的失败。未做 U-Boot/硬件实机启动验证。

上一轮 review 的处理情况

• mai-team-app（cf308f4 的阻塞项）：os = elf ⇒ format = elf 的组合校验只挂在 resolve_load()。已修：抽出 FitConfig::validate() 由 resolve_load()/resolve_entry() 共用，并新增 rejects_incompatible_os_and_format_from_both_resolvers 断言两个入口返回同一文案。
• mai-team-app（行内评论 4227846823，advisory）：LoongArch MZ 头换算内联在生成入口，Auto entry 有两个解析点并绕过 BIN 落点校验。已修：loongarch_image_entry() 移入 fit_config.rs，resolve_entry(&metadata, load, &payload) 成为唯一解析入口，旧路径 ALSO 复用同一函数。
• mai-team-app（行内评论 4278335719，advisory）：缺少“真实 ELF → 生成 FIT → 断言属性/payload”的回归。已修：新增 generates_configured_fit_from_a_real_elf_for_elf_and_bin_payloads，用真实 prepare_runtime_artifacts() 与真实 llvm-objcopy -O binary 覆盖 format=bin / format=elf / os=elf 以及 source==runtime 与独立 runtime 两条分支，并断言 kernel 组件的 os/load/entry/data。
• mai-team-app（行内评论 4227846828 / 4227846833，advisory）：elf_load_base() 的单一容器基址限制、direct_entry() 只校验 entry 所在段。已在本 head 用代码注释固定为明确契约（elf_load_base() 说明“连续字节容器/单一基址”，resolve_entry() 文档注释说明 format=elf+os=linux 的 flatten 契约与 os=elf 的适用场景），行为仍为 fail-closed。
• ZR233 的 [P1]/[P2]（bootelf 需要内存中 ELF 头地址、__executable_start 是 VMA）：在 8076e5d/e7b566e 已修，本 head 未回退；其 review body 要求的真实 ELF 回归由上述新测试落地。
• ZR233 在 cf308f4 上 APPROVED；作者在 2026-10-16T03:23 的 issue comment 提到“bot 的 changes requested block 似乎没有更新”。经复核，此前 CHANGES_REQUESTED 依据的问题在当前 head 均已修复或转为已文档化的非阻塞取舍，故本次为 APPROVE。

遗留风险与测试缺口（均非阻塞）

1. format = "elf" + FitAddress::Auto 要求所有 file-backed PT_LOAD 共享同一 p_paddr - p_offset，否则报错要求显式 load；fail-closed 且诊断明确，但带 gap/非等距布局的内核只能显式指定，建议在接线 PR 的用户文档中说明。
2. direct_entry() 只校验 entry 所在 section 的 LMA == VMA；format = "elf" + 默认 os = "linux" 下其余段 VMA≠LMA 仍会生成成功（依赖内核自身早期映射/重定位）。该契约已写入 resolve_entry() 文档注释，建议在用户文档中重复并引导非恒等映射内核使用 os = "elf"。
3. FIT os = "elf" 依赖目标 U-Boot 注册该 OS 字符串（CONFIG_CMD_ELF）并启用 CONFIG_BOOTM_ELF；生成阶段无法校验远端配置，当前错误文案只提到 CONFIG_BOOTM_ELF，建议接线文档一并说明。
4. 本 PR 未提供用户入口，端到端只覆盖“生成 FIT + 断言属性/payload”，没有 U-Boot/硬件实机启动证据；这些属接线 PR 的验收条件。
5. 复核后未发现问题的部分：os = "elf" 必须 format = "elf" 且 entry 等于 payload load（与 do_bootm_elf() → bootelf(bmi->images->ep, …) 语义一致）；format = "elf" 的 Auto load 以 p_paddr - p_offset 为容器基址、符号仅在一致时被接受；BIN 的 load/entry 与 objcopy/BFD 的 p_paddr + file_delta LMA 规则一致；validate_elf_load_data() 的文件范围与溢出检查；NamedTempFile + persist 原子替换、新输出走 umask、已有输出保留原权限、输入别名/硬链接保护；toml/json 往返测试；旧 U-Boot Linux 路径等价性；新增生产代码无 unwrap()/expect()/unsafe。

相近工作

本 PR 声明依赖 #193。以 repo:drivercraft/ostool is:pr is:open FIT 搜索只命中本 PR 自身，未发现重复的开放 PR；相关既有工作为 FIT 边界重构 #122/#123、boot readiness #129、raw BIN 准备 #125、FIT 修复 #194/#201/#207。

Powered by deepseek-flash