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

[Icenowy Zheng]

于 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.

>
>> 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.