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. Regards, Lucas
