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

Marc Zyngier marc.zyngier at arm.com
Wed Jun 7 12:51:48 UTC 2017


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.

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


More information about the U-Boot mailing list