[参考译文] AM263P4-Q1：CCS THEIA 中的映像生成问题- bin 和.tiimage 非常大！

e2e.ti.com/.../UDS_5F00_SBL_5F00_OSPI-_2D00_-Copy.txt

附加下的 SysConfig 文件。 文本格式。

尊敬的 Seb：

Unknown 说：

但是、生成的.out 为2MB、.bin 和.appimage 接近2GB！

请注意、.out 不仅仅是加载到目标中的代码。 它包含仅加载到调试器的所有调试符号信息。 只有2MB 的一小部分将被加载到目标。

如果需要、我通知了该线程的编译器专家以了解更多信息。

我无法评论.bin 和.appimage、因为我不熟悉这些文件是如何生成的。

谢谢

Ki

你(们)好

我知道.out 会被调试信息夸大...因为即使所有代码都在 RAM 中正常运行、它也是一个引导加载程序项目、我似乎无法正常使用 CCS 启动调试会话。 我也尝试了使用引导加载程序示例项目、但会出现同样的行为。

调试的唯一方法似乎是通过刷写 SW、这对于每次将电路板置于串行引导模式、启动刷写脚本、然后返回到 OSPI 模式并加载不带 GEL 文件的调试会话...时、FAF 有点影响

但问题在于.tiimage 文件的大小。 我无法用它刷写电路板。

因此、我会被阻止进行调试。

期待您了解有关这方面的分辨率。

谢谢

此致

单端

我可以提供一些帮助、以加深您的理解。  但我无法告诉您解决此问题的最佳方法。

请阅读文章 二进制文件简介。  重点关注标题为 二进制文件中的空洞的部分。 基于此、下一步是查看已初始化段之间的存储器缺口是否很大。

在该线程的前面部分、您发布了一个包含一些文件的 zip 文件。  是其中一个文件 .out 初始文本文件。  使用实用程序 tiarmreadelf 检查文件中的各个部分。  它位于同一个位置 \bin 加载目录作为编译器 tiarmclang .  使用此命令...

% tiarmreadelf --sections UDS_sbl_ospi_multicore_elf_am263px-lp_r5fss0-0_nortos_ti-arm-clang.out
There are 40 section headers, starting at offset 0x1f67b4:

Section Headers:
  [Nr] Name              Type            Address  Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .sbl_init_code    PROGBITS        70002000 0005b8 000040 00  AX  0   0  8
  [ 2] .text             PROGBITS        70002100 000600 04ed40 00  AX  0   0 32
 
<...>

筛选输出以仅查看已初始化的段。  此类段是 type (类型) PROGBITS 和 FLG 列包含 Ax 或者 A .  使用此命令...

% tiarmreadelf --sections UDS_sbl_ospi_multicore_elf_am263px-lp_r5fss0-0_nortos_ti-arm-clang.out | findstr PROGBITS | findstr /c:" A"
  [ 1] .sbl_init_code    PROGBITS        70002000 0005b8 000040 00  AX  0   0  8
  [ 2] .text             PROGBITS        70002100 000600 04ed40 00  AX  0   0 32
  [ 3] .text.hwi         PROGBITS        70050e40 04f340 000dd0 00  AX  0   0 16
  [ 4] .text.cache       PROGBITS        70051c10 050110 0004a0 00  AX  0   0 16
  [ 5] .text.mpu         PROGBITS        700520b0 0505b0 0002d0 00  AX  0   0 16
  [ 6] .text.boot        PROGBITS        70052380 050880 0001c0 00  AX  0   0 16
  [ 8] .rodata           PROGBITS        70053890 050a40 003c90 00   A  0   0  8
  [17] .rodata.hsmrt     PROGBITS        70062100 0546d0 0066c3 00   A  0   0  8
  [26] .boot_info        PROGBITS        00000000 000034 000004 00   A  0   0  1
  [27] .cinit            PROGBITS        00000100 000038 00057c 00   A  0   0  4

注释 findstr 是 Windows 命令。  应用 findstr /？ 了解它的工作原理。 如果您使用的是 Linux 系统、请使用的某个变体 润滑 但是。

记住后面的第一列 PROGBITS 是该段的基地址。  请注意操作方法 .boot_info 和 .cinit 与其余部分很远。  这个差距就是二进制文件这么大的原因。

遗憾的是、我对您的版本了解不够、无法告诉您更改它的最佳方法、以便这两个部分靠近其余部分。

谢谢。此致、

-George.

正如 George 提到的、减小容器大小的关键是(重新)移动.cinit 和 boot_info 段。

我相信.cinit 之所以正确、是因为您已将其更改为 ROM 初始化模型。 如果您根据原始 SBL 示例将其改回 RAM 初始化模型、.cinit 应该会消失。

剩余的.boot_info 部分可能是您已针对具体的应用添加的内容。 您能否找到它旁边的 rodata？ 在任何情况下、boot_info 的加载地址(0x0)听起来都不正确、因为这是矢量表应该的位置。