[参考译文] AM243X-AM243X：成功创建了.text_tcm-section MCU-PLUS-SDK

您好 Felix：

 位于 TCMA 存储器中的“text_tcm"一“一节主要包含 PROFINET FWHAL 中的时间关键型函数。 正如第一个屏幕截图所分享的那样、关键字“fast_code_hwal"附加“附加到 PROFINET FWHAL 中的大多数函数定义中、并且这些函数的相应文本存储在 TCMA 存储器中。 这可以加快这些函数的执行时间、并在高流量负载情况下提供更好的性能。

如果您有任何后续问题、敬请告知

此致、

Laxman  

你好、Laxman、

我了解该用例、从不对它进行质疑、但是我认为什么错误会自动放置在 TCM 中、而无需在链接器脚本中被引用。 我找不到这方面的任何文档、而且让某种神奇的东西看起来不是我想要的行为。 我也看不到这遵循链接器的默认放置算法。

我假设您使用智能放置 (https://software-dl.ti.com/codegen/docs/tiarmclang/rel4_0_2_LTS/compiler_manual/smart_placement/index.html) 来处理该文件或将其放置在 TCM 中的文档（我们在该部分发生之前就这样做了）、但不像一个神奇的部分。

这方面的文档在哪里？ 我只是想念它。

此致

Felix

您好 Felix：

但是什么错误我是自动放置在 TCM 中而没有被引用在链接器脚本中

这些 功能将被选择并 置于 TCM 中。 例如、“void fast_code_hwal PN_PTCP_resetDelayTimings“

定义中附加了“FAST_CODE_FWHAL"的“的任何函数都将是 TEXT_TCM 段的一部分。

然后、将“text_tcm"部分“部分按照 linker.cmd 文件中的指定放置在 TCMA 存储器中。

文档中没有明确提到这一点、我们将在即将发布的 SDK 版本中相应地进行更新。

此致、
Laxman

谢谢 Laxman、

我了解此#define 和本节的用法。 我认为这不是我们的问题。  

我还想在我们这边找到一些东西。 Profinet _DEVICE_RT_MRP_MII_ICSS_fwhal.am243x.r5f.ti-arm-clang.release.lib 放置在我们链接器脚本中的 DDR-RAM 内。
我们不使用该示例、因此没有提到将.text_tcma 段放置在 TCMA 中的链接器脚本。 我们从不在任何地方引用此.text_tcm-section。 它仍然弹出到 TCMA 内部。 所以我仍然不明白是什么使这个部分自动进入 TCM 中,即使在任何地方都没有提到,并且包含这个部分的库甚至被放置在其他地方。
在 https://software-dl.ti.com/codegen/docs/tiarmclang/rel4_0_2_LTS/compiler_manual/linker_description/05_linker_command_files/the-sections-directive-stdz0759595.html#section-allocation-and-placement 后面 它指出：“如果您不指示链接器如何分配某个段、它会使用默认算法放置该段。“ 如果我们查看默认算法 https://software-dl.ti.com/codegen/docs/tiarmclang/rel4_0_2_LTS/compiler_manual/linker_description/07_default_placement_algorithm/default-placement-algorithm-stdz0752588.html#stdz0752588 并遵循默认存储器模型 https://software-dl.ti.com/codegen/docs/tiarmclang/rel4_0_2_LTS/compiler_manual/linker_description/05_linker_command_files/the-memory-directive-stdz075888.html#default-memory-model 、它会指出它将使用整个可用的 32 位存储器地址范围。 这将是它放置在 TCMA 内部的唯一解释、因为它位于 0x00000000。 但是：我们还注意到、在另一个工程中、.text_tcm-section 将自动放置在 TCMB 中、因此如果链接器脚本中从未提及该段、则为 0x41010000 范围：
 

因此、这不可能是一个完整的案例、或者工具链文档也不完整。

此致

Felix

嗨、Laxman、

很抱歉晚才回复。 嗯、我们不使用 SYSCFG。 我们修改了 SDK-API、直接获取配置而不是数组和索引、而且我们还手动执行所有其他初始化工作、因为我们出于我们的目的实现了一个 C++驱动程序库。 我们的链接器文件还使用一些头文件、因为我们使用多个内核、并为头文件中的所有内核定义了 MEMORY 指令的地址范围。 但我当然可以通过私人信息发送给您。

下面是一个屏幕截图、我们还将 text.hwi-section 放在 tcma 内。 在以下命令之后会自动放置.text_tcm：

将其放置在 tcmb 中的情况的屏幕截图位于上一篇文章中。 我想这是因为 tcma 没有更多的空间（使用了 0x7110、最大空间为 0x8000、因此没有 0x16fc .text_tcm-section）。 另请注意、tcmb 的屏幕截图使用 Profinet IRT。 tcma 的屏幕截图仅使用 Profinet RT。

此致

Felix

您好 Felix：

如果 linker.cmd 文件中没有明确提到这一点、我们期望 text_tcm 段不会放置在存储器部分中。 但是、让我在内部讨论这一点、我们会尽快回复您。  

此致、
Laxman

您好 Felix：

我刚刚查看了您的询问、看到了您报告的相同行为。 即使链接器脚本中没有明确提及该段、该段仍由链接器定义并自动置于 TCM 中。 我正在尝试寻找正确的文档,我很快会回来给你。

此致、
Kamil  

嗨、Kamil、

感谢您的澄清、所以它的工作原理也是我猜过的。 为了确保我得到了正确的一切:TCMA 开始于 0x00000000。 一旦在 MEMORY 指令中定义的其中的空间不足、就会将该段移动到 MEMORY 指令中定义的下一个地址、并以增量顺序执行。 因此、链接器在 0x00008000（TCMA 末尾）和 0x41010000（TCMB 开头）之间会出现一个“空洞“、不会将其作为可用存储器提供给链接器。 由于下一个可用地址是 TCMB 和 GPMC、SRAM 和 DDR 在之后启动 (0x50000000、0x70000000 和 0x80000000)、因此它将恰好使用该 TCMB 地址。 但链接器需要在链接器命令文件 MEMORY 指令中获知该存储器。 如果理论上在比如 0x30000000 处会有另一个存储器、那么它会改用该地址。

我的假设是否正确？ 我只是想清楚地说明我的一切都是正确的。

您好 Felix：

感谢您的跟进。

是的、您的假设是正确的。 链接器将段放置在由 linker.cmd 文件的 MEMORY 指令定义的第一个足够且“可用“的存储器空间中。

您始终可以通过反复使用 存储器中定义的不同区域并观察生成的映射文件来验证这一点、看看每个段的分配位置。

此致、
Kamil