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

admin

Guru**** 2046040 points

Other Parts Discussed in Thread: SYSCONFIG

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1450857/am263p4-q1-issue-with-image-generation-in-ccs-theia---bin-and-tiimage-are-huge

器件型号：AM263P4-Q1
主题中讨论的其他器件：SysConfig

工具与软件：

你(们)好

我在使用 CCS THEIA 和映像生成时遇到问题。

我正在从事的项目应该能够轻松地适应384kB 的尺寸。

构建时、CCS 中的存储器分配显示此情况全部正常：

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

附加了 SysConfig 文件。

我试图将初始化模型从 RAM 更改为 ROM、但看不到任何更改。

将.out 与 bin 和 appimage 文件附加到了一起

e2e.ti.com/.../2063.Debug.zip

这会阻碍开发、因为我无法进行调试。

提前感谢您的帮助。

此致

单端

5 个月前

0 admin 5 个月前

TI__Guru**** 2046040 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

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

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

0 admin 5 个月前

TI__Guru**** 2046040 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

尊敬的 Seb：

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

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

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

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

谢谢

0 admin 5 个月前

TI__Guru**** 2046040 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

你(们)好

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

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

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

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

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

谢谢

此致

单端

0 admin 5 个月前

TI__Guru**** 2046040 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

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

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

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

Fullscreen

1
2
3
4
5
6
7
8
9
10
% 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
 
<...>
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

% 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 . 使用此命令...

Fullscreen

1
2
3
4
5
6
7
8
9
10
11
% 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
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

% 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.

0 admin 5 个月前

TI__Guru**** 2046040 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

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

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

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

0 admin 5 个月前

TI__Guru**** 2046040 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

您好、George 和 Kier

非常感谢您的回答。这是非常有用的信息。

我将对此进行研究、看看如何解决我的问题、但肯定是很好的指示。

如果实验得出结论、我会再次将问题标记为已解决。

感谢您的帮助。

此致

单端

0 admin 5 个月前

TI__Guru**** 2046040 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

你(们)好

为了从今天早上开始跟进帖子、遵循您的建议、图像会减少很多。非常感谢您的建议。

我可以将板闪烁 OK。

但是、我很难获得可靠的调试启动。对于引导加载程序项目、在闪存中刷写 SW 后、开始调试更可靠、然后使用不带初始化 GEL 的配置开始调试、连接到目标并加载符号。

但这很麻烦。是否有更好/更快速可靠地启动调试会话？

此外、即使使用这种方法、有时也需要进行多次电路板复位(使用电路板上的按钮)才能正确启动、并避免在执行 Bootloader_socLoadHsmrtFw 函数期间软件崩溃。

我渴望了解如何在构建后可靠地开始调试、因为这会大大加快该过程。

当部分代码在 XIP 中执行、而另一部分代码没有执行时、我也渴望了解图像结构。

看起来、我们目前需要刷写2个文件、但正常的经典刷写过程只需要一个十六进制文件。我渴望了解如何达到这一点。

期待您的阅读。

此致

单端

0 admin 5 个月前

TI__Guru**** 2046040 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

我认为最好为上述每一个问题单独提出一个问题。

虽然非常麻烦。是否有更好/更快速可靠地启动调试会话？[/QUOT]
最好的调试方法是通过开发引导模式和初始化 GEL 脚本执行、但您说这不可靠。或许在单独的 TT 中、会详细说明为什么它对您来说不可靠。

基于 Arm 的微控制器（参考译文帖）

基于 Arm 的微控制器（参考译文帖）(Read Only)

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