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.
您好!
我正在使用 AM6548进行 AMP 系统设计。 正如 TI 建议的那样、AM6548中的一个内核可在 TrustZone 安全环境中运行、而其他内核则可在 TrustZone 非安全环境中运行。
安全(主)内核首先启动、然后需要启用其他(辅助)内核。 由于系统不使用 Arm 可信固件、在安全 主内核上运行的代码发出 TISCI 处理器引导管理请求(具体而言、为 TISCI_MSG_PROC_REQUEST、TISCI_MSG_PROC_SET_CONFIG、TISCI_MSG_PROC_SET_CONTROL)和电源管理请求(具体而言、为 TISCI_MSG_SET_DEVICE)以启动每个辅助内核。
DMSC 上的系统固件似乎正在使 TISCI_MSG_PROC_REQUEST 最小化、因此启动辅助内核的序列的其余部分会出现故障。
出于测试目的、我可以在 TrustZone 非安全状态下运行主内核、在这种情况下、TISCI 请求全部被确认、而辅助内核使用相同的代码序列正常启动。 除了 TrustZone 安全状态外、这两种安全状态下的代码之间的唯一区别是:
注意:一般而言、当从安全内核发出其他 TISCI 请求(例如、配置时钟、电源域、请求资源等)时、这些请求工作正常。
系统固件中是否存在导致来自安全内核的 TISCI 处理器引导管理请求失败的限制? 如果是、我如何解决它? 否则、可能是什么原因导致这种行为?
谢谢。
伊恩
我们以 Linux SDK 引导流程为例、
software-dl.ti.com/.../UG-General-Info.html
其中、A53上的引导序列:ATF -> OPTEE -> A53-SPL/u-boot/kernel。。
我建议参考您的设计中 PSCI/TISCI 上的 ATF/OPTEE 调用示例...
- PSCI/TISCI 上的 ATF
git.ti.com/.../k3_psci.c
git.ti.com/.../ti_sci.c
-关于 TISCI 的 OPTEE
git.ti.com/.../ti_sci.c
ATF 的好参考
信任固件-a.readtheddocs.io/.../firmware-design.html
此致!
-洪
感谢您的答复。 我熟悉 AM6548的正常启动流程以及 Arm Trusted Firmware/PSCI 实现方式、它基于我在问题中提到的 TISCI 请求。 很抱歉没有指出我正在使用的系统上没有 Arm Trusted Firmware。
我的问题的要点是、为什么从 TrustZone 安全世界中的 A53内核发出的 TISCI 引导处理器管理请求是赤裸裸的、以及为了让它们与从非安全世界发出的请求一样工作、需要做些什么。
尊敬的 Ian:
- 主机 ID、安全代理 ID 和中断号
- 是否存在其他 TISCI 消息标头
注意:一般而言、当从安全内核发出其他 TISCI 请求(例如、配置时钟、电源域、请求资源等)时、这些请求工作正常。
[/报价]我想您已经对 A53的所有不同主机 ID 设置进行了试验吗?
https://software-dl.ti.com/tisci/esd/20_04_01/5_soc_doc/am65x_sr2/hosts.html
此致、Andreas
在我的测试中、如果安全 A53使用除10之外的主机 ID、则来自安全 A53的任何 TISCI 请求完全没有响应、因此我假设10是正确的主机 ID。
如果我遗漏了您的观点、请您 澄清一下您的想法。
最有用的 情况是、请说明在安全环境中、A53内核发出系统固件 NAK TISCI_MSG_PROC_REQUEST 的条件、以及如何避免这种情况。
谢谢。
以下是在 ATF 校准 TISCI API 调用中如何使用 host_ID = 10 (secure)。
github.com/.../ti_sci.c
github.com/.../platform_def.h
此致!
-洪
https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/am65x_sr2/hosts.html#introduction
"此外、HostID 与安全代理通道绑定的主要原因之一是它可防止欺骗。 系统固件收到消息时、将对照接收消息的安全代理通道验证与消息中的 HostID 关联的安全代理通道。 具体来说、只有"主机名"列中列出的主机 ID 可以使用与之关联的安全代理通道。
https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/am65x_sr2/hosts.html#enumeration-of-host-ids
https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/am65x_sr2/sec_proxy.html#secure-proxy-thread-allocation-for-main-sec-proxy0
与"主机 ID"关联的"Secure Proxy Thread ID"代码中的示例= 10
https://github.com/ARM-software/arm-trusted-firmware/blob/master/plat/ti/k3/common/drivers/sec_proxy/sec_proxy.h#L26-L30
此致!
-洪
很抱歉、我遗漏了一些内容、但据我所知、您的回复中没有内容专门适用于 TISCI_MSG_PROC_REQUEST、而不是其他 TISCI 请求、例如启用时钟、分配资源和控制电源域。 正如我所指出的、当从安全 A53主机发出时、这些其他 TISCI 请求可以正常工作(因为我使用的代码已使用主机 ID 10和适当的安全代理通道)。
我以前看到的是、如果主机 ID、安全代理通道等出错、则 DMC/系统固件根本不会响应该消息。
这不是我发出 TISCI_MSG_PROC_REQUEST 时看到的情况;在这种情况下、当请求来自安全 A53内核(主机 ID 10)时、我会得到 NAK 响应。
这让我怀疑系统固件中有一些逻辑会拒绝该请求、原因包括电路板配置或关于哪一个主机 ID 可以管理我正在尝试启动的 A53内核的规则。 这是我希望别人解释的逻辑、最好提供有关如何使申请符合系统固件接受的要求的建议(例如、通过更改电路板配置)。
"通过簿记 API 实施访问控制。 访问的基本定义如下:
我们使用主机 ID (或普通主机)来确定请求者(就像 TISCI 的其他设备一样)。
默认情况下、我们允许所有处理器由任何其他主机控制(无管制)。
电路板配置提供:根据 PROC_ID、列出允许控制处理器的"允许的主机 ID"限制列表。 但条件如下:
-一次只有一台主机可以控制处理器
-主机(有控制)可以将处理器的控制权移交给允许列表中的另一个主机。
-在电路板 cfg 中标识"恢复主机"主机 ID,并且该主机可以覆盖已建立的所有权。
我们能否捕获 SYSFW 跟踪日志以检查"TISCI_MSG_PROC_Request"API 调用是否遵循上述排序...
此致!
-洪
感谢洪先生,这给了我一些工作机会...
您好、Hong:
我们系统中的电路板配置在 我尝试从 TISCI 请求开始的内核的允许主列表中包含安全 A53 (主机 ID 10)。 但是、最初控制 A53内核的 MCU 固件需要将对"辅助"内核的控制显式移交给安全 A53 (主机 ID 10)。 完成该更改后、TISCI 处理器管理请求将正常完成。 这与您在上面描述的内容是一致的、尽管需要花费一些时间来确定移交的地点。
感谢您的帮助;我认为这个话题现在可以结束了。