• 状态 Resolved
  • 已锁定 已锁定
  • 回复 5 回复
  • 订户 0 订户
  • 视图 18 视图
  • 用户 0 会员在此处
选项
选项
相关

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] CC1314R10：如何在 MCU 外部验证 OTA bin？

admin
Guru**** 2813665 points

Other Parts Discussed in Thread: SHA-256, CC1314R10, CC1354P10, UNIFLASH

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

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1617413/cc1314r10-how-to-verify-my-ota-bin-outside-my-mcu

器件型号： CC1314R10
Thread 中讨论的其他器件： CC1354P10、 UNIFLASH、SHA-256

您好、

我正在使用的器件 CC1314R10 上的 MCUboot 具有以下配置：

  • 引导加载程序基础： 0x00000000

  • 主插槽底座： 0x00006000

  • 辅助插槽底座： 0x00031000

  • 插槽大小： 0x2B000

  • 升级模式： 覆盖

  • 加密：已禁用

  • 防回滚：已禁用

我有一个无线网关架构：
User (Web UI)
   ↓
Host Gateway
   ↓
Collector (CC1314R10 with MCUboot)

用户通过网页上载固件.bin 文件。
主机网关会下载该.bin 并将其发送到收集器以进行 OTA 更新。

如果上传的固件无效（随机或损坏的二进制文件）并写入辅助插槽、则器件可能会因拖车状态不一致而卡在引导加载程序模式下。

为避免这种情况、我想验证固件映像 然后发送到 CC1314R10 器件。

我的问题

  1. 在外部（在 MCU 之外）验证 MCUboot 固件映像的建议方法是什么？

  2. 检查image_header幻数 (0x96F3B83D) 是否足够？

  3. 在覆盖模式下、在写入辅助插槽之前、映像尾部是否有任何其他元数据必须经过验证？



此致、
Muniyappan R.M.

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

    尊敬的 Muniyappan：

    我将尽我所知回答。 MCUBoot 是一个开源项目、询问 MCUBoot 社区对于您来说也会很有用。

    1.我会在 CC1354P10 上运行它以进行功能验证。  

    2.当您说辅助插槽中的映像可以使器件进入卡在引导加载程序模式时、听起来不只是 CRC 校验失败。 （然后引导加载程序会跳转到主槽位中的映像。）

    除了图像标头外、还有一个图像标尾。 我们在链接的 E2E 主题中讨论了“引导神奇“数字。

    3、我不知道。 我要在此处参考 MCUBoot 文档。

    谢谢、

    Marie H

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

    尊敬的 Marie：

    感谢您的快速答复。

    [引述 userid=“277653" url="“ url="~“~/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1617413/cc1314r10-how-to-verify-my-ota-bin-outside-my-mcu/6234654

    2.当您说辅助插槽中的映像可以使器件进入卡在引导加载程序模式时、听起来不只是 CRC 校验失败。 （然后引导加载程序会跳转到主槽位中的映像。）

    [/报价]

    >>我刷写了 损坏的二进制 V2.0-刚刚 使用 Uniflash 工具将运行固件 (V 1.0) 的一个字节修改到辅助插槽、然后重新提示电路板、并且我的电路板正在按预期运行我的旧固件 (V 1.0)。 很好很好

    我只需要知道如何完成此验证。 我可以使用 bin 在主机网关中执行此操作吗？


    此致、
    Muniyappan R.M.

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

    尊敬的 Muniyappan：

    如果您更改了映像中的一个字节并且没有重新计算 CRC、则将收到 CRC 错误。

    谢谢、

    Marie H

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

    尊敬的 Marie：



    [引述 userid=“277653" url="“ url="~“~/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1617413/cc1314r10-how-to-verify-my-ota-bin-outside-my-mcu/6235321

    如果您更改了映像中的一个字节并且没有重新计算 CRC、则将收到 CRC 错误。

    [/报价]

    其实那是我遗漏的部分。

    MCU 引导接头中的 CRC 值在哪里？

    因为在我的测试场景中、即破坏现有容器中的单个字节并使用上传 Uniflash 工具、它没有跳到我损坏的文件箱、而只是停留在现有的应用程序中。

    那么、谁确定固件已损坏以及如何损坏呢？。 如果引导加载程序检测到该问题、是否可以在主机网关中实现相同的检查？。


    由于我的当前流程是用户在网页上上传固件分级文件时、因此它是仅在网关中接收到的原始分级文件（网络或网关不会执行额外的 CRC 计算）。 因此、接收到的相同.bin 文件或任何文件都会转发到 CC1314R10 以进行 FA 固件升级。 然后、它将写入我的 CC1314 的辅助应用时隙、然后触发复位。

    因此、在积极情况和消极情况下、无论用户上传的 bin 文件是什么、都不会进行任何检查、将其传输并写入 CC1314 的辅助应用程序槽中。

    如果我能够确定如何在引导加载程序中完成固件验证并将其集成到主机网关中、就可以丢弃主机网关本身中的无效固件分级。 这可以节省应用中的大量时间、例如 172KB 的 SPI 传输（从主机 GW 到收集器）、存储在收集器闪存中、以及 172KB 的收集器到端传感器射频传输。


    此致、
    Muniyappan R.M.

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

    尊敬的 Muniyappan：

    是、CRC 校验在 MCUBoot 中实施。 抱歉、从技术上讲、这不是 CRC 校验、而是使用 SHA 进行的映像完整性检查。

    文件：c：\ti\simplelink_cc13xx_cc26xx_sdk_8_32_00_07\source\third_party\mcuboot\bootUtil\BootUtil\image_validate.c src

    在第 364-365 行、该函数计算整个映像的 SHA-256 或 SHA-384 哈希值：
    RC = BootUtil_img_hash (enc_state、image_index、hdr、fap、tmp_buf、
    TMP_buf_sz、哈希、SEED、SEED_len)；

    然后在第 396-413 行、将计算出的哈希值与映像 TLV 中存储的哈希值 (Tag-Length-value) 进行比较
    章节：
    FIH_CALL（BOOT_FIH_mequal、FIH_RC、哈希、buf、sizeof（哈希）)；

    谢谢、

    Marie H