On 09/13/2013 05:54 AM, Nicolas Pitre wrote:
On Thu, 12 Sep 2013, Catalin Marinas wrote:
Linux interaction with the firmware is another area which badly needs standardisation, whether it is secure firmware or not, simply because that's the first code a CPU executes when out of reset. Such standardisation is even more important in the presence of secure firmware (and given that AArch64 is new, companies will have to write new firmware and there is little legacy to carry).
What I'm saying is that _complexity_ in the firmware is _*THE*_ problem. Whether it is old or new, AArch64 or AArch32, PSCI or whatnot.
The _increasing_ interactions between any firmware/bootloader and Linux _is_ a serious problem. This is a problem because it _will_ have bugs. It _will_ have version and implementation skews. It will require _more_ coordinations between different software parts beyond any standard interfaces. And that is _costly_ and a total nightmare to manage. And even more so when those bugs are in the (possibly unalterable) firmware.
You can bury your head in the sand as you wish and conveniently downplay those facts. I personally do care greatly and I do have sympathy for vendors who might wish to pursue a different path than this single solution with everything in firmware approach.
For the discussion, i'm neutral. :-) But upper question is really good point, so let me give more input here.
Before when we developed for Trustzone Software (TZSW), the two worlds (Non-Secure and Secure world) we can simply take them as two separate contexts, if these two contexts have their own state machine and need interactive with each other's state machine, the code will be complex and is really bad thing.
Finally we refined the code to decouple the state machine, the basic idea is to let one world maintain the context and another world _ONLY_ provide the primitive functionalities.
IMHO, PSCI have an assumption at here: we know ARM has used a micro-controller (or a tiny ARM core) as the separated power controller for the power management, and has the firmware run on this controller. So whatever PSCI or the power controller's own code can be flexibly upgraded. But i think many SoC companies will design their own logic for power management unit (PMU) resident in the SoC, it's not flexible and from previous product experience, the logic for low power mode is easily to have silicon bugs.
Taking account upper concern, if the PSCI only provide the primitive functionalities (cache operations, CCI port operations, GIC/Timer related operations) and the state machine is maintained in Linux will be more flexible.
Thx, Leo Yan