On Wed, Jun 7, 2017 at 2:50 PM, Maxime Ripard maxime.ripard@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@aosc.io wrote:
于 2017年6月7日 GMT+08:00 上午11:36:27, Chen-Yu Tsai wens@csie.org 写到:
On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng icenowy@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@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_NONSECselect CPU_V7_HAS_VIRTselect ARCH_SUPPORT_PSCI select SUNXI_GEN_SUN6I select SUPPORT_SPLselect ARMV7_BOOT_SEC_DEFAULT if OLD_SUNXI_KERNEL_COMPATThe 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.
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.
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.
Regards ChenYu