[参考译文] DRA821U：DRA821 上的固件更新

尊敬的 P B：

由于今天的 TI 假日、预计响应会延迟。  

此致

Suman

尊敬的 PB：

查看 5.4.3。 三级引导加载程序 (BootApp)-是否可以使用 BootApp、但包含从被选者跳转到 Linux 内核、加载 u-boot 并跳转到 u-boot、让 uboot 引导 Linux？

您能否分享您的具体用例并说明 U-Boot 在您的应用中的作用？  

关于引导选项、器件支持多种引导流配置。 有关详细信息、请参阅以下应用手册：

- www.ti.com/.../sdaa123.pdf

关于 A/B 固件更新、我们目前没有专门的文档来概述此过程。 根据客户要求和引导介质选择、固件更新过程可能会有很大差异。

此致
Diwakar

您能否分享您的特定用例并解释 U-Boot 在您的应用中的作用？  [/报价]

主要用于引导脚本和通过签名拟合映像验证的引导。 此外、我将深入探讨已验证的嵌入式引导的一些详细信息、这是在 u-boot 中实现的标准引导的一部分。 我询问了 BootAPP 的引导流程、因为我怀疑 BootAPP 可能能够为系统的其余部分选择正确的引导插槽、因为我猜引导 ROM 没有这种功能。 对于我们的用例、理想的解决方案是能够从 SPL 或 Boot App Up（可能使用 A/B 方案）更新所有软件/固件栈。 这就是它在其他平台上的工作方式、其中第一个“外部“引导加载程序是来自 TF-A 的 BL2、因为它本身支持 PSA 固件更新、因此在该平台上拥有类似内容会很有用。  

关于 A/B 固件更新、我们目前没有专门的文档来概述此过程。 根据客户要求和引导介质选择、固件更新过程可能会有很大差异。

因此、我是否可以假设此平台上没有众所周知、成熟的固件更新方法、例如在我上面提到的 PSA 固件更新的情况下？ 客户必须使用自己的固件更新方法、是的吗？ （仅限 I target SD/eMMC 引导介质）。 有这样的资料有助于估计需要做多少工作。

[/quote]

尊敬的 PB：

对于我们的用例、理想的解决方案是能够从 SPL 或 Boot App Up（可能使用 A/B 方案）更新所有软件/固件栈。 这就是它在其他平台上的工作方式、其中第一个“外部“引导加载程序是来自 TF-A 的 BL2、因为它本机支持 PSA 固件更新、因此在该平台上拥有类似内容会很有用。

我建议查看应用手册中详细说明的所有引导流程选项。 根据我的理解、在进行定制后可以使用 SBL（次级引导加载程序）引导流程来满足您的要求。

那么、我是否可以假设此平台上没有众所周知的、成熟的固件更新方法、就像我在上面提到的 PSA 固件更新一样？ 客户必须使用自己的固件更新方法、是的吗？ （仅限 I target SD/eMMC 引导介质）。 有这样的信息有助于估计需要做多少工作。

该功能不包含在标准开箱即用 SDK 中。 但是、不同的客户已根据其特定要求实施固件更新功能。 目前、没有适用于此功能的标准化或参考 (“黄金“）流程。

此致
Diwakar