[参考译文] AM263P4：如何验证；更新校准和验证；？

尊敬的 Kier：

虽然我也在向我们的团队核实以便更好地理解这一点。 请允许我在星期五之前回来。

请查看有关此主题的编译器文档： https://software-dl.ti.com/codegen/docs/tiarmclang/rel1_0_0_sts/tiarmclang_ug/tiarmclang-portfolio/compiler_manual/program_loading_and_running/run-time-initialization-slau1316977.html

感谢手动链接。 我想选择 RAM 或 ROM 模型是需要考虑的因素、但可能对我的问题并不重要、因为两者都需要在 OSPI 中修改目标文件、这是一个棘手的问题。

如果需要更好地解释我的用例、请在本文档中进行更雄辩的说明： https://cdn.vector.com/cms/content/application-areas/ecu-calibration/xcp/XCP_Book_V1.5_EN.pdf

请参阅 "3.1. 闪存中的参数"

尊敬的 Kier：  

您的应用是从闪存还是从 RAM 运行？

如果它从 RAM 运行、那么映射文件能够为你提供.cinit 表的位置、这个位置在 RAM 中。

如果是 XIP、则在执行代码时写入闪存需要特殊的 IP (如 FOTA)才能写入闪存  

下面还介绍了 OTFA IP 的引导段功能(如果有用)： software-dl.ti.com/.../bootseg_ip_working.html

尊敬的 Nilabh：

我们的应用程序在 RAM 中运行。 映射文件仅给出.cinit 表在 RAM 中的位置。 我需要在 OSPI 闪存中.cinit 表的位置才能更改它。

从视觉上讲、我需要这样做：

我想这个问题是： 如何计算 OSPI 闪存中.cinit 的地址？

尊敬的 Kier：

让我在下周早些时候重新讨论这个问题。

有什么建议吗？ 我想这个问题可以归结为如何计算.cinit 在.appimage 或.mcelf 中的位置。

对不起 Kier 的长延迟,我是 OOO 由于旅行。

我将在该主题中循环访问我们的 MCELF 专家。

尽管有一些与我有关的考虑。 假设将对已签名的 mcelf 映像进行更新、如果您更新.cinit 段、则还需要更新哈希和签名、这将如何起作用。

您还打算使用已加密的图像或未加密的图像吗？

Unknown 说：

尽管有一些与我有关的考虑因素。 如果更新了一个已签名的 mcelf 映像、那么如果您更新.cinit 段、您将需要更新散列和签名、这将如何起作用。

这是一个非常好的问题。 我不认为它现在会工作,我想它,不是没有大量的努力。
至少 我必须将.cinit (或其等效项)移至任何有符号区域之外、但这本身会带来复杂性。

我想现在 我可以 回答这个问题。 我的备份计划是目前使用 EEPROM 来存储各个校准值、这是一个要简单得多的概念。

感谢回答相关问题。

我们似乎遇到了类似的问题。 我们还在研究项目中与校准文件处理主题相同的选项。 (链接)

除了 X509签名之外、使得情况变得复杂的部分是整个工具链设置为不可知闪存位置。 Flashwriter 会忽略 mcelf 中的段加载地址、而仅刷写单个"块"(例如完整的.mcelf)。 因此、闪存中的校准部分永远不会位于同一位置。  

我们尝试解决这个问题的方法是实施基于段的校验和或哈希、并确保闪存写入器修改为跟随段负载地址。 然后、您可以根据需要、根据原始 mcelf intent 刷写一个或多个段。 确实需要一个自定义的 HsmRT 映像、在该映像上没有很多信息。

到目前为止我发现的另一个问题是、出于某些原因、CCS 调试器使用段加载地址而不是运行地址来将程序加载到 RAM 中。 这意味着定义的 flash 布局非常难实现。 让 Lauterbach 焕发活力。

如您所说、可能最好找到替代方案。 这是一个非常复杂的过程、以前很简单。