[参考译文] RTOS/OMAP-L138：直接引导至 A 和#39；ROM 模式和#39；二进制映像时出现问题。

您好、Keith、

在使用引导加载程序加载与"ROM 初始化"链接的非 SYSBIOS 应用程序时、您是否会看到此问题？  __TI_auto_init()在技术上不属于 SYSBIOS。 它是由链接器链接的用于初始化全局变量的函数。 有关更多详细信息、请参阅 ARM 优化 C/C++编译器用户指南中的第6.10节"系统初始化"： http://downloads.ti.com/docs/esd/SPNU151/index.html#SPNU151N_HTML/run-time-environment.html?Highlight=rom_model

如果您对系统初始化的执行方式有具体问题、编译器论坛也应提供帮助。

此致、

文森特

尊敬的 Vincent：

提前感谢您的帮助。 我是否应该将其移至其他论坛？

是的、我的引导加载程序实际上会查看离散的以确定要应用程序。  有2种可能的应用程序、一种是 SYSBIOS 应用程序、另一种是香草 C 运行时应用程序。  每次加载并执行 C 运行时应用程序时、SYSBIOS 不加载。

当我查看我的映射文件时、_TI_auto_init 似乎来自两个应用的不同库：

从我的 SYSBIOS 应用程序映射文件：  

c3000000 00000060 boot.ae9：boot.oe9 (.text)
c3000000 000000d7 arm_Ground 程序_pe9.oe9 (XDC.meta)
c3000060 00000008 rtsv5_a_le_eabi.lib：args_main.obj (.tramp._args_main.1)
c3000068 00000008 auto_init.ae9：auto_init.oe9 (.tramp.__TI_auto_init.1)
c3000070 00000008 rtsv5_a_le_eabi.lib：exit.obj (.tramp.exit.1)

从我的 C 运行时应用程序映射文件：  

init 0 c0000000 00000060
c0000000 00000048 rtsv5_a_le_eabi.lib：boot.obj (.text)
c0000048 00000008：args_main.obj (.tramp._args_main.1)
c0000050 00000008：auto_init.obj (.tramp.__TI_auto_init.1)
c0000058 00000008：exit.obj (.tramp.exit.1)

在我的 SYSBIOS 链接器命令文件中(除了 RTOS 自动生成的文件外)、我执行此操作以强制入口点位于特定地址：

｛

初始化：｛boot*(.text)｝> 0xC3000000

｝

在我的 C 运行时链接器命令文件(此项目中唯一的文件)中、我执行此操作以强制入口点位于特定地址：

init：{rtsv5_a_le_eabi.lib (.text)｝> 0xC3000000

Keith

您好、Keith、

引导加载程序对 SYSBIOS 应用程序和非 SYSBIOS 应用程序的作用之间是否有差异？ 如果是、我怀疑专门处理 SysBIOS 应用程序的代码有问题。 不确定"我的引导加载程序实际上是通过查看离散来确定要应用程序"的含义。 (BTW、C 运行时应用程序的映射文件似乎表示您已将其加载到与链接器命令文件中显示的地址不同的地址-可能只是一个拼写错误。)

同时、我发现以下一些链接可能会有所帮助：
e2e.ti.com/.../303974
e2e.ti.com/.../106611
processors.wiki.ti.com/.../Boot_Images_for_OMAP-L138
e2e.ti.com/.../1839020

您能否检查此信息是否能帮助您解决问题？  特别是最后一个线程、在将 SysBIOS 程序引导加载到 ARM 时似乎表示成功。

此致、
文森特

尊敬的 Vincent：

非常感谢您的帮助！

我已经解决了我的问题。  最后、我如何压缩和存储 tiobj2bin.bat 工具为我创建的二进制映像时遇到了问题。

由于我的程序位于0xC3000000、而我的向量存储在0xFFFFFFFF、因此 tiobj2bin.bat 为这些目标创建的单个二进制映像的大小几乎为1 GB。

我开发了一个工具、使用运行长度编码来压缩图像、并将程序和矢量拆分为两个更小的图像、这些图像存储在 NOR 闪存中。

为此、我使用了映射文件中的信息来查找程序的末尾。  这就是导致我出现问题的原因。

我使用了"内存配置"中的"已使用"值来找到最终结果
使用下面的映射代码段可得到0xC3000000 + 0x00434117 = 0xC34117

事实证明、这并不是真正准确的。  如果您在"regment allocation map"中的映射文件中稍微深入一点、则会发现.cinit 段(实际上是程序代码中的最后一个段)
从0xC34330D8开始，长度为0x1048 ......... 0xC34330D8 + 0x1048 = 0xC34120

"内存配置"始终是.cinit 段实际大小的9分之一。
因此，我无意中切断了.cinit 段的末端，这会导致 AUTO_Init()进入杂草中。

它有时会起作用的原因是、我还在程序代码之后直接嵌入了一个32位 CRC。  在某些情况下、此 CRC 值将等同于半有效的.cinit 条目、并且至少会使数据发生跛形。

我更新了我的二进制压缩工具、以解决这种差异、现在它在100%的时间内工作。

我还在表中添加了几个0值字、因为我在其他一些文章中看到、这可能是标记.cinit 表本身的末尾所必需的(也称为让 Auto_Init（)函数知道如何停止初始化常量)

Keith

映射文件片段

(笑声)
(笑声)

名称源长度使用未使用的属性填充
------------ ---- ------ ---- ---- --------
L3_CBA_RAM 8000000 00020000 00000000 00020000 RW X
DDR c3000000 03000000 00434117 02bcbee9 RW X
IRAM ff00002000 00000368 00001c98 RW X

段分配映射

运行 origin load origin length init length atts members
------ ------ ------ ------ ---- ----
c3000000 c3000000 00000078 00000078 r-x
c3000000 c3000000 00000078 00000078 r-x .init
c3000078 c3000078 003816da 00000000 rw-
c3000078 c3000078 003816da 00000000 rw-.bss
c338754 c338754 0000002c 0000002c 0000002c r-x
c3381754 c338754 0000002c 0000002c r-x .text.1
c3381780 c3381780 00058cc0 00000000 rw-
c3381780 c3381780 00058cc0 00000000 rw-.far
c33da440 c33da440 0003fffc 0003fffc r-x
c33da440 c33da440 0003fffc 0003fffc r-x .text.2
c341a43c c341a43c 00010000 00000000 rw-
c341a43c c341a43c 00010000 00000000 rw-.stack
c342a43c c342a43c 00001bc4 00001bc4 r-
c342a43c c342a43c 00001bc4 00001bc4 r-.const.1
c342c000 c342c000 00004000 00000000 rw-
c342c000 c342c000 00004000 00000000 rw- ti.sysbios.family.arm.arm.arm9.mutableSection
c3430000 c3430000 000011f9 000011f9 r--
c3430000 c3430000 000011f9 000011f9 r-.const.2
c34311fc c34311fc 00001ed8 00000000 rw-
c34311fc c34311fc 00001ed8 00000000 rw-.data
c34330d8 c34330d8 00001048 00001048 r--
c34330d8 c34330d8 00001048 00001048 r-.cinit
ff0000 ffff0000 00000368 00000368 r-x
ff0000 ffff000000000040 00000040 r-.vecs
ff0040 ffff0040 00000328 00000328 r-x .vectorTable

(笑声)
(笑声)