From mboxrd@z Thu Jan 1 00:00:00 1970 From: icenowy at aosc.io Date: Sun, 02 Jul 2017 20:36:04 +0800 Subject: [U-Boot] [linux-sunxi] [RFC PATCH 8/8] sunxi: enable PSCI for A83T SoC In-Reply-To: <20170702122215.23ee232c@why.wild-wind.fr.eu.org> References: <20170607004721.24194-9-icenowy@aosc.io> <20170607065036.rlv5oif2majhxi7s@flea.lan> <40F87103-B0D5-47C0-BE60-59B84CC261F6@aosc.io> <9c72276f-5523-872d-9f69-22400ac51a11@arm.com> <20170623133552.opmdhtlvcljh53t5@flea.lan> <27424350c4a34d9a76c404ee61e5c55e@aosc.io> <941782a7f5af40657e30b5091f1b22a5@aosc.io> <20170702122215.23ee232c@why.wild-wind.fr.eu.org> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: u-boot@lists.denx.de 在 2017-07-02 19:22，Marc Zyngier 写道： > On Sun, 2 Jul 2017 15:08:12 +0800 > wrote: > >> 在 2017-06-23 21:50，Chen-Yu Tsai 写道： >> > On Fri, Jun 23, 2017 at 9:39 PM, wrote: >> >> 在 2017-06-23 21:35，Maxime Ripard 写道： >> >>> >> >>> On Fri, Jun 23, 2017 at 09:24:25PM +0800, icenowy at aosc.io wrote: >> >>>> >> >>>> 在 2017-06-07 20:51，Marc Zyngier 写道： >> >>>> > On 07/06/17 13:12, Icenowy Zheng wrote: >> >>>> > > >> >>>> > > >> >>>> > > 于 2017年6月7日 GMT+08:00 下午8:11:12, Marc Zyngier >> >>>> > > 写到: >> >>>> > > > On 07/06/17 08:00, Chen-Yu Tsai wrote: >> >>>> > > > > On Wed, Jun 7, 2017 at 2:50 PM, Maxime Ripard >> >>>> > > > > wrote: >> >>>> > > > > > On Wed, Jun 07, 2017 at 11:47:24AM +0800, Chen-Yu Tsai wrote: >> >>>> > > > > > > On Wed, Jun 7, 2017 at 11:40 AM, Icenowy Zheng >> >>>> > > > > > > >> >>>> > > > wrote: >> >>>> > > > > > > > >> >>>> > > > > > > > >> >>>> > > > > > > > 于 2017年6月7日 GMT+08:00 上午11:36:27, Chen-Yu >> >>>> > > > > > > > Tsai 写到: >> >>>> > > > > > > > > On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng >> >>>> > > > > > > > > >> >>>> > > > wrote: >> >>>> > > > > > > > > > As we have now a basical implementation >> >>>> > > > > > > > > > of PSCI for A83T, enable >> >>>> > > > > > > > > > non-secure boot support and PSCI on A83T now. >> >>>> > > > > > > > > > >> >>>> > > > > > > > > > Signed-off-by: Icenowy Zheng >> >>>> > > > > > > > > > --- >> >>>> > > > > > > > > > arch/arm/mach-sunxi/Kconfig | 4 ++++ >> >>>> > > > > > > > > > 1 file changed, 4 insertions(+) >> >>>> > > > > > > > > > >> >>>> > > > > > > > > > diff --git a/arch/arm/mach-sunxi/Kconfig >> >>>> > > > > > > > > b/arch/arm/mach-sunxi/Kconfig >> >>>> > > > > > > > > > index 7ced838d6a..31d29de428 100644 >> >>>> > > > > > > > > > --- a/arch/arm/mach-sunxi/Kconfig >> >>>> > > > > > > > > > +++ b/arch/arm/mach-sunxi/Kconfig >> >>>> > > > > > > > > > @@ -98,8 +98,12 @@ config MACH_SUN8I_A33 >> >>>> > > > > > > > > > config MACH_SUN8I_A83T >> >>>> > > > > > > > > > bool "sun8i (Allwinner A83T)" >> >>>> > > > > > > > > > select CPU_V7 >> >>>> > > > > > > > > > + select CPU_V7_HAS_NONSEC >> >>>> > > > > > > > > > + select CPU_V7_HAS_VIRT >> >>>> > > > > > > > > > + select ARCH_SUPPORT_PSCI >> >>>> > > > > > > > > > select SUNXI_GEN_SUN6I >> >>>> > > > > > > > > > select SUPPORT_SPL >> >>>> > > > > > > > > > + select ARMV7_BOOT_SEC_DEFAULT if >> >>>> > > > > > > > > > OLD_SUNXI_KERNEL_COMPAT >> >>>> > > > > > > > > >> >>>> > > > > > > > > The kernel does not work yet. Please have it boot to >> >>>> > > > > > > > > secure by >> >>>> > > > default >> >>>> > > > > > > > > regardless of the kernel. We can have it >> >>>> > > > > > > > > boot non-secure once the >> >>>> > > > > > > > > kernel >> >>>> > > > > > > > > has been working for a reasonable amount of time. >> >>>> > > > > > > > > >> >>>> > > > > > > > > I don't want clueless users coming and asking why it >> >>>> > > > > > > > > suddenly >> >>>> > > > stopped >> >>>> > > > > > > > > working. This should be an experimental feature. >> >>>> > > > > > > > >> >>>> > > > > > > > Maybe you should send out the fix, and tag them to also >> >>>> > > > > > > > apply to >> >>>> > > > > > > > stable tree. >> >>>> > > > > > > > >> >>>> > > > > > > > GIC is really broken, UP systems only work by chance. We >> >>>> > > > > > > > shouldn't depend on this behavior. >> >>>> > > > > > > >> >>>> > > > > > > As I previously explained, it is not the GIC that is broken. >> >>>> > > > > > > I >> >>>> > > > believe >> >>>> > > > > > > the GIC is working exactly as it is supposed to with >> >>>> > > > > > > regards to its >> >>>> > > > > > > input signals. >> >>>> > > > > > > >> >>>> > > > > > > Allwinner's security extensions implementation simply does >> >>>> > > > > > > not >> >>>> > > > properly >> >>>> > > > > > > forward the AXI secure bit when the e-fuse's secure bit isn't >> >>>> > > > burned. >> >>>> > > > >> >>>> > > > Arghh. Puke. Now I remember this, and I wish I didn't... >> >>>> > > > >> >>>> > > > > > Is that on all revisions, or just the revB ? >> >>>> > > > > >> >>>> > > > > It's the A80, but I'm guessing the same applies to the A83T. It's >> >>>> > > > more >> >>>> > > > > of a guess really, but I think it's a logical one. If the e-fuse >> >>>> > > > isn't >> >>>> > > > > programmed, the TZPC doesn't work, and access to all secure >> >>>> > > > peripherals >> >>>> > > > > still work, even from non-secure mode. The only one that >> >>>> > > > > does work is >> >>>> > > > > the secure SRAM. >> >>>> > > > > >> >>>> > > > > The GIC still has the banked secure/non-secure registers, just >> >>>> > > > > that >> >>>> > > > all >> >>>> > > > > cores access the secure bank, even when in non-secure mode. The >> >>>> > > > workaround >> >>>> > > > > is to use the alias set of non-secure registers in Linux. >> >>>> > > > >> >>>> > > > That's a pretty dire workaround. Also, I expect that secure writes >> >>>> > > > to >> >>>> > > > GICV/GICH will not do the right thing. At this point, what is the >> >>>> > > > requirement for running non-secure? >> >>>> > > >> >>>> > > Write Secure Boot eFUSE, which will break *all* existing softwares. >> >>>> > >> >>>> > Don't do it, then. >> >>>> > >> >>>> > Any other *real* use case for running non-secure? As in "Stuff that >> >>>> > would benefit to a user"? Because if the answer is "none" as I suspect >> >>>> > it is, you might as well keep the system in secure mode. >> >>>> >> >>>> Maybe we should then use legacy SMP bringup method (code in kernel) >> >>>> rather than PSCI? >> >>> >> >>> >> >>> I guess it all depends on the answer to Marc's question. If >> >>> virtualization doesn't work, then we don't have any incentive anymore >> >>> to use PSCI and that would be a sensible option, yes. >> >> >> >> >> >> I remember non-secure is a dependency for virtualization (HYP mode). >> >> >> >> So if we do not do the workaround on GIC, we won't have stable >> >> non-secure, then we won't have HYP mode, then we can drop PSCI. >> > >> > I think you got it the other way around. >> > >> > If virtualization doesn't work, despite the workaround, then there's >> > no need for it, and we can just do legacy SMP. >> >> I tried `qemu-system-arm -enable-kvm` on A83T with this patchset and >> Chen-Yu's GIC workaround patchset, and *FAILED*. >> >> The workaround patchset in fact slightly broke vGIC code by changing >> a macro name -- it's easy to fix. >> >> However, it seems that with this fixed the KVM cannot still work -- >> I tried to start a virtual machine, but it silently fails (no kernel >> log are shown when the VM starting fails). >> >> So, at least this workaround cannot let virtualization work. > > Before discounting it altogether, it'd be interesting to find out what > breaks exactly. How did you start the guest? What is the failure mode? Oh, I'm sorry. I used wrong command for it... (forgot -cpu host parameter) Now it works. Virtual machine boot log is available at [1]. [1] https://pastebin.anthonos.org/view/66a9ca54 So it may be valuable to apply the workaround now? > > Thanks, > > M. > -- > Without deviation from the norm, progress is not possible.