[U-Boot] [linux-sunxi] [RFC PATCH 8/8] sunxi: enable PSCI for A83T SoC

[Maxime Ripard]

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 <marc.zyngier at arm.com> 写到:
> >> On 07/06/17 08:00, Chen-Yu Tsai wrote:
> >>> On Wed, Jun 7, 2017 at 2:50 PM, Maxime Ripard
> >>> <maxime.ripard at free-electrons.com> 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 <icenowy at aosc.io>
> >> wrote:
> >>>>>>
> >>>>>>
> >>>>>> 于 2017年6月7日 GMT+08:00 上午11:36:27, Chen-Yu Tsai <wens at csie.org> 写到:
> >>>>>>> On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng <icenowy at aosc.io>
> >> 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 <icenowy at aosc.io>
> >>>>>>>> ---
> >>>>>>>>  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: <http://lists.denx.de/pipermail/u-boot/attachments/20170607/491f81a3/attachment.sig>