[U-Boot] [PATCH 1/3] ARM: rmobile: Switch CPU to non-secure HYP mode for r8a7790 based boards

Oleksandr olekstysh at gmail.com
Thu Mar 14 11:37:23 UTC 2019


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.


>
> And I apologize again for taking this long to reply.

No problem.


>
> [...]
>
-- 
Regards,

Oleksandr Tyshchenko



More information about the U-Boot mailing list