> Subject: Re: [PATCH 0/3] Add power domain driver support for i.mx8m family > > On 4/17/2019 3:13 PM, Lucas Stach wrote: > > 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. > > It might be possible to rework this to use some form of SCMI-over-SMC > instead of vendor-specific SMCCC SIP calls Whether SCMI or just SIP, it will make it easy to support virtualization(partition) or TEE. > > +SCMI maintainer We need implement firmware in ATF, and use SMC as the mailbox. I have taken Andre's previous patch to support smc mailbox and addressed some comments, and trying integrate with SCMI. The major issue is SCMI spec does not include SMC support. Sudeep, do you have any suggestions? Thanks, Peng. > > > 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. > Hiding everything critical for security (especially CCM) behind a SCMI > interface would be a large amount of work but introducing SCMI > incrementally (starting with imx8mm power) would be useful by itself because > it simplifies OS implementation. > > Many at NXP have attempted to evaluate SCMI and their conclusion has > always been that "many extensions are required". > > -- > Regards, > Leonard
