From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marc Zyngier Date: Wed, 7 Jun 2017 13:51:48 +0100 Subject: [U-Boot] [linux-sunxi] [RFC PATCH 8/8] sunxi: enable PSCI for A83T SoC In-Reply-To: <40F87103-B0D5-47C0-BE60-59B84CC261F6@aosc.io> References: <20170607004721.24194-1-icenowy@aosc.io> <20170607004721.24194-9-icenowy@aosc.io> <20170607065036.rlv5oif2majhxi7s@flea.lan> <40F87103-B0D5-47C0-BE60-59B84CC261F6@aosc.io> Message-ID: <9c72276f-5523-872d-9f69-22400ac51a11@arm.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: u-boot@lists.denx.de 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. M. -- Jazz is not dead. It just smells funny...