feat(ostool): support board-specific U-Boot load addresses

[bullhh]

问题

部分开发板的 U-Boot 环境变量并不提供 ostool 目前默认依赖的地址信息。

以 SG2002 为例，printenv 中没有 kernel_addr_r / loadaddr / kernel_comp_addr_r 等通用变量，只有板级启动脚本使用的 uImage_addr。因此 ostool remote U-Boot runner 在构建 FIT image 前无法推断 kernel entry，直接失败：

Error: Cannot determine kernel entry address

即使绕过 kernel entry 推断，串口 loady 上传 FIT 后，原逻辑也默认执行裸 bootm。这依赖 U-Boot 默认 loadaddr，在 SG2002 上不能保证从刚上传的 FIT 地址启动。

[bullhh]

为什么 SG2002 需要显式配置地址

SG2002 的 U-Boot 环境里没有 ostool 默认依赖的通用变量：

kernel_addr_r
loadaddr
kernel_comp_addr_r
kernel_addr_c

它的 Linux 启动流程使用的是厂商脚本变量：

uImage_addr=0x81800000
fatload mmc ${sddev} ${uImage_addr} boot.sd
bootm ${uImage_addr}#config-sg2002_licheervnano_sd

这里的 uImage_addr 只是 boot.sd 这个 FIT 文件的加载地址，不是 kernel 最终运行地址。Linux kernel 的 load/entry address 已经写在 boot.sd FIT 内部，所以 U-Boot 不需要通过 kernel_addr_r 暴露出来。

ostool 的流程不同：它会临时生成新的 image.fit，因此需要同时知道：

• FIT image 上传到哪里；
• FIT 内部 kernel 最终加载/执行到哪里。

所以 SG2002 需要显式配置：

kernel_load_addr = "0x80200000"
fit_load_addr = "0x82200000"
bootm_addr = "0x82200000"

含义是：

kernel_load_addr: Starry kernel 的最终 load/entry 地址
fit_load_addr:    通过 loady 上传 image.fit 的临时地址
bootm_addr:       执行 bootm 时解析 FIT 的地址

为什么不在 ostool 里自动解析 uImage_addr

不建议把 uImage_addr 作为 ostool 的通用 fallback，原因是：

• uImage_addr 不是标准 U-Boot 变量，只是厂商脚本约定；
• 它只能表示 FIT/uImage 文件的加载地址，不能推导 kernel 的最终 load/entry 地址；
• 不同板子的 uImage_addr 语义可能不同，硬编码会引入错误假设；
• 该地址可能只适合厂商 boot.sd，不一定适合 ostool 生成的 FIT。

因此更合适的方式是保留显式地址配置，让 board config 明确描述启动布局。这样不影响 OrangePi 这类标准 U-Boot 环境，也能支持 SG2002 这种非标准环境。