2398221_zh-CN

[#1]

NXP iMX8MP：基于WFI的CPU在U-Boot中处于空闲状态时不会唤醒

尊敬的恩智浦技术支持团队：

我们正在研究基于 i.MX8M Plus 的产品的 U-Boot 中的低功耗等待机制，现在我们希望得到 NXP 的指导。

软件版本

• SoC：NXP i.MX8M Plus
• BSP：
  • ATF：lf_v2.10_android-15.0.0_1.2.0
  • U-Boot：lf_v2024.04_android-15.0.0_1.2.0
  • 基于公开的 NXP 电路板支持包（Variscite 分支对 ATF/GIC 代码路径没有相关的修改）

目标

在 Android 系统启动之前，应用程序需要在 U-Boot 模式下停留几分钟，以便为深度放电的电池充电。

基于 mdelay() 的忙循环会消耗不必要的功率并产生额外的热量，因此我们正在尝试定期进入低功耗空闲状态，并使用 ARM 通用定时器 (CNTP, PPI 30) 唤醒。

初始实施

• 配置 CNTP 定时器
• 启用 PPI 30
• 从 EL2 执行原始 wfi()

处理器永远不会从 wfi() 中唤醒。UART 输出突然停止，没有任何异常或崩溃。

PSCI 实现

• PSCI_VERSION 返回 1.1
• PSCI_FEATURES(CPU_SUSPEND) 返回 0（支持）
• 调用 CPU_SUSPEND 请求进入待机电源状态

程序会执行 ATF 备用程序实现 imx_cpu_standby()，但系统会以完全相同的方式挂起：没有异常，没有 UART 输出，执行永远不会恢复。

因此，两者：

• 在 EL2 级别执行原始 wfi() 函数
• wfi() 通过 ATF 经由 PSCI 执行

产生相同的行为。

已经核实的内容

CPU 和定时器

• U-Boot 在 EL2 层执行。
• CNTP定时器已正确编程。
• CNTP_TVAL_EL0 倒计时正常。
• CNTP_CTL_EL0 显示：
  • 启用 = 1
  • IMASK = 0
  • 布防后，ISTATUS = 0。

CPU接口

• ICC_PMR_EL1 配置正确。
• ICC_IGRPEN1_EL1 已启用。

虚拟化

HCR_EL2 具有：

• IMO = 0
• FMO = 0

因此，中断路由不会通过 EL2 虚拟化进行。

中断网络安全分类

我们从美国烟酒枪炮及爆炸物管理局（ATF）的消息来源证实：

• 所有PPI最初都由通用GICv3辅助代码配置为第1组非安全设备。
• 只有 SGI8（以及可选的 SDEI SGI）被重新配置为安全模式。
• PPI 30 不在安全中断属性表中。

因此，通用定时器中断似乎仍如预期那样保持为第 1 组非安全状态。

SCR_EL3.TWE

我们最初怀疑不安全的 wfi() 可能会通过 SCR_EL3.TWE 被困到 EL3，但现在看来不太可能，因为当 wfi() 通过 PSCI 在 ATF 内部执行时，也会发生同样的行为。

进一步调查

在跟踪 ATF GIC 初始化时，我们注意到 gicv3_distif_init() 会清除 Distributor EnableGrp 位，并且只会重新启用安全中断属性表请求的那些位。

由于该辅助程序只生成 Group0 和 Group1 Secure 属性，因此 EnableGrp1NS 似乎永远不会被显式地重新启用。

为了验证这一点，我们：

• 读取 GICD_CTLR
• 观察到 EnableGrp1NS = 0
• 尝试从 EL2 自行设置 EnableGrp1NS。

不料：

• 写入操作顺利完成，没有出现任何错误。
• RWP运行正常
• 但读取后 EnableGrp1NS 仍然为 0。

我们还核实了：

• GICD_CTLR.DS == 0
• GIC 内存区域的 RDC 保护已禁用（ENA = 0）
• RDC违规登记数量仍为零。

因此，RDC 似乎并没有阻止写入操作。

剩余问题

至此，我们已经排除了：

• 定时器编程
• CPU接口配置，
• 中断优先级掩码
• 中断组分类，
• SCR_EL3.TWE 捕获，
• PSCI 与原始 WFI 执行方式对比，
• RDC保护。

剩下的未解释的行为是，架构上不安全的可写分发器控制位（EnableGrp1NS）似乎不接受此平台上的写入，因此原始 wfi() 和 PSCI CPU_SUSPEND 都无法使用通用定时器中断唤醒。

1. i.MX8M Plus Android 15 电路板支持包。 出现这种现象是否正常？
2. 在公共 ATF 源代码之外，是否存在任何平台特定的初始化缺失，导致通用定时器 PPI 无法通过 wfi() 唤醒 CPU？
3. EnableGrp1NS 是否被有意阻止在此平台上被不安全的软件修改？
4. 有没有人成功地使用以下两种方法之一实现了从 U-Boot 定期唤醒：
   • 原始 wfi()，或
   • PSCI CPU_SUSPEND
     由 ARM 通用定时器驱动？

非常感谢您能提供任何关于预期初始化顺序或平台特定行为的见解。

谢谢！

顺祝商祺！

码头