在 2017-06-23 21:35，Maxime Ripard 写道：
On Fri, Jun 23, 2017 at 09:24:25PM +0800, icenowy@aosc.io wrote:
在 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.zyngier@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@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_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?
I guess it all depends on the answer to Marc's question. If virtualization doesn't work, then we don't have any incentive anymore to use PSCI and that would be a sensible option, yes.
I remember non-secure is a dependency for virtualization (HYP mode).
So if we do not do the workaround on GIC, we won't have stable non-secure, then we won't have HYP mode, then we can drop PSCI.
Maxime
-- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com