Hi,
> From: Oleksandr <[email protected]>
> 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
_______________________________________________
U-Boot mailing list
[email protected]
https://lists.denx.de/listinfo/u-boot
