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

[Marc Zyngier]

On 07/06/17 14:04, Maxime Ripard wrote:
> 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?

The SMC instruction is available from both PL1 exception levels, so
calling into PSCI from secure should be possible (assuming your PSCI
code is driven from Monitor mode).

> If that is so fundamentally broken that this is the only benefit, I
> guess we might as well use some old-style SMP ops.

Broken, for sure. Which is why I'm asking about the benefits of running
non-secure on something that has evidently been very badly integrated,
and for which non-secure is at best an afterthought.

Now, if someone could try and run guests on this turd and report whether
this works correctly or not, that'd be an interesting data point.
Because in the absence of a TEE running on the secure side,
virtualization is basically the only thing you gain from running on the
non-secure side.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...