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

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

> > > 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.
> 

No plan to implement SCPI like firmware on i.MX8M. i.MX8M don't

BR
Jacky Bai

> Regards,
> Lucas