From mboxrd@z Thu Jan 1 00:00:00 1970 From: Maxime Ripard Date: Wed, 7 Jun 2017 15:04:27 +0200 Subject: [U-Boot] [linux-sunxi] [RFC PATCH 8/8] sunxi: enable PSCI for A83T SoC In-Reply-To: <9c72276f-5523-872d-9f69-22400ac51a11@arm.com> References: <20170607004721.24194-1-icenowy@aosc.io> <20170607004721.24194-9-icenowy@aosc.io> <20170607065036.rlv5oif2majhxi7s@flea.lan> <40F87103-B0D5-47C0-BE60-59B84CC261F6@aosc.io> <9c72276f-5523-872d-9f69-22400ac51a11@arm.com> Message-ID: <20170607130427.kb6zhjqndegixquk@flea.lan> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: u-boot@lists.denx.de On Wed, Jun 07, 2017 at 01:51:48PM +0100, Marc Zyngier wrote: > 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. The initial idea was to use PSCI for the core bringup, which afaik requires Linux to run non-secure, right? If that is so fundamentally broken that this is the only benefit, I guess we might as well use some old-style SMP ops. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: