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

[Mr . Fülöp]

Thanks! I will try it out and let you know the result!

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Icenowy Zheng]

于 2018年2月13日 GMT+08:00 上午4:25:35, "Mr. Fülöp"  写到:
>Hi Icenowy,
>
>Thank you for your reply!
>I worked much and got this close, so I really want to make this thing
>work 
>:) 
>Do you have any suggestions/patches/directions? This "ugly hack" is
>there 
>somewhere? :)

The Linux version of this hack is at [1].

[1] https://github.com/wens/linux/tree/gic-secure-workaround

>
>I think the issue resides on the "switching" to the next cpu...
>
>Thank you in advance!
>
>Alex
>
>
>On Wednesday, February 7, 2018 at 8:04:41 PM UTC+2, Icenowy Zheng
>wrote:
>>
>>
>>
>> 于 2018年2月8日 GMT+08:00 上午2:02:39, "Mr. Fülöp" > > 写到: 
>> >Hi Guys, 
>> > 
>> >I think I reached a dead end... 
>> >Can you please tell me why does it hang on "(XEN) Bringing up CPU1"?
>
>> >I compiled many xen version, but my feeling is that in the u-boot is
>
>> >sth. that makes Xen hang... 
>> > 
>> >Any suggestions? 
>> > 
>> >Thank you in advance! 
>> > 
>> >= 
>> > 
>> > Xen 4.11-unstable 
>> >(XEN) Xen version 4.11-unstable (@) (arm-linux-gnueabi-gcc (Debian 
>> >6.1.1-9) 6.1.1 20160705) debug=y  Fri Feb  2 16:48:36 UTC 2018 
>> >(XEN) Latest ChangeSet: Fri Nov 3 16:43:02 2017 + git:4c7e478 
>> >(XEN) Processor: 410fc075: "ARM Limited", variant: 0x0, part 0xc07,
>rev 
>> >0x5 
>> >(XEN) 32-bit Execution: 
>> >(XEN)   Processor Features: 1131:00011011 
>> >(XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 ThumbEE
>Jazelle 
>> >(XEN) Extensions: GenericTimer Security 
>> >(XEN)   Debug Features: 02010555 
>> >(XEN)   Auxiliary Features:  
>> >(XEN)   Memory Model Features: 10101105 4000 0124 02102211 
>> >(XEN)  ISA Features: 02101110 13112111 21232041 2131 10011142 
>> > 
>> >(XEN) Using PSCI-0.1 for SMP bringup 
>> >(XEN) SMP: Allowing 8 CPUs 
>> >(XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 24000 KHz 
>> >(XEN) GICv2 initialization: 
>> >(XEN) gic_dist_addr=01c81000 
>> >(XEN) gic_cpu_addr=01c82000 
>> >(XEN) gic_hyp_addr=01c84000 
>> >(XEN) gic_vcpu_addr=01c86000 
>> >(XEN) gic_maintenance_irq=25 
>> >(XEN) GICv2: 224 lines, 8 cpus, secure (IID 0200143b). 
>> >(XEN) Using scheduler: SMP Credit Scheduler (credit) 
>> >(XEN) Allocated console ring of 64 KiB. 
>> >(XEN) VFP implementer 0x41 architecture 2 part 0x30 variant 0x7 rev
>0x5 
>> >(XEN) Bringing up CPU1- HERE IT HANGS - 
>>
>> I think you just met the bug we mentioned in this thread. 
>> With this patchset applied a Linux kernel will also hang 
>> here without ugly hack. 
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Mr . Fülöp]

Hi Icenowy,

Thank you for your reply!
I worked much and got this close, so I really want to make this thing work 
:) 
Do you have any suggestions/patches/directions? This "ugly hack" is there 
somewhere? :)

I think the issue resides on the "switching" to the next cpu...

Thank you in advance!

Alex


On Wednesday, February 7, 2018 at 8:04:41 PM UTC+2, Icenowy Zheng wrote:
>
>
>
> 于 2018年2月8日 GMT+08:00 上午2:02:39, "Mr. Fülöp"  > 写到: 
> >Hi Guys, 
> > 
> >I think I reached a dead end... 
> >Can you please tell me why does it hang on "(XEN) Bringing up CPU1"? 
> >I compiled many xen version, but my feeling is that in the u-boot is 
> >sth. that makes Xen hang... 
> > 
> >Any suggestions? 
> > 
> >Thank you in advance! 
> > 
> >= 
> > 
> > Xen 4.11-unstable 
> >(XEN) Xen version 4.11-unstable (@) (arm-linux-gnueabi-gcc (Debian 
> >6.1.1-9) 6.1.1 20160705) debug=y  Fri Feb  2 16:48:36 UTC 2018 
> >(XEN) Latest ChangeSet: Fri Nov 3 16:43:02 2017 + git:4c7e478 
> >(XEN) Processor: 410fc075: "ARM Limited", variant: 0x0, part 0xc07, rev 
> >0x5 
> >(XEN) 32-bit Execution: 
> >(XEN)   Processor Features: 1131:00011011 
> >(XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 ThumbEE Jazelle 
> >(XEN) Extensions: GenericTimer Security 
> >(XEN)   Debug Features: 02010555 
> >(XEN)   Auxiliary Features:  
> >(XEN)   Memory Model Features: 10101105 4000 0124 02102211 
> >(XEN)  ISA Features: 02101110 13112111 21232041 2131 10011142 
> > 
> >(XEN) Using PSCI-0.1 for SMP bringup 
> >(XEN) SMP: Allowing 8 CPUs 
> >(XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 24000 KHz 
> >(XEN) GICv2 initialization: 
> >(XEN) gic_dist_addr=01c81000 
> >(XEN) gic_cpu_addr=01c82000 
> >(XEN) gic_hyp_addr=01c84000 
> >(XEN) gic_vcpu_addr=01c86000 
> >(XEN) gic_maintenance_irq=25 
> >(XEN) GICv2: 224 lines, 8 cpus, secure (IID 0200143b). 
> >(XEN) Using scheduler: SMP Credit Scheduler (credit) 
> >(XEN) Allocated console ring of 64 KiB. 
> >(XEN) VFP implementer 0x41 architecture 2 part 0x30 variant 0x7 rev 0x5 
> >(XEN) Bringing up CPU1- HERE IT HANGS - 
>
> I think you just met the bug we mentioned in this thread. 
> With this patchset applied a Linux kernel will also hang 
> here without ugly hack. 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Icenowy Zheng]

于 2018年2月8日 GMT+08:00 上午2:02:39, "Mr. Fülöp"  写到:
>Hi Guys,
>
>I think I reached a dead end...
>Can you please tell me why does it hang on "(XEN) Bringing up CPU1"?
>I compiled many xen version, but my feeling is that in the u-boot is
>sth. that makes Xen hang...
>
>Any suggestions?
>
>Thank you in advance!
>
>=
>
> Xen 4.11-unstable
>(XEN) Xen version 4.11-unstable (@) (arm-linux-gnueabi-gcc (Debian
>6.1.1-9) 6.1.1 20160705) debug=y  Fri Feb  2 16:48:36 UTC 2018
>(XEN) Latest ChangeSet: Fri Nov 3 16:43:02 2017 + git:4c7e478
>(XEN) Processor: 410fc075: "ARM Limited", variant: 0x0, part 0xc07, rev
>0x5
>(XEN) 32-bit Execution:
>(XEN)   Processor Features: 1131:00011011
>(XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 ThumbEE Jazelle
>(XEN) Extensions: GenericTimer Security
>(XEN)   Debug Features: 02010555
>(XEN)   Auxiliary Features: 
>(XEN)   Memory Model Features: 10101105 4000 0124 02102211
>(XEN)  ISA Features: 02101110 13112111 21232041 2131 10011142
>
>(XEN) Using PSCI-0.1 for SMP bringup
>(XEN) SMP: Allowing 8 CPUs
>(XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 24000 KHz
>(XEN) GICv2 initialization:
>(XEN) gic_dist_addr=01c81000
>(XEN) gic_cpu_addr=01c82000
>(XEN) gic_hyp_addr=01c84000
>(XEN) gic_vcpu_addr=01c86000
>(XEN) gic_maintenance_irq=25
>(XEN) GICv2: 224 lines, 8 cpus, secure (IID 0200143b).
>(XEN) Using scheduler: SMP Credit Scheduler (credit)
>(XEN) Allocated console ring of 64 KiB.
>(XEN) VFP implementer 0x41 architecture 2 part 0x30 variant 0x7 rev 0x5
>(XEN) Bringing up CPU1- HERE IT HANGS -

I think you just met the bug we mentioned in this thread.
With this patchset applied a Linux kernel will also hang
here without ugly hack.

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Mr . Fülöp]

Hi Guys,

I think I reached a dead end...
Can you please tell me why does it hang on "(XEN) Bringing up CPU1"?
I compiled many xen version, but my feeling is that in the u-boot is sth. that 
makes Xen hang...

Any suggestions?

Thank you in advance!

=

 Xen 4.11-unstable
(XEN) Xen version 4.11-unstable (@) (arm-linux-gnueabi-gcc (Debian 6.1.1-9) 
6.1.1 20160705) debug=y  Fri Feb  2 16:48:36 UTC 2018
(XEN) Latest ChangeSet: Fri Nov 3 16:43:02 2017 + git:4c7e478
(XEN) Processor: 410fc075: "ARM Limited", variant: 0x0, part 0xc07, rev 0x5
(XEN) 32-bit Execution:
(XEN)   Processor Features: 1131:00011011
(XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 ThumbEE Jazelle
(XEN) Extensions: GenericTimer Security
(XEN)   Debug Features: 02010555
(XEN)   Auxiliary Features: 
(XEN)   Memory Model Features: 10101105 4000 0124 02102211
(XEN)  ISA Features: 02101110 13112111 21232041 2131 10011142 
(XEN) Using PSCI-0.1 for SMP bringup
(XEN) SMP: Allowing 8 CPUs
(XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 24000 KHz
(XEN) GICv2 initialization:
(XEN) gic_dist_addr=01c81000
(XEN) gic_cpu_addr=01c82000
(XEN) gic_hyp_addr=01c84000
(XEN) gic_vcpu_addr=01c86000
(XEN) gic_maintenance_irq=25
(XEN) GICv2: 224 lines, 8 cpus, secure (IID 0200143b).
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Allocated console ring of 64 KiB.
(XEN) VFP implementer 0x41 architecture 2 part 0x30 variant 0x7 rev 0x5
(XEN) Bringing up CPU1- HERE IT HANGS -

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Jagan Teki]

On Monday 05 February 2018 09:05 PM, Mr. Fülöp wrote:

Thank you all for your help! I really appreciate your feedback!

Following your advice I booted XEN ... Yeeeyyy
BUT got stuck here:

  Xen 4.11-unstable
(XEN) Xen version 4.11-unstable (@) (arm-linux-gnueabi-gcc (Debian 6.1.1-9) 
6.1.1 20160705) debug=y  Fri Feb  2 16:48:36 UTC 2018
(XEN) Latest ChangeSet: Fri Nov 3 16:43:02 2017 + git:4c7e478
(XEN) Processor: 410fc075: "ARM Limited", variant: 0x0, part 0xc07, rev 0x5
(XEN) 32-bit Execution:
(XEN)   Processor Features: 1131:00011011
(XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 ThumbEE Jazelle
(XEN) Extensions: GenericTimer Security
(XEN)   Debug Features: 02010555
(XEN)   Auxiliary Features: 
(XEN)   Memory Model Features: 10101105 4000 0124 02102211
(XEN)  ISA Features: 02101110 13112111 21232041 2131 10011142 
(XEN) Using PSCI-0.1 for SMP bringup
(XEN) SMP: Allowing 8 CPUs
(XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 24000 KHz
(XEN) GICv2 initialization:
(XEN) gic_dist_addr=01c81000
(XEN) gic_cpu_addr=01c82000
(XEN) gic_hyp_addr=01c84000
(XEN) gic_vcpu_addr=01c86000
(XEN) gic_maintenance_irq=25
(XEN) GICv2: 224 lines, 8 cpus, secure (IID 0200143b).
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Allocated console ring of 64 KiB.
(XEN) VFP implementer 0x41 architecture 2 part 0x30 variant 0x7 rev 0x5
(XEN) Bringing up CPU1

I am trying to recompile Xen and see if I can get further...
I will keep you updated with my progress... :)

Please let me know your opinion on this!
Is it feasible?


Is OTG cable connected on board? can you try to unplug it and use DCIN.

--
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Mr . Fülöp]

Thank you all for your help! I really appreciate your feedback!

Following your advice I booted XEN ... Yeeeyyy 
BUT got stuck here:

 Xen 4.11-unstable
(XEN) Xen version 4.11-unstable (@) (arm-linux-gnueabi-gcc (Debian 6.1.1-9) 
6.1.1 20160705) debug=y  Fri Feb  2 16:48:36 UTC 2018
(XEN) Latest ChangeSet: Fri Nov 3 16:43:02 2017 + git:4c7e478
(XEN) Processor: 410fc075: "ARM Limited", variant: 0x0, part 0xc07, rev 0x5
(XEN) 32-bit Execution:
(XEN)   Processor Features: 1131:00011011
(XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 ThumbEE Jazelle
(XEN) Extensions: GenericTimer Security
(XEN)   Debug Features: 02010555
(XEN)   Auxiliary Features: 
(XEN)   Memory Model Features: 10101105 4000 0124 02102211
(XEN)  ISA Features: 02101110 13112111 21232041 2131 10011142 
(XEN) Using PSCI-0.1 for SMP bringup
(XEN) SMP: Allowing 8 CPUs
(XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 24000 KHz
(XEN) GICv2 initialization:
(XEN) gic_dist_addr=01c81000
(XEN) gic_cpu_addr=01c82000
(XEN) gic_hyp_addr=01c84000
(XEN) gic_vcpu_addr=01c86000
(XEN) gic_maintenance_irq=25
(XEN) GICv2: 224 lines, 8 cpus, secure (IID 0200143b).
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Allocated console ring of 64 KiB.
(XEN) VFP implementer 0x41 architecture 2 part 0x30 variant 0x7 rev 0x5
(XEN) Bringing up CPU1 

I am trying to recompile Xen and see if I can get further...
I will keep you updated with my progress... :)

Please let me know your opinion on this!
Is it feasible?

Thank you guys!

Alex

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Jagan Teki]

On Mon, Feb 5, 2018 at 7:05 PM, Mr. Fülöp  wrote:
> This is the loop I was talking about:
>
> U-Boot 2018.03-rc1-00078-gb215307-dirty (Feb 05 2018 - 12:50:50 +)
>
> Loading Environment from FAT... Unable to use mmc 1:0... Failed (-5)
> Loading Environment from MMC... *** Warning - bad CRC, using default 
> environment
>
> Failed (-5)
> In:serial
> Out:   serial
> Err:   serial
> Net:   No ethernet found.
> starting USB...
> USB0:   data abort

Check with this patch [1]

[1] https://patchwork.ozlabs.org/patch/869304/

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Mr . Fülöp]

This is the loop I was talking about:

U-Boot 2018.03-rc1-00078-gb215307-dirty (Feb 05 2018 - 12:50:50 +)

Loading Environment from FAT... Unable to use mmc 1:0... Failed (-5)
Loading Environment from MMC... *** Warning - bad CRC, using default environment

Failed (-5)
In:serial
Out:   serial
Err:   serial
Net:   No ethernet found.
starting USB...
USB0:   data abort
pc : []  lr : []
reloc pc : [<4a01ba3a>]lr : [<4a01ba1d>]
sp : bbf4ec40  ip : bbf584ec fp : 0002
r10: bffb577c  r9 : bbf50ee8 r8 : 
r7 :   r6 : bbf5773c r5 : bffb39a4  r4 : bbf57550
r3 :   r2 : 01c4 r1 : 3f8f  r0 : 
Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
Resetting CPU ...



Any hints? Thank you!

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Mr . Fülöp]

Hello!

First of all I would like to thank you all for your amazing contribution! More 
I dive into understanding the kernel, more I appreciate your work and more I 
learn.

As Marc Zyngier said:
"Now, if someone could try and run guests on this turd and report whether 
this works correctly or not, that'd be an interesting data point. 
Because in the absence of a TEE running on the secure side, 
virtualization is basically the only thing you gain from running on the 
non-secure side. "

I am that "someone" who wants to run Xen on a A83T chipset. I managed to build 
the latest kernel 4.15, the Xen hypervisor and got stuck on compiling the 
u-boot kernel with virtualization, HYP enabled and boot non secure:

 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 

Not knowing if A83T supports virtualization and the above mentioned features, I 
tried to enable these in Kconfig and build the latest u-boot kernel. 
Unfortunatelly even if it compiled, I have a strange loop at boot...I think it 
is related to the CPU allocation...
 
  
As you can see I am a noob in terms of kernel hacking, but I want, with your 
help, to achieve this implementation of Xen.

In this regard I would appreciate your help and guidance.

Can you provide the files/patches and/or a tutorial on how I could accomplish 
my goal?


Many thanks!


Alex

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Maxime Ripard]

On Sun, Jul 02, 2017 at 04:27:52PM +0100, Marc Zyngier wrote:
> It definitely requires extra testing (booting the kernel hardly shakes
> the GIC), but that's certainly encouraging. Can you run some
> significant workload in a guest (kernel compilation, hackbench) and
> report the results?

Also, enabling the various IPs we have pending (like ethernet) would
be helpful I guess. So far, we just have the UARTs enabled, which are
not really going to stress the system either :)

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

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

[Maxime Ripard]

Hi,

On Sun, Jul 02, 2017 at 04:40:20PM +0100, André Przywara wrote:
> On 02/07/17 15:17, Maxime Ripard wrote:
> > On Wed, Jun 07, 2017 at 03:06:55PM +0100, Marc Zyngier wrote:
> >>> If that is so fundamentally broken that this is the only benefit, I
> >>> guess we might as well use some old-style SMP ops.
> >>
> >> Broken, for sure. Which is why I'm asking about the benefits of running
> >> non-secure on something that has evidently been very badly integrated,
> >> and for which non-secure is at best an afterthought.
> >>
> >> Now, if someone could try and run guests on this turd and report whether
> >> this works correctly or not, that'd be an interesting data point.
> >> Because in the absence of a TEE running on the secure side,
> >> virtualization is basically the only thing you gain from running on the
> >> non-secure side.
> > 
> > I just tried running Xen on it, with an adjustment similar to what
> > Chen-Yu made in the kernel.
> > 
> > It fails at boot, and stops with:
> > (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER4
> > (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER8
> > (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER12
> > (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER16
> > (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER20
> > (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER24
> > (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER0
> 
> Those messages are normal and happen on every machine. The Xen VGIC
> implementation cannot clear the active flag [1] (for more complex
> reasons), and fortunately Linux and other OSes actually don't need it,
> so we get away with it. What the kernel does here is to make sure that
> no IRQ is active, which is basically a NOP on a pristine and just
> initialized (V)GIC.

Ok.

> But you said that it stopped at boot? Are you sure that your Xen setup
> works in the first place? Xen on A20 seems to be somewhat supported, by
> maybe there is some other A83T speciality that gets in the way?

It's basically stalled, yes, and didn't start dom0. I tested Xen in
the past on an A33, and it worked like a charm, but it might very well
be a PEBKAC.

> A more reliable and easier to debug test would be KVM, I guess.
> You can use kvmtool[2] instead of QEMU if that is too complex to setup:
> $ lkvm run -k zImage -p console=ttyS0
> gives you a shell in a guest, if you want to have a proper rootfs:
> $ lkvm run -k zImage -d somerootfs.img -p "console=ttyS0 root=/dev/vda"

I didn't know kvmtool, thanks for the tip.

Icenowy seems to had it running, so I guess we can just focus on KVM
for now.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

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

[André Przywara]

On 02/07/17 15:17, Maxime Ripard wrote:

Hi,

> On Wed, Jun 07, 2017 at 03:06:55PM +0100, Marc Zyngier wrote:
>>> If that is so fundamentally broken that this is the only benefit, I
>>> guess we might as well use some old-style SMP ops.
>>
>> Broken, for sure. Which is why I'm asking about the benefits of running
>> non-secure on something that has evidently been very badly integrated,
>> and for which non-secure is at best an afterthought.
>>
>> Now, if someone could try and run guests on this turd and report whether
>> this works correctly or not, that'd be an interesting data point.
>> Because in the absence of a TEE running on the secure side,
>> virtualization is basically the only thing you gain from running on the
>> non-secure side.
> 
> I just tried running Xen on it, with an adjustment similar to what
> Chen-Yu made in the kernel.
> 
> It fails at boot, and stops with:
> (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER4
> (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER8
> (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER12
> (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER16
> (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER20
> (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER24
> (XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER0

Those messages are normal and happen on every machine. The Xen VGIC
implementation cannot clear the active flag [1] (for more complex
reasons), and fortunately Linux and other OSes actually don't need it,
so we get away with it. What the kernel does here is to make sure that
no IRQ is active, which is basically a NOP on a pristine and just
initialized (V)GIC.

But you said that it stopped at boot? Are you sure that your Xen setup
works in the first place? Xen on A20 seems to be somewhat supported, by
maybe there is some other A83T speciality that gets in the way?

A more reliable and easier to debug test would be KVM, I guess.
You can use kvmtool[2] instead of QEMU if that is too complex to setup:
$ lkvm run -k zImage -p console=ttyS0
gives you a shell in a guest, if you want to have a proper rootfs:
$ lkvm run -k zImage -d somerootfs.img -p "console=ttyS0 root=/dev/vda"

Cheers,
Andre.

[1]
https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/arm/vgic-v2.c;hb=HEAD#l487
[2] git://git.kernel.org/pub/scm/linux/kernel/git/will/kvmtool.git
(just checkout and "make" on the target)

> 
> It looks like it won't be easy to support. I guess we could just go
> for smp_ops, and if someone really cares one day about it, we'll
> always have the option to support it then.
> 
> Maxime
> 

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Marc Zyngier]

On Sun, 2 Jul 2017 20:36:04 +0800
 wrote:

> 在 2017-07-02 19:22，Marc Zyngier 写道：
> > On Sun, 2 Jul 2017 15:08:12 +0800
> >  wrote:
> >   
> >> 在 2017-06-23 21:50，Chen-Yu Tsai 写道：  
> >> > On Fri, Jun 23, 2017 at 9:39 PM,   wrote:  
> >> >> 在 2017-06-23 21:35，Maxime Ripard 写道：  
> >> >>>
> >> >>> On Fri, Jun 23, 2017 at 09:24:25PM +0800, icen...@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
> >>  > >  写到:  
> >>  > > > On 07/06/17 08:00, Chen-Yu Tsai wrote:  
> >>  > > > > On Wed, Jun 7, 2017 at 2:50 PM, Maxime Ripard
> >>  > > > >  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
> >>  > > > > > >   
> >>  > > > wrote:  
> >>  > > > > > > >
> >>  > > > > > > >
> >>  > > > > > > > 于 2017年6月7日 GMT+08:00 上午11:36:27, Chen-Yu
> >>  > > > > > > > Tsai  写到:  
> >>  > > > > > > > > On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng
> >>  > > > > > > > >   
> >>  > > > 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 
> >>  > > > > > > > > > ---
> >>  > > > > > > > > >  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  
> >>  > > > 

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

[Maxime Ripard]

On Wed, Jun 07, 2017 at 03:06:55PM +0100, Marc Zyngier wrote:
> > If that is so fundamentally broken that this is the only benefit, I
> > guess we might as well use some old-style SMP ops.
> 
> Broken, for sure. Which is why I'm asking about the benefits of running
> non-secure on something that has evidently been very badly integrated,
> and for which non-secure is at best an afterthought.
> 
> Now, if someone could try and run guests on this turd and report whether
> this works correctly or not, that'd be an interesting data point.
> Because in the absence of a TEE running on the secure side,
> virtualization is basically the only thing you gain from running on the
> non-secure side.

I just tried running Xen on it, with an adjustment similar to what
Chen-Yu made in the kernel.

It fails at boot, and stops with:
(XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER4
(XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER8
(XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER12
(XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER16
(XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER20
(XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER24
(XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER0

It looks like it won't be easy to support. I guess we could just go
for smp_ops, and if someone really cares one day about it, we'll
always have the option to support it then.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

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

[icenowy]

在 2017-07-02 19:22，Marc Zyngier 写道：

On Sun, 2 Jul 2017 15:08:12 +0800
 wrote:


在 2017-06-23 21:50，Chen-Yu Tsai 写道：
> On Fri, Jun 23, 2017 at 9:39 PM,   wrote:
>> 在 2017-06-23 21:35，Maxime Ripard 写道：
>>>
>>> On Fri, Jun 23, 2017 at 09:24:25PM +0800, icen...@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
 > >  写到:
 > > > On 07/06/17 08:00, Chen-Yu Tsai wrote:
 > > > > On Wed, Jun 7, 2017 at 2:50 PM, Maxime Ripard
 > > > >  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
 > > > > > > 
 > > > wrote:
 > > > > > > >
 > > > > > > >
 > > > > > > > 于 2017年6月7日 GMT+08:00 上午11:36:27, Chen-Yu
 > > > > > > > Tsai  写到:
 > > > > > > > > On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng
 > > > > > > > > 
 > > > 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 
 > > > > > > > > > ---
 > > > > > > > > >  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 

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

[Marc Zyngier]

On Sun, 2 Jul 2017 15:08:12 +0800
 wrote:

> 在 2017-06-23 21:50，Chen-Yu Tsai 写道：
> > On Fri, Jun 23, 2017 at 9:39 PM,   wrote:  
> >> 在 2017-06-23 21:35，Maxime Ripard 写道：  
> >>> 
> >>> On Fri, Jun 23, 2017 at 09:24:25PM +0800, icen...@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
>  > >  写到:  
>  > > > On 07/06/17 08:00, Chen-Yu Tsai wrote:  
>  > > > > On Wed, Jun 7, 2017 at 2:50 PM, Maxime Ripard
>  > > > >  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
>  > > > > > >   
>  > > > wrote:  
>  > > > > > > >
>  > > > > > > >
>  > > > > > > > 于 2017年6月7日 GMT+08:00 上午11:36:27, Chen-Yu
>  > > > > > > > Tsai  写到:  
>  > > > > > > > > On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng
>  > > > > > > > >   
>  > > > 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 
>  > > > > > > > > > ---
>  > > > > > > > > >  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 

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

[icenowy]

在 2017-06-23 21:50，Chen-Yu Tsai 写道：

On Fri, Jun 23, 2017 at 9:39 PM,   wrote:

在 2017-06-23 21:35，Maxime Ripard 写道：


On Fri, Jun 23, 2017 at 09:24:25PM +0800, icen...@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
> >  写到:
> > > On 07/06/17 08:00, Chen-Yu Tsai wrote:
> > > > On Wed, Jun 7, 2017 at 2:50 PM, Maxime Ripard
> > > >  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
> > > > > > 
> > > wrote:
> > > > > > >
> > > > > > >
> > > > > > > 于 2017年6月7日 GMT+08:00 上午11:36:27, Chen-Yu
> > > > > > > Tsai  写到:
> > > > > > > > On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng
> > > > > > > > 
> > > 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 
> > > > > > > > > ---
> > > > > > > > >  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 

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

[Chen-Yu Tsai]

On Fri, Jun 23, 2017 at 9:39 PM,   wrote:
> 在 2017-06-23 21:35，Maxime Ripard 写道：
>>
>> On Fri, Jun 23, 2017 at 09:24:25PM +0800, icen...@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
>>> > >  写到:
>>> > > > On 07/06/17 08:00, Chen-Yu Tsai wrote:
>>> > > > > On Wed, Jun 7, 2017 at 2:50 PM, Maxime Ripard
>>> > > > >  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
>>> > > > > > > 
>>> > > > wrote:
>>> > > > > > > >
>>> > > > > > > >
>>> > > > > > > > 于 2017年6月7日 GMT+08:00 上午11:36:27, Chen-Yu
>>> > > > > > > > Tsai  写到:
>>> > > > > > > > > On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng
>>> > > > > > > > > 
>>> > > > 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 
>>> > > > > > > > > > ---
>>> > > > > > > > > >  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 

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

[icenowy]

在 2017-06-23 21:35，Maxime Ripard 写道：

On Fri, Jun 23, 2017 at 09:24:25PM +0800, icen...@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
> >  写到:
> > > On 07/06/17 08:00, Chen-Yu Tsai wrote:
> > > > On Wed, Jun 7, 2017 at 2:50 PM, Maxime Ripard
> > > >  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 
> > > wrote:
> > > > > > >
> > > > > > >
> > > > > > > 于 2017年6月7日 GMT+08:00 上午11:36:27, Chen-Yu
> > > > > > > Tsai  写到:
> > > > > > > > On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng 
> > > 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 
> > > > > > > > > ---
> > > > > > > > >  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


--
You received this message 

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

[Maxime Ripard]

On Fri, Jun 23, 2017 at 09:24:25PM +0800, icen...@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
> > >  写到:
> > > > On 07/06/17 08:00, Chen-Yu Tsai wrote:
> > > > > On Wed, Jun 7, 2017 at 2:50 PM, Maxime Ripard
> > > > >  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 
> > > > wrote:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 于 2017年6月7日 GMT+08:00 上午11:36:27, Chen-Yu
> > > > > > > > Tsai  写到:
> > > > > > > > > On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng 
> > > > > > > > > 
> > > > 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 
> > > > > > > > > > ---
> > > > > > > > > >  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.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

-- 
You received this 

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

[icenowy]

在 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  
写到:

On 07/06/17 08:00, Chen-Yu Tsai wrote:

On Wed, Jun 7, 2017 at 2:50 PM, Maxime Ripard
 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 

wrote:



于 2017年6月7日 GMT+08:00 上午11:36:27, Chen-Yu Tsai  
写到:

On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng 

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


--
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Marc Zyngier]

On 07/06/17 14:04, Maxime Ripard wrote:
> On Wed, Jun 07, 2017 at 01:51:48PM +0100, Marc Zyngier wrote:
>> On 07/06/17 13:12, Icenowy Zheng wrote:
>>>
>>>
>>> 于 2017年6月7日 GMT+08:00 下午8:11:12, Marc Zyngier  写到:
 On 07/06/17 08:00, Chen-Yu Tsai wrote:
> On Wed, Jun 7, 2017 at 2:50 PM, Maxime Ripard
>  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 
 wrote:


 于 2017年6月7日 GMT+08:00 上午11:36:27, Chen-Yu Tsai  写到:
> On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng 
 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 
>> ---
>>  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.
> 
> The initial idea was to use PSCI for the core bringup, which afaik
> requires Linux to run non-secure, right?

The SMC instruction is available from both PL1 exception levels, so
calling into PSCI from secure should be possible (assuming your PSCI
code is driven from Monitor mode).

> If that is so fundamentally broken that this is the only benefit, I
> guess we might as well use some old-style SMP ops.

Broken, for sure. Which is why I'm asking about the benefits of running
non-secure on something that has evidently been very badly integrated,
and for which non-secure is at best an afterthought.

Now, if someone could try and run guests on this turd and report whether
this works correctly or not, that'd be an interesting data point.
Because in the absence of a TEE running on the secure side,
virtualization is basically the only thing you gain from running on the
non-secure side.

Thanks,

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

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To 

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

[Maxime Ripard]

On Wed, Jun 07, 2017 at 01:51:48PM +0100, Marc Zyngier wrote:
> On 07/06/17 13:12, Icenowy Zheng wrote:
> > 
> > 
> > 于 2017年6月7日 GMT+08:00 下午8:11:12, Marc Zyngier  写到:
> >> On 07/06/17 08:00, Chen-Yu Tsai wrote:
> >>> On Wed, Jun 7, 2017 at 2:50 PM, Maxime Ripard
> >>>  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 
> >> wrote:
> >>
> >>
> >> 于 2017年6月7日 GMT+08:00 上午11:36:27, Chen-Yu Tsai  写到:
> >>> On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng 
> >> 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 
>  ---
>   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.

The initial idea was to use PSCI for the core bringup, which afaik
requires Linux to run non-secure, right?

If that is so fundamentally broken that this is the only benefit, I
guess we might as well use some old-style SMP ops.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

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

[Marc Zyngier]

On 07/06/17 13:12, Icenowy Zheng wrote:
> 
> 
> 于 2017年6月7日 GMT+08:00 下午8:11:12, Marc Zyngier  写到:
>> On 07/06/17 08:00, Chen-Yu Tsai wrote:
>>> On Wed, Jun 7, 2017 at 2:50 PM, Maxime Ripard
>>>  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 
>> wrote:
>>
>>
>> 于 2017年6月7日 GMT+08:00 上午11:36:27, Chen-Yu Tsai  写到:
>>> On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng 
>> 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 
 ---
  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...

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [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  写到:
>On 07/06/17 08:00, Chen-Yu Tsai wrote:
>> On Wed, Jun 7, 2017 at 2:50 PM, Maxime Ripard
>>  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 
>wrote:
>
>
> 于 2017年6月7日 GMT+08:00 上午11:36:27, Chen-Yu Tsai  写到:
>> On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng 
>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 
>>> ---
>>>  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.

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Marc Zyngier]

On 07/06/17 08:00, Chen-Yu Tsai wrote:
> On Wed, Jun 7, 2017 at 2:50 PM, Maxime Ripard
>  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  wrote:


 于 2017年6月7日 GMT+08:00 上午11:36:27, Chen-Yu Tsai  写到:
> On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng  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 
>> ---
>>  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?

> 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.
-- 
Jazz is not dead. It just smells funny...

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Chen-Yu Tsai]

On Wed, Jun 7, 2017 at 2:50 PM, Maxime Ripard
 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  wrote:
>> >
>> >
>> > 于 2017年6月7日 GMT+08:00 上午11:36:27, Chen-Yu Tsai  写到:
>> >>On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng  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 
>> >>> ---
>> >>>  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.
>
> 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

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Icenowy Zheng]

于 2017年6月7日 GMT+08:00 下午2:50:36, Maxime Ripard 
 写到:
>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 
>wrote:
>> >
>> >
>> > 于 2017年6月7日 GMT+08:00 上午11:36:27, Chen-Yu Tsai  写到:
>> >>On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng 
>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 
>> >>> ---
>> >>>  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.
>
>Is that on all revisions, or just the revB ?

All revisions, and even all SoCs after sun8iw6 that we
know, although the GIC issue seems to only show on
multi-cluster SoCs.

The A83T RevA/RevB difference is about CPU0/CPU4 (the first
CPUs in both clusters) bring up.

>
>Maxime

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Maxime Ripard]

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  wrote:
> >
> >
> > 于 2017年6月7日 GMT+08:00 上午11:36:27, Chen-Yu Tsai  写到:
> >>On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng  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 
> >>> ---
> >>>  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.

Is that on all revisions, or just the revB ?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

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

[Chen-Yu Tsai]

On Wed, Jun 7, 2017 at 11:40 AM, Icenowy Zheng  wrote:
>
>
> 于 2017年6月7日 GMT+08:00 上午11:36:27, Chen-Yu Tsai  写到:
>>On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng  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 
>>> ---
>>>  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.

ChenYu

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Icenowy Zheng]

于 2017年6月7日 GMT+08:00 上午11:36:27, Chen-Yu Tsai  写到:
>On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng  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 
>> ---
>>  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.

>
>ChenYu

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Chen-Yu Tsai]

On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zheng  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 
> ---
>  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.

ChenYu

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.