[U-Boot] [PATCH v1 0/3] Enable HPS execution stage notification

[Ang, Chee Hong]

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 at intel.com wrote:
> > > > 
> > > > 
> > > > From: "Ang, Chee Hong" <chee.hong.ang at 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.