我试图了解如何使用U-boot PSCI接口将内核引导到HYP模式。
通过u-boot源代码，我确实看到有一个通用的psci.S和其他psci.S这是特定于板子的并且有以下疑问。
1）。 psci.S如何以及在何处适合正常的u-boot流程（在启动u-boot时调用cpu_on和cpu_off等psci服务的时间和方式）.s
2）。如何使用u-boot的psci接口在HYP模式下启动内核（在psci接口中允许Linux内核以HYP模式启动的是什么）？
答案 0 :(得分：2)
1）。 psci.S如何以及在何处适合正常的u-boot流程
U-boot预留了一些安全世界内存和安全监控代码的副本，这样它可以在U-Boot退出后保持驻留状态，并提供对某些PSCI SMC呼叫的最小处理。
（启动u-boot时调用cpu_on和cpu_off等psci服务的时间和方式）
他们不是。 U-Boot仅在主CPU上运行并切换到Linux。 Linux可能会在其自己的引导过程中稍后启动辅助核心，但到目前为止U-Boot已经过去了，除了前面提到的安全监视器代码。
2）。如何使用u-boot的psci接口在HYP模式下启动内核
不是。
（psci界面中允许Linux内核以HYP模式启动的是什么？）
没有
您所指的补丁系列背后的一点是，对于32位ARM平台而言，（并且遗憾的是）它们常常具有TrustZone感知硬件设计，但却支持垃圾软件。供应商BSP实现了足够的引导加载程序以启动事物，并且从未从引导中切换出安全的SVC模式，因此整个Linux在安全的世界中运行，并且其内核充满了高度特定于平台的代码，仅限于安全硬件就像电源控制器一样。如果你想使用虚拟化（如果你是KVM / ARM的共同维护者并且最近自己购买了CubieTruck，这显然是一个紧迫的问题......） - 这会带来一个问题 - 它很容易足以将U-boot代码用于这样一个平台，并在启动Linux之前切换到NS-HYP，从而启用KVM（上游U-boot当时已经对此有了一些初步的支持），但是一旦你＆＃39;从安全的世界中退出后，您可以随后使用原始smp_operations启动辅助CPU，这取决于触及仅安全的硬件。
通过实现一些简单的运行时＆＃34;固件＆＃34;从引导加载程序的背面悬挂下来，然后您可以根据需要以最简单的方式回调安全世界，并且最有必要在那里移动必要的特定于平台的代码，以便在简单的固件调用接口后面抽象操作，尤其是，如果已经是Linux支持的合适的那个。
PSCI本身并没有什么特别之处 - 有很多ARM平台拥有适当的安全固件，通过它们自己的专有协议实现电源管理和SMP操作。一些模糊的相关方面是符合PSCI规范保证所有CPU都将以相同的模式出现，因此如果您最初在HYP中进入Linux，您将不会看到不匹配的辅助设备出现在某些模式中其他不兼容的模式或安全状态。