RE: [PATCH 0/3] Add power domain driver support for i.mx8m family

[Jacky Bai <ping.bai@nxp.com>]

> Am Mittwoch, den 17.04.2019, 11:16 +0000 schrieb Aisheng Dong:
> > > From: Jacky Bai
> > > Sent: Wednesday, April 17, 2019 1:27 PM
> > >
> > > The i.MX8M family is a set of NXP product focus on delivering the
> > > latest and greatest video and audio experience combining
> > > state-of-the-art media-specific features with high-performance
> > > processing while optimized for lowest power consumption.
> > > i.MX8MQ, i.MX8MM, i.MX8MN, even the furture i.MX8MP are all belong
> > > to this family.
> > >
> > > The GPC module is used to manage the PU power domains' power on/off.
> > > For the whole i.MX8M family, different SoC has differnt power domain
> > > design. the power up sequence has significant difference.
> > > all the power sequence must be guaranteed by SW. Some domains' power
> > > up sequence need to access the SRC module or sub-system specific GPR.
> > > the SRC register & SS's register are not in in the GPC's memory range.
> > >
> > > it makes us hard to use the GPCv2 driver to cover all the different
> > > power up requirement. Each time, a new SoC is added, we must modify
> > > the GPCv2 driver to make it resuable for it. a lot of code need to be added
> in GPCv2 to support it.
> > > we need to access the SRC & SS' GPR, then the GPCv2 driver can NOT
> > > be self-contained. Accessing the non-driver specific module's
> > > register is a bad practice. Although, the GPC module provided the
> > > similar function for PU power domain, but it is not 100% compatible with
> GPCv2.
> > >
> > > The most important thing is that the GPC & SRC module is a security
> > > critical resource that security permission must be considered when
> > > building the security system. The GPC module is not only used by PU
> > > power domain power on/off. It is also used by the TF-A PSCI code to
> > > do the CPU core power management. the SRC module control the CPU
> > > CORE reset and the CPU reset vector address. if we give the non-secure
> world write permission to SRC.
> > > System can be easily induced to malicious code.
> > >
> >
> > Considering the security issue, it looks to me a right direction to
> > move GPC power handling into ATF.
> > It also helps build a more generic driver and ease other OS
> > integration needed by customers (e.g. QNX, Win10).
> >
> > Lucas,
> > How do you think of it?
> 
> I don't yet buy the security argument. There are many more shared parts on
> the SoC, like the clock controller, that would need to be taken away from the
> non-secure world if one would want to run an untrusted OS kernel on a
> i.MX8M system.
> 
> To properly implement security on any i.MX8M based system the firmware
> would need to grow something like a full ARM SCPI implementation, so all
> shared critical peripherals are solely under firmware control.
> 
> I agree that it might make sense to move some parts into the firmware and
> have much simpler OS level drivers, but I don't agree on the implementation
> direction taken here. Growing custom PSCI extension interfaces will only get
> us so far, without solving the system security issue in a holistic way. It is my
> strong believe that only a complete rearchitecture of the OS support on top of
> a ARM SCPI firmware interface can solve this properly.
> 

Hi Lucas,

Either SCMI or SCPI, I think it is initially designed for SOC that has dedicated SCP to
manage the SOC resource, but for i.MX8M, we don't have such support. so just
for the power domain support, do you have other suggestion for it.

BR
Jacky Bai

> Regards,
> Lucas