From mboxrd@z Thu Jan 1 00:00:00 1970 From: Icenowy Zheng Date: Wed, 07 Jun 2017 20:12:21 +0800 Subject: [U-Boot] [linux-sunxi] [RFC PATCH 8/8] sunxi: enable PSCI for A83T SoC In-Reply-To: References: <20170607004721.24194-1-icenowy@aosc.io> <20170607004721.24194-9-icenowy@aosc.io> <20170607065036.rlv5oif2majhxi7s@flea.lan> Message-ID: <40F87103-B0D5-47C0-BE60-59B84CC261F6@aosc.io> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: u-boot@lists.denx.de 于 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. > >> I'm not about to waste one of my boards programming the e-fuse to >find >> out the hard way though. The CCU doesn't have a security setting. It >> might as well be secure-only. If one sets the e-fuse and the SoC's >> security extensions work as they're supposed to, then it will no >longer >> work with mainline Linux. Or any software we have for that matter. > >Fair enough. > >Thanks, > > M.