Re: [linux-sunxi] [RFC PATCH 8/8] sunxi: enable PSCI for A83T SoC
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
于 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
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
于 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
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
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
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
On Mon, Feb 5, 2018 at 7:05 PM, Mr. Fülöpwrote: > 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
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
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
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
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
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
On Sun, 2 Jul 2017 20:36:04 +0800wrote: > 在 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
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
在 2017-07-02 19:22,Marc Zyngier 写道: On Sun, 2 Jul 2017 15:08:12 +0800wrote: 在 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
On Sun, 2 Jul 2017 15:08:12 +0800wrote: > 在 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
在 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
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
在 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
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
在 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
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
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
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
于 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
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
On Wed, Jun 7, 2017 at 2:50 PM, Maxime Ripardwrote: > 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
于 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
On Wed, Jun 07, 2017 at 11:47:24AM +0800, Chen-Yu Tsai wrote: > On Wed, Jun 7, 2017 at 11:40 AM, Icenowy Zhengwrote: > > > > > > 于 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
On Wed, Jun 7, 2017 at 11:40 AM, Icenowy Zhengwrote: > > > 于 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
于 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
On Wed, Jun 7, 2017 at 8:47 AM, Icenowy Zhengwrote: > 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.
[linux-sunxi] [RFC PATCH 8/8] sunxi: enable PSCI for A83T SoC
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 config MACH_SUN8I_H3 bool "sun8i (Allwinner H3)" -- 2.12.2 -- 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.