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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
