On Thu, 2019-03-14 at 01:16 +0100, Marek Vasut wrote: > On 2/12/19 8:52 PM, Oleksandr wrote: > > 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. > > And I apologize again for taking this long to reply. > > [...] > Adding Chin Liang and Jeremy.
Regards Ley Foon _______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
