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