Hi,
From: Oleksandr olekstysh@gmail.com Sent: jeudi 14 mars 2019 12:37
On 14.03.19 02:16, Marek Vasut wrote:
On 2/12/19 8:52 PM, Oleksandr wrote:
Hi,
Hi
[...]
I was thinking about this whole PSCI situation and how it's all implemented today. Basically what we do is generate a separate reduced shred of U-Boot, which will remain resident in memory and which could be called by some other software. That shred is a piece of U-Boot proper, but a lot of stuff is just torn away at runtime, so it's not the whole binary, just tattered remnants of it.
I really do not like this approach to the whole U-Boot PSCI in the first place, it seems really fragile and dangerous.
But look, U-Boot already has support for U-Boot SPL/TPL, which is small, can contain a full driver model, drivers and all the necessary support functionality. It is built from the same sources, at the same time, but it is not a shred of U-Boot proper but rather a separate entity.
So I wonder, can't we use this U-Boot SPL/TPL as the piece of code which would remain resident in memory and handle the PSCI calls instead ? I think U-Boot can load such a code or it could be somehow bundled with U-Boot proper (using a fitImage maybe ?). This way you won't have to re-implement all the drivers in arch/arm/, the DM/DT remains in place and the whole PSCI handler would be self-contained, so no need to fiddle with linker sections of U-Boot itself.
I am CCing other people who use this PSCI stuff in U-Boot, maybe they have some thoughts on this approach.
Thank you for your honest answer.
Let's see what the community will say.
I will answer for STM32MP1 platform.
On STM32MP157 chip, the PSCI support is expected minimal in U-Boot for basic boot defconfig. ROM code => SPL => U-Boot (install PSCI monitor) => Kernel => only CPU_ON/OFF for hotplug needed by kernel but no power management.
For full PSCI support (standby modes), we are using TF-A secure monitor (trusted boot defconfig) with full power support or OP-TEE secure monitor ROM code => TF-A (BL2 install secure monitor = BL32 : SP min) => U-Boot (non secure world) => Kernel ROM code => TF-A (BL2) => secure OS = OP-TEE => U-Boot (non secure world) => Kernel In these 2 cases U-Boot access secure resource with SPCI request (SMC call).
But it in the future of the basic boot, if we want add a full PSCI support in U-Boot for power management, we need at least access to some resources: - I2C driver - STPMIC1 driver - DDR driver (to switch the DDR in self refresh mode) - Clock /reset driver
I agree all this part are already managed by U-Boot drivers / u-class. But we need also a way to have access to board information / DT description.
It is also why I don't implement the function psci_system_off() in ./arch/arm/mach-stm32mp/psci.c => I don't want recode a I2C driver in PSCI code...
void __secure psci_system_off(u32 function_id) { /* System Off is not managed, waiting user power off * TODO: handle I2C write in PMIC Main Control register bit 0 = SWOFF */ while (1) wfi(); }
So have a PSCI firmware with driver model based on the U-Boot code (as it is done for SPL/TPL) seems for me a good solution.
Question: what the right moment to install the secure monitor ?
+ SPL=> U-Boot then U-Boot can use PSCI installed firmware but no access of secure resource in U-Boot + U-Boot => Kernel then U-Boot is executed in secure world can't use the PSCI firmware (as today)
PS: the first solution is used for some board when the secure monitor of TF-A = BL32 is installed by U-Boot (see CONFIG_SPL_ATF)
ROM code => SPL : install BL32 compiled from TF-A code => U-Boot (non secure world) => Kernel
And I apologize again for taking this long to reply.
No problem.
[...]
-- Regards,
Oleksandr Tyshchenko
Regards
Patrick