在 2017-06-07 20:51，Marc Zyngier 写道：
On 07/06/17 13:12, Icenowy Zheng wrote:
于 2017年6月7日 GMT+08:00 下午8:11:12, Marc Zyngier <marc.zyng...@arm.com>
写到:
On 07/06/17 08:00, Chen-Yu Tsai wrote:
On Wed, Jun 7, 2017 at 2:50 PM, Maxime Ripard
<maxime.rip...@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 <icen...@aosc.io>
wrote:
于 2017年6月7日 GMT+08:00 上午11:36:27, Chen-Yu Tsai <w...@csie.org>
写到:
On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng <icen...@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 <icen...@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.
Maybe we should then use legacy SMP bringup method (code in kernel)
rather than PSCI?
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
