On Tue, 2019-05-07 at 16:39 +0200, Marek Vasut wrote:
On 5/7/19 4:08 PM, Ang, Chee Hong wrote:
On Tue, 2019-05-07 at 15:03 +0200, Marek Vasut wrote:
On 5/7/19 7:07 AM, chee.hong.ang@intel.com wrote:
From: "Ang, Chee Hong" chee.hong.ang@intel.com
Notify Secure Device Manager (SDM) on the stage of HPS code execution. In general, there are three main code execution stages: (1) First Stage Boot Loader (FSBL) which is U-Boot SPL. (2) Second Stage Boot Loader (SSBL) which is U-Boot. (3) Operating System which is Linux.
Ang, Chee Hong (3): ARM: socfpga: stratix10: Add HPS execution stage notification function ARM: socfpga: stratix10: To notify SDM when SPL pass control to U-Boot ARM: socfpga: stratix10: To notify SDM when U-Boot pass control to Linux
arch/arm/mach-socfpga/include/mach/mailbox_s10.h | 7 +++++++ arch/arm/mach-socfpga/mailbox_s10.c | 6 ++++++ arch/arm/mach-socfpga/misc_s10.c | 5 +++++ arch/arm/mach-socfpga/spl_s10.c | 6 ++++++ 4 files changed, 24 insertions(+)
Can we expect any of this mbox stuff to be ever migrated over to DM and moved into drivers/ instead of constantly adding stuff to mach- socfpga ?
These mailbox stuffs are basically a set of functions shared by SPL, u- boot and Linux (PSCI) which is specific to our platform. Even if we convert this mailbox stuffs to DM and move to drivers/, we still need to duplicate those functions for PSCI which can be called by Linux. We are starting to spend time converting our existing clock manager and etc for S10 platform to DM and will move them to drivers/. But we still need to keep those PSCI stuffs which are specific to our platform in mach-sofcpga.
There was some discussion about the PSCI here: https://www.mail-archive.com/u-boot@lists.denx.de/msg319458.html
Yes. I am aware of it. Current implementation of PSCI in u-boot is "just work" but not elegant.
Currently, the PSCI sections only exist right before u-boot booting Linux, because those PSCI functions will be used by Linux only. Our current boot flow involve only u-boot (no ATF): 1) SPL (EL3, secure) 2) U-boot (El3. secure) 3) Install PSCI sections (EL3, secure) 4) Linux (EL1, non-secure)
U-boot don't need PSCI call to access secure resources because it's already running in EL3 (secure). Linux will be calling those PSCI functions(EL3) from EL1 to access secure resources.
For those users who typically don't use u-boot's PSCI, their boot flow is as follow:
1) ATF (EL3, secure) 2) Install PSCI sections (also known as secure monitor) (EL3, secure) 3) U-boot (EL2, non-secure) 4) Linux (EL1, non-secure)
With this boot flow, all PSCI stuffs are in ATF. So u-boot and Linux don't have access to secure resources so both of them have to access it via PSCI/SMC calls. The downside is this boot flow involves 2 pieces of software component which are ATF and u-boot.
Back to our u-boot use case, so far our PSCI services don't have dependency on common full driver such as (SPI, I2C and etc). That's the reason we just have sets of functions which can be directly called by u-boot(EL3) and also called by Linux(EL1) through PSCI/SMC.
Those PSCI discussions are some good discussions. You have made your points and I know where you stand in those discussions. Currently, PSCI is just part of u-boot (2nd stage boot loader) and it is detached from u-boot right before booting Linux because u-boot is not expected to stay resident in memory after booting Linux.
Whether PSCI should be part of SPL or TPL to support full drivers in DM and how/when it should be installed need some serious thought and effort to do it right.