* Kexec: BE kernel on ARM VE TC2 @ 2013-08-05 12:12 Vijay Kilari 2013-08-05 15:28 ` Ben Dooks 2013-08-08 21:50 ` Will Deacon 0 siblings, 2 replies; 13+ messages in thread From: Vijay Kilari @ 2013-08-05 12:12 UTC (permalink / raw) To: linux-arm-kernel Hi Will, I am trying to make kexec work on BE kernel on ARM VE TC2. First, to make KEXEC work with SMP on ARM VE TC2 board, I set nr_cpus=2 (i.e boot only A15's) this works with LE kernel. However, I made below changes to make KEXEC work for BE kernel. my question is: why delay is required for board to reboot with kexec?. Is it platform issue?. diff --git a/arch/arm/kernel /machine_kexec.c b/arch/arm/kernel/machine_kexec.c index 4fb074c..0fb0ff9 100644 --- a/arch/arm/kernel/machine_kexec.c +++ b/arch/arm/kernel/machine_kexec.c @@ -123,6 +123,18 @@ void machine_crash_shutdown(struct pt_regs *regs) printk(KERN_INFO "Loading crashdump kernel...\n"); } +static void byte_copy_relocate_kernel(void *dst, const void *src, int size) +{ + char *d, *s; + d = (char *) dst; + s = (char *) src; + while (size > 0) + { + *d++ = *s++; + size--; + } +} + /* * Function pointer to optional machine-specific reinitialization */ @@ -155,9 +167,8 @@ void machine_kexec(struct kimage *image) /* copy our kernel relocation code to the control code page */ - memcpy(reboot_code_buffer, - relocate_new_kernel, relocate_new_kernel_size); - + byte_copy_relocate_kernel(reboot_code_buffer, + relocate_new_kernel, relocate_new_kernel_size); flush_icache_range((unsigned long) reboot_code_buffer, (unsigned long) reboot_code_buffer + KEXEC_CONTROL_PAGE_SIZE); @@ -165,6 +176,6 @@ void machine_kexec(struct kimage *image) if (kexec_reinit) kexec_reinit(); - + mdelay(500); soft_restart(reboot_code_buffer_phys); } Thanks & Regards Vijay ^ permalink raw reply related [flat|nested] 13+ messages in thread
* Kexec: BE kernel on ARM VE TC2 2013-08-05 12:12 Kexec: BE kernel on ARM VE TC2 Vijay Kilari @ 2013-08-05 15:28 ` Ben Dooks 2013-08-08 6:16 ` Vijay Kilari 2013-08-08 21:50 ` Will Deacon 1 sibling, 1 reply; 13+ messages in thread From: Ben Dooks @ 2013-08-05 15:28 UTC (permalink / raw) To: linux-arm-kernel On 05/08/13 13:12, Vijay Kilari wrote: > Hi Will, > > I am trying to make kexec work on BE kernel on ARM VE TC2. > > First, to make KEXEC work with SMP on ARM VE TC2 board, > I set nr_cpus=2 (i.e boot only A15's) this works with LE kernel. > > However, I made below changes to make KEXEC work for BE kernel. > my question is: why delay is required for board to reboot with kexec?. > Is it platform issue?. > > diff --git a/arch/arm/kernel /machine_kexec.c b/arch/arm/kernel/machine_kexec.c > index 4fb074c..0fb0ff9 100644 > --- a/arch/arm/kernel/machine_kexec.c > +++ b/arch/arm/kernel/machine_kexec.c > @@ -123,6 +123,18 @@ void machine_crash_shutdown(struct pt_regs *regs) > printk(KERN_INFO "Loading crashdump kernel...\n"); > } > > +static void byte_copy_relocate_kernel(void *dst, const void *src, int size) > +{ > + char *d, *s; > + d = (char *) dst; > + s = (char *) src; > + while (size> 0) > + { > + *d++ = *s++; > + size--; > + } > +} > + > /* > * Function pointer to optional machine-specific reinitialization > */ > @@ -155,9 +167,8 @@ void machine_kexec(struct kimage *image) > > > /* copy our kernel relocation code to the control code page */ > - memcpy(reboot_code_buffer, > - relocate_new_kernel, relocate_new_kernel_size); > - > + byte_copy_relocate_kernel(reboot_code_buffer, > + relocate_new_kernel, relocate_new_kernel_size); you should be able to use memcpy() here, as it shouldn't change the endian-ness of the data being copied. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius ^ permalink raw reply [flat|nested] 13+ messages in thread
* Kexec: BE kernel on ARM VE TC2 2013-08-05 15:28 ` Ben Dooks @ 2013-08-08 6:16 ` Vijay Kilari 2013-08-08 8:36 ` Russell King - ARM Linux 0 siblings, 1 reply; 13+ messages in thread From: Vijay Kilari @ 2013-08-08 6:16 UTC (permalink / raw) To: linux-arm-kernel On Mon, Aug 5, 2013 at 8:58 PM, Ben Dooks <ben.dooks@codethink.co.uk> wrote: > On 05/08/13 13:12, Vijay Kilari wrote: >> >> Hi Will, >> >> I am trying to make kexec work on BE kernel on ARM VE TC2. >> >> First, to make KEXEC work with SMP on ARM VE TC2 board, >> I set nr_cpus=2 (i.e boot only A15's) this works with LE kernel. >> >> However, I made below changes to make KEXEC work for BE kernel. >> my question is: why delay is required for board to reboot with kexec?. >> Is it platform issue?. >> >> diff --git a/arch/arm/kernel /machine_kexec.c >> b/arch/arm/kernel/machine_kexec.c >> index 4fb074c..0fb0ff9 100644 >> --- a/arch/arm/kernel/machine_kexec.c >> +++ b/arch/arm/kernel/machine_kexec.c >> @@ -123,6 +123,18 @@ void machine_crash_shutdown(struct pt_regs *regs) >> printk(KERN_INFO "Loading crashdump kernel...\n"); >> } >> >> +static void byte_copy_relocate_kernel(void *dst, const void *src, int >> size) >> +{ >> + char *d, *s; >> + d = (char *) dst; >> + s = (char *) src; >> + while (size> 0) >> + { >> + *d++ = *s++; >> + size--; >> + } >> +} >> + >> /* >> * Function pointer to optional machine-specific reinitialization >> */ >> @@ -155,9 +167,8 @@ void machine_kexec(struct kimage *image) >> >> >> /* copy our kernel relocation code to the control code page */ >> - memcpy(reboot_code_buffer, >> - relocate_new_kernel, relocate_new_kernel_size); >> - >> + byte_copy_relocate_kernel(reboot_code_buffer, >> + relocate_new_kernel, relocate_new_kernel_size); > > > you should be able to use memcpy() here, as it shouldn't change the > endian-ness of the data being copied. > Yes, you are right. I see that memcpy() works. However I see strange issue with Kexec on BE kernel. If I put debug print in arch/arm/kernel/head.S code before turning on MMU, KEXEC works. if I remove the debug print kexec boot hangs. So I could not relate how calling printascii is solving the problem Any suggestion? If printascii is called after turning on mmu, kexec hangs. Below is my debug code diff --git a/arch/arm/kernel/head-common.S b/arch/arm/kernel/head-common.S index 5b391a6..15d4504 100644 --- a/arch/arm/kernel/head-common.S +++ b/arch/arm/kernel/head-common.S @@ -175,6 +175,15 @@ __lookup_processor_type_data: .long __proc_info_end .size __lookup_processor_type_data, . - __lookup_processor_type_data +__print_debug: + stmfd sp!, {r0 - r6, r9, lr} + adr r0, str_p3 + bl printascii + ldmfd sp!, {r0 - r6, r9, pc} +str_p3: .asciz "\nHere" + .align +ENDPROC(__print_debug) + __error_p: #ifdef CONFIG_DEBUG_LL adr r0, str_p1 diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S index d509995..a19147c 100644 --- a/arch/arm/kernel/head.S +++ b/arch/arm/kernel/head.S @@ -114,7 +114,7 @@ ENTRY(stext) #else ldr r8, =PHYS_OFFSET @ always constant in this case #endif - + bl __print_debug /* * r1 = machine no, r2 = atags or dtb, * r8 = phys_offset, r9 = cpuid, r10 = procinfo > -- > Ben Dooks http://www.codethink.co.uk/ > Senior Engineer Codethink - Providing Genius ^ permalink raw reply related [flat|nested] 13+ messages in thread
* Kexec: BE kernel on ARM VE TC2 2013-08-08 6:16 ` Vijay Kilari @ 2013-08-08 8:36 ` Russell King - ARM Linux 0 siblings, 0 replies; 13+ messages in thread From: Russell King - ARM Linux @ 2013-08-08 8:36 UTC (permalink / raw) To: linux-arm-kernel On Thu, Aug 08, 2013 at 11:46:03AM +0530, Vijay Kilari wrote: > Yes, you are right. I see that memcpy() works. However I see strange issue > with Kexec on BE kernel. If I put debug print in arch/arm/kernel/head.S code > before turning on MMU, KEXEC works. if I remove the debug print kexec > boot hangs. > So I could not relate how calling printascii is solving the problem > > Any suggestion? > > If printascii is called after turning on mmu, kexec hangs. Below is my > debug code > > diff --git a/arch/arm/kernel/head-common.S b/arch/arm/kernel/head-common.S > index 5b391a6..15d4504 100644 > --- a/arch/arm/kernel/head-common.S > +++ b/arch/arm/kernel/head-common.S > @@ -175,6 +175,15 @@ __lookup_processor_type_data: > .long __proc_info_end > .size __lookup_processor_type_data, . - __lookup_processor_type_data > > +__print_debug: > + stmfd sp!, {r0 - r6, r9, lr} > + adr r0, str_p3 > + bl printascii > + ldmfd sp!, {r0 - r6, r9, pc} > +str_p3: .asciz "\nHere" > + .align > +ENDPROC(__print_debug) > + This is rather broken. Who says you have a stack here to store those registers? The answer is - you generally won't have a stack. So this is going to scribble on whatever memory 'sp' happens to be pointing at at the time the kernel is entered. printascii is designed to avoid disrupting as many registers as possible. It will only modify r0-r3 and of course lr. I'm sure you can temporarily move r1/r2 to a different register pair, and move the above inline, and then move these back. The comment just after where you place it documents the 'live' registers. I'm not saying anything about the problem you're reporting; I'm trying to teach you how to use the early debug correctly. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Kexec: BE kernel on ARM VE TC2 2013-08-05 12:12 Kexec: BE kernel on ARM VE TC2 Vijay Kilari 2013-08-05 15:28 ` Ben Dooks @ 2013-08-08 21:50 ` Will Deacon 2013-08-12 9:59 ` Vijay Kilari 2013-08-13 22:52 ` Nicolas Pitre 1 sibling, 2 replies; 13+ messages in thread From: Will Deacon @ 2013-08-08 21:50 UTC (permalink / raw) To: linux-arm-kernel On Mon, Aug 05, 2013 at 01:12:17PM +0100, Vijay Kilari wrote: > Hi Will, > > I am trying to make kexec work on BE kernel on ARM VE TC2. > > First, to make KEXEC work with SMP on ARM VE TC2 board, > I set nr_cpus=2 (i.e boot only A15's) this works with LE kernel. Interesting, is this with a mainline kernel? I don't see how SMP kexec can work on TC2 without additional patches to park the secondary cores safely. Will ^ permalink raw reply [flat|nested] 13+ messages in thread
* Kexec: BE kernel on ARM VE TC2 2013-08-08 21:50 ` Will Deacon @ 2013-08-12 9:59 ` Vijay Kilari 2013-08-13 11:15 ` Will Deacon 2013-08-13 22:52 ` Nicolas Pitre 1 sibling, 1 reply; 13+ messages in thread From: Vijay Kilari @ 2013-08-12 9:59 UTC (permalink / raw) To: linux-arm-kernel On Fri, Aug 9, 2013 at 3:20 AM, Will Deacon <will.deacon@arm.com> wrote: > On Mon, Aug 05, 2013 at 01:12:17PM +0100, Vijay Kilari wrote: >> Hi Will, >> >> I am trying to make kexec work on BE kernel on ARM VE TC2. >> >> First, to make KEXEC work with SMP on ARM VE TC2 board, >> I set nr_cpus=2 (i.e boot only A15's) this works with LE kernel. > > Interesting, is this with a mainline kernel? I don't see how SMP kexec can > work on TC2 without additional patches to park the secondary cores safely. > Yes, it is our internal kernel based on 3.10.3. I have not made any changes related to this. I found that booting only 2 CPU's works and I continue to check Kdump and other features on top of this. However with Big Endian, I see that Kexec is not stable. I suspect that UART is the issue. because playing around with some printk and delays make it work. Any help? I plan to reset pl011 before kexec softreset. But could not find any register to reset complete pl011 uart. I will try to reset/clear IMSC, ICR and CR registers of pl011 and check. Note: On Kexec with CONFIG_KEXEC_JUMP disabled, the softreboot happens without resetting/shutdown of any devices > Will ^ permalink raw reply [flat|nested] 13+ messages in thread
* Kexec: BE kernel on ARM VE TC2 2013-08-12 9:59 ` Vijay Kilari @ 2013-08-13 11:15 ` Will Deacon 0 siblings, 0 replies; 13+ messages in thread From: Will Deacon @ 2013-08-13 11:15 UTC (permalink / raw) To: linux-arm-kernel On Mon, Aug 12, 2013 at 10:59:45AM +0100, Vijay Kilari wrote: > On Fri, Aug 9, 2013 at 3:20 AM, Will Deacon <will.deacon@arm.com> wrote: > > On Mon, Aug 05, 2013 at 01:12:17PM +0100, Vijay Kilari wrote: > >> I am trying to make kexec work on BE kernel on ARM VE TC2. > >> > >> First, to make KEXEC work with SMP on ARM VE TC2 board, > >> I set nr_cpus=2 (i.e boot only A15's) this works with LE kernel. > > > > Interesting, is this with a mainline kernel? I don't see how SMP kexec can > > work on TC2 without additional patches to park the secondary cores safely. > > > > Yes, it is our internal kernel based on 3.10.3. I have not made any changes > related to this. I found that booting only 2 CPU's works > and I continue to check Kdump and other features on top of this. I think 2 CPUs is working by fluke. Try kexecing a Thumb kernel from an ARM kernel. > However with Big Endian, I see that Kexec is not stable. I suspect > that UART is the issue. because playing around with some printk and delays > make it work. Any help? I plan to reset pl011 before kexec softreset. > But could not find any register to reset complete pl011 uart. > I will try to reset/clear IMSC, ICR and CR registers of pl011 and check. Wait are you trying to kexec a BE kernel from an LE kernel? That would be similar to the Thumb/ARM case I mentioned above. A better starting point would be to try UP kernels and get that working first, since we already know that SMP kexec is broken on TC2. Will ^ permalink raw reply [flat|nested] 13+ messages in thread
* Kexec: BE kernel on ARM VE TC2 2013-08-08 21:50 ` Will Deacon 2013-08-12 9:59 ` Vijay Kilari @ 2013-08-13 22:52 ` Nicolas Pitre 2013-08-14 5:46 ` Vijay Kilari 1 sibling, 1 reply; 13+ messages in thread From: Nicolas Pitre @ 2013-08-13 22:52 UTC (permalink / raw) To: linux-arm-kernel On Thu, 8 Aug 2013, Will Deacon wrote: > On Mon, Aug 05, 2013 at 01:12:17PM +0100, Vijay Kilari wrote: > > Hi Will, > > > > I am trying to make kexec work on BE kernel on ARM VE TC2. > > > > First, to make KEXEC work with SMP on ARM VE TC2 board, > > I set nr_cpus=2 (i.e boot only A15's) this works with LE kernel. > > Interesting, is this with a mainline kernel? I don't see how SMP kexec can > work on TC2 without additional patches to park the secondary cores safely. BTW those patches are available in linux-next at the moment. Nicolas ^ permalink raw reply [flat|nested] 13+ messages in thread
* Kexec: BE kernel on ARM VE TC2 2013-08-13 22:52 ` Nicolas Pitre @ 2013-08-14 5:46 ` Vijay Kilari 2013-08-14 15:19 ` Nicolas Pitre 0 siblings, 1 reply; 13+ messages in thread From: Vijay Kilari @ 2013-08-14 5:46 UTC (permalink / raw) To: linux-arm-kernel On Wed, Aug 14, 2013 at 4:22 AM, Nicolas Pitre <nico@fluxnic.net> wrote: > On Thu, 8 Aug 2013, Will Deacon wrote: > >> On Mon, Aug 05, 2013 at 01:12:17PM +0100, Vijay Kilari wrote: >> > Hi Will, >> > >> > I am trying to make kexec work on BE kernel on ARM VE TC2. >> > >> > First, to make KEXEC work with SMP on ARM VE TC2 board, >> > I set nr_cpus=2 (i.e boot only A15's) this works with LE kernel. >> >> Interesting, is this with a mainline kernel? I don't see how SMP kexec can >> work on TC2 without additional patches to park the secondary cores safely. > > BTW those patches are available in linux-next at the moment. Thanks for this info. I see that MCPM, TC2_PM & SPC configuration needs to be enabled to have TC2 power management. However MCPM also depends on CCI configuration to register smps ops. In my config, I dont have CCI config enabled Can you please suggest right configuration to be enabled and also dts configuration for SPC, CCI to enable TC2 power mgmt. Also I am using u-boot. Do I need to use UEFI/firmware to enable TC2 power mgmt? I remember, some time back, I have tried linaro tracking git and failed to boot my board > > > Nicolas ^ permalink raw reply [flat|nested] 13+ messages in thread
* Kexec: BE kernel on ARM VE TC2 2013-08-14 5:46 ` Vijay Kilari @ 2013-08-14 15:19 ` Nicolas Pitre 2013-08-19 7:31 ` Vijay Kilari 0 siblings, 1 reply; 13+ messages in thread From: Nicolas Pitre @ 2013-08-14 15:19 UTC (permalink / raw) To: linux-arm-kernel On Wed, 14 Aug 2013, Vijay Kilari wrote: > On Wed, Aug 14, 2013 at 4:22 AM, Nicolas Pitre <nico@fluxnic.net> wrote: > > On Thu, 8 Aug 2013, Will Deacon wrote: > > > >> On Mon, Aug 05, 2013 at 01:12:17PM +0100, Vijay Kilari wrote: > >> > Hi Will, > >> > > >> > I am trying to make kexec work on BE kernel on ARM VE TC2. > >> > > >> > First, to make KEXEC work with SMP on ARM VE TC2 board, > >> > I set nr_cpus=2 (i.e boot only A15's) this works with LE kernel. > >> > >> Interesting, is this with a mainline kernel? I don't see how SMP kexec can > >> work on TC2 without additional patches to park the secondary cores safely. > > > > BTW those patches are available in linux-next at the moment. > > Thanks for this info. > I see that MCPM, TC2_PM & SPC configuration needs to be enabled to have > TC2 power management. However MCPM also depends on CCI configuration > to register smps ops. > In my config, I dont have CCI config enabled You do need CCI support in addition to all the above. Managing CPUs on TC2 is serious business ! > Can you please suggest right configuration to be enabled and also dts > configuration for SPC, CCI to enable TC2 power mgmt. You need the following pieces of firmware: mbb_v311.ebf or later in MB/HBI0190D/ and proper reference to it in MB/HBI0190D/board.txt. dbb_v110.ebf or later in SITE1/HBI0249A/. The file SITE1/HBI0249A/board.txt must have a proper reference to that file, as well as the following values in the "[SCC REGISTERS]" section: SCC: 0x700 0x0032F003 Most important here is to have bits 12 through 15 set to 1. Those firmware files should be available on ARM's web site. You also need to have the following sections in your device tree source file: - SPC/SCC Depending on the flavor of the patch you have, this is either spc at 7fff0000 or scc at 7fff0000. You should look for either vexpress-spc.txt or vexpress-scc.txt in Documentation/devicetree/bindings/arm/ and use the example therein. - CCI You need a CCI section as examplified in Documentation/devicetree/bindings/arm/cci.txt. > Also I am using u-boot. Do I need to use UEFI/firmware to enable TC2 power mgmt? No. I'm using U-Boot as well. > I remember, some time back, I have tried linaro tracking git and > failed to boot my board This is most likely because of the above firmware settings and device tree requirements. Nicolas ^ permalink raw reply [flat|nested] 13+ messages in thread
* Kexec: BE kernel on ARM VE TC2 2013-08-14 15:19 ` Nicolas Pitre @ 2013-08-19 7:31 ` Vijay Kilari 2013-08-19 12:17 ` Vijay Kilari 0 siblings, 1 reply; 13+ messages in thread From: Vijay Kilari @ 2013-08-19 7:31 UTC (permalink / raw) To: linux-arm-kernel On Wed, Aug 14, 2013 at 8:49 PM, Nicolas Pitre <nico@fluxnic.net> wrote: > On Wed, 14 Aug 2013, Vijay Kilari wrote: > >> On Wed, Aug 14, 2013 at 4:22 AM, Nicolas Pitre <nico@fluxnic.net> wrote: >> > On Thu, 8 Aug 2013, Will Deacon wrote: >> > >> >> On Mon, Aug 05, 2013 at 01:12:17PM +0100, Vijay Kilari wrote: >> >> > Hi Will, >> >> > >> >> > I am trying to make kexec work on BE kernel on ARM VE TC2. >> >> > >> >> > First, to make KEXEC work with SMP on ARM VE TC2 board, >> >> > I set nr_cpus=2 (i.e boot only A15's) this works with LE kernel. >> >> >> >> Interesting, is this with a mainline kernel? I don't see how SMP kexec can >> >> work on TC2 without additional patches to park the secondary cores safely. >> > >> > BTW those patches are available in linux-next at the moment. >> >> Thanks for this info. >> I see that MCPM, TC2_PM & SPC configuration needs to be enabled to have >> TC2 power management. However MCPM also depends on CCI configuration >> to register smps ops. >> In my config, I dont have CCI config enabled > > You do need CCI support in addition to all the above. Managing CPUs on > TC2 is serious business ! > >> Can you please suggest right configuration to be enabled and also dts >> configuration for SPC, CCI to enable TC2 power mgmt. > > You need the following pieces of firmware: > > mbb_v311.ebf or later in MB/HBI0190D/ and proper reference to it in > MB/HBI0190D/board.txt. > > dbb_v110.ebf or later in SITE1/HBI0249A/. The file > SITE1/HBI0249A/board.txt must have a proper reference to that file, > as well as the following values in the "[SCC REGISTERS]" section: > > SCC: 0x700 0x0032F003 > > Most important here is to have bits 12 through 15 set to 1. > > Those firmware files should be available on ARM's web site. > > You also need to have the following sections in your device tree source > file: > > - SPC/SCC > > Depending on the flavor of the patch you have, this is either > spc at 7fff0000 or scc at 7fff0000. You should look for either > vexpress-spc.txt or vexpress-scc.txt in > Documentation/devicetree/bindings/arm/ and use the example therein. > > - CCI > > You need a CCI section as examplified in > Documentation/devicetree/bindings/arm/cci.txt. > >> Also I am using u-boot. Do I need to use UEFI/firmware to enable TC2 power mgmt? > > No. I'm using U-Boot as well. > >> I remember, some time back, I have tried linaro tracking git and >> failed to boot my board > > This is most likely because of the above firmware settings and device > tree requirements. > > Thanks for this info. I have taken your linaro branch and tested it git clone git://git.linaro.org/people/nico/linux.git and checkout TC2 branch I have selected MCPM, TC2_PM config and made following changes to dts file diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts index d2803be..46ba764 100644 --- a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts +++ b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts @@ -9,6 +9,8 @@ /dts-v1/; +/memreserve/ 0xff000000 0x01000000; + / { model = "V2P-CA15_CA7"; arm,hbi = <0x249>; @@ -29,6 +31,47 @@ i2c1 = &v2m_i2c_pcie; }; + clusters { + #address-cells = <1>; + #size-cells = <0>; + cluster0: cluster at 0 { + reg = <0>; + cores { + #address-cells = <1>; + #size-cells = <0>; + + core0: core at 0 { + reg = <0>; + }; + + core1: core at 1 { + reg = <1>; + }; + + }; + }; + + cluster1: cluster at 1 { + reg = <1>; + cores { + #address-cells = <1>; + #size-cells = <0>; + + core2: core at 0 { + reg = <0>; + }; + + core3: core at 1 { + reg = <1>; + }; + + core4: core at 2 { + reg = <2>; + }; + }; + }; + }; + cpus { #address-cells = <1>; #size-cells = <0>; @@ -37,36 +80,56 @@ device_type = "cpu"; compatible = "arm,cortex-a15"; reg = <0>; + cluster = <&cluster0>; + core = <&core0>; + clock-frequency = <1000000000>; + cci-control-port = <&cci_control1>; }; cpu1: cpu at 1 { device_type = "cpu"; compatible = "arm,cortex-a15"; reg = <1>; + cluster = <&cluster0>; + core = <&core1>; + clock-frequency = <1000000000>; + cci-control-port = <&cci_control1>; }; cpu2: cpu at 2 { device_type = "cpu"; compatible = "arm,cortex-a7"; reg = <0x100>; + cluster = <&cluster1>; + core = <&core2>; + clock-frequency = <800000000>; + cci-control-port = <&cci_control2>; }; cpu3: cpu at 3 { device_type = "cpu"; compatible = "arm,cortex-a7"; reg = <0x101>; + cluster = <&cluster1>; + core = <&core3>; + clock-frequency = <800000000>; + cci-control-port = <&cci_control2>; }; cpu4: cpu at 4 { device_type = "cpu"; compatible = "arm,cortex-a7"; reg = <0x102>; + cluster = <&cluster1>; + core = <&core4>; + clock-frequency = <800000000>; + cci-control-port = <&cci_control2>; }; }; memory at 80000000 { device_type = "memory"; - reg = <0 0x80000000 0 0x40000000>; + reg = <0 0x80000000 0 0x80000000>; }; wdt at 2a490000 { @@ -81,6 +144,8 @@ compatible = "arm,hdlcd"; reg = <0 0x2b000000 0 0x1000>; interrupts = <0 85 4>; + mode = "1024x768-16 at 60"; + framebuffer = <0 0xff000000 0 0x01000000>; clocks = <&oscclk5>; clock-names = "pxlclk"; }; @@ -104,6 +169,36 @@ interrupts = <1 9 0xf04>; }; + cci at 2c090000 { + compatible = "arm,cci-400"; + #address-cells = <1>; + #size-cells = <1>; + reg = <0 0x2c090000 0 0x1000>; + ranges = <0x0 0x0 0x2c090000 0x10000>; + + cci_control1: slave-if at 4000 { + compatible = "arm,cci-400-ctrl-if"; + interface-type = "ace"; + reg = <0x4000 0x1000>; + }; + + cci_control2: slave-if at 5000 { + compatible = "arm,cci-400-ctrl-if"; + interface-type = "ace"; + reg = <0x5000 0x1000>; + }; + }; + + cci-pmu at 2c099000 { + compatible = "arm,cci-400-pmu"; + reg = <0 0x2c099000 0 0x6000>; + interrupts = <0 101 4>, + <0 102 4>, + <0 103 4>, + <0 104 4>, + <0 105 4>; + }; + memory-controller at 7ffd0000 { compatible = "arm,pl354", "arm,primecell"; reg = <0 0x7ffd0000 0 0x1000>; @@ -125,6 +220,12 @@ clock-names = "apb_pclk"; }; + spc at 7fff0000 { + compatible = "arm,vexpress-spc,v2p-ca15_a7","arm,vexpress-spc"; + reg = <0 0x7fff0000 0 0x1000>; + interrupts = <0 95 4>; + }; + timer { compatible = "arm,armv7-timer"; interrupts = <1 13 0xf08>, With this I see that secondary CPU's are not booted. Please see log below PERCPU: Embedded 7 pages/cpu @80d12000 s7296 r8192 d13184 u32768 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 260096 Kernel command line: console=ttyAMA0,38400n8 root=/dev/nfs rw ip=dhcp nfsroot=10.167.100.215:/mnt/be_rfs PID hash table entries: 4096 (order: 2, 16384 bytes) Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 1034252K/1048576K available (3579K kernel code, 166K rwdata, 1020K rodata, 203K init, 139K bss, 14324K reserved) Virtual kernel memory layout: vector : 0xffff0000 - 0xffff1000 ( 4 kB) fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB) vmalloc : 0xc0800000 - 0xff000000 (1000 MB) lowmem : 0x80000000 - 0xc0000000 (1024 MB) modules : 0x7f000000 - 0x80000000 ( 16 MB) .text : 0x80008000 - 0x804862ac (4601 kB) .init : 0x80487000 - 0x804b9c80 ( 204 kB) .data : 0x804ba000 - 0x804e39e0 ( 167 kB) .bss : 0x804e39e0 - 0x805068d0 ( 140 kB) SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 Hierarchical RCU implementation. NR_IRQS:16 nr_irqs:16 16 sched_clock: 32 bits at 1000kHz, resolution 1000ns, wraps every 4294967ms sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms Console: colour dummy device 80x30 Calibrating delay loop... 1987.37 BogoMIPS (lpj=9936896) pid_max: default: 32768 minimum: 301 Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok CPU0: update cpu_power 1441 CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 Setting up static identity map for 0x80365b78 - 0x80365bd0 vexpress-spc loaded at c0808000 ARM CCI driver probed TC2 power management initialized CPU1: failed to come online CPU2: failed to come online CPU3: failed to come online Brought up 1 CPUs SMP: Total of 1 processors activated (1987.37 BogoMIPS). CPU: All CPU(s) started in SVC mode. I am using following firware versions MB: mbb_v312.ebf DBB: dbb_v110.ebf and board.txt in DBB is as follows SCC: 0x700 0x0032F003 ;CFGRW48 - Cluster configuration register (Default 0x0032F003) ; [ 28] Boot Cluster (default CA15) ; [25:24] Boot CPU (default 0) ; [ 15] A7 Event stream generation (default: enabled) ; [ 14] A15 Event stream generation (default: enabled) ; [ 13] Power down the non-boot cluster (default: enabled) ; [ 12] Use per-cpu mailboxes for power management (default: enabled) ; [ 11] A15 executes WFEs as nops (default: disabled) SCC: 0x400 0x33330C00 ;CFGRW41 - A15 configuration register 0 (Default 0x33330C00) ; [29:28] SPNIDEN ; [25:24] SPIDEN ; [21:20] NIDEN ; [17:16] DBGEN ; [13:12] CFGTE ; [ 9: 8] VINITHI_CORE ; [ 7] IMINLN ; [ 3: 0] CLUSTER_ID .. ;Power management interface SCC: 0xC00 0x00000007 ;Control: [0]PMI_EN [1]DBG_EN [2]SPC_SYSCFG (disable DBG_EN for power measurements) In fact, I have updated complete firmware to v5.2 version, with this Boot monitor version is v5.2.1 and as I mentioned, I am using u-boot for booting Please let me know what is going wrong here? > Nicolas ^ permalink raw reply related [flat|nested] 13+ messages in thread
* Kexec: BE kernel on ARM VE TC2 2013-08-19 7:31 ` Vijay Kilari @ 2013-08-19 12:17 ` Vijay Kilari 2013-08-20 10:31 ` Vijay Kilari 0 siblings, 1 reply; 13+ messages in thread From: Vijay Kilari @ 2013-08-19 12:17 UTC (permalink / raw) To: linux-arm-kernel Hi Nicolas, On Mon, Aug 19, 2013 at 1:01 PM, Vijay Kilari <vijay.kilari@gmail.com> wrote: > On Wed, Aug 14, 2013 at 8:49 PM, Nicolas Pitre <nico@fluxnic.net> wrote: >> On Wed, 14 Aug 2013, Vijay Kilari wrote: >> >>> On Wed, Aug 14, 2013 at 4:22 AM, Nicolas Pitre <nico@fluxnic.net> wrote: >>> > On Thu, 8 Aug 2013, Will Deacon wrote: >>> > >>> >> On Mon, Aug 05, 2013 at 01:12:17PM +0100, Vijay Kilari wrote: >>> >> > Hi Will, >>> >> > >>> >> > I am trying to make kexec work on BE kernel on ARM VE TC2. >>> >> > >>> >> > First, to make KEXEC work with SMP on ARM VE TC2 board, >>> >> > I set nr_cpus=2 (i.e boot only A15's) this works with LE kernel. >>> >> >>> >> Interesting, is this with a mainline kernel? I don't see how SMP kexec can >>> >> work on TC2 without additional patches to park the secondary cores safely. >>> > >>> > BTW those patches are available in linux-next at the moment. >>> >>> Thanks for this info. >>> I see that MCPM, TC2_PM & SPC configuration needs to be enabled to have >>> TC2 power management. However MCPM also depends on CCI configuration >>> to register smps ops. >>> In my config, I dont have CCI config enabled >> >> You do need CCI support in addition to all the above. Managing CPUs on >> TC2 is serious business ! >> >>> Can you please suggest right configuration to be enabled and also dts >>> configuration for SPC, CCI to enable TC2 power mgmt. >> >> You need the following pieces of firmware: >> >> mbb_v311.ebf or later in MB/HBI0190D/ and proper reference to it in >> MB/HBI0190D/board.txt. >> >> dbb_v110.ebf or later in SITE1/HBI0249A/. The file >> SITE1/HBI0249A/board.txt must have a proper reference to that file, >> as well as the following values in the "[SCC REGISTERS]" section: >> >> SCC: 0x700 0x0032F003 >> >> Most important here is to have bits 12 through 15 set to 1. >> >> Those firmware files should be available on ARM's web site. >> >> You also need to have the following sections in your device tree source >> file: >> >> - SPC/SCC >> >> Depending on the flavor of the patch you have, this is either >> spc at 7fff0000 or scc at 7fff0000. You should look for either >> vexpress-spc.txt or vexpress-scc.txt in >> Documentation/devicetree/bindings/arm/ and use the example therein. >> >> - CCI >> >> You need a CCI section as examplified in >> Documentation/devicetree/bindings/arm/cci.txt. >> >>> Also I am using u-boot. Do I need to use UEFI/firmware to enable TC2 power mgmt? >> >> No. I'm using U-Boot as well. >> >>> I remember, some time back, I have tried linaro tracking git and >>> failed to boot my board >> >> This is most likely because of the above firmware settings and device >> tree requirements. >> >> > > Thanks for this info. I have taken your linaro branch and tested it > > git clone git://git.linaro.org/people/nico/linux.git and checkout TC2 branch > > I have selected MCPM, TC2_PM config and made following changes to dts file > > diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts > b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts > index d2803be..46ba764 100644 > --- a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts > +++ b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts > @@ -9,6 +9,8 @@ > > /dts-v1/; > > +/memreserve/ 0xff000000 0x01000000; > + > / { > model = "V2P-CA15_CA7"; > arm,hbi = <0x249>; > @@ -29,6 +31,47 @@ > i2c1 = &v2m_i2c_pcie; > }; > > + clusters { > + #address-cells = <1>; > + #size-cells = <0>; > + cluster0: cluster at 0 { > + reg = <0>; > + cores { > + #address-cells = <1>; > + #size-cells = <0>; > + > + core0: core at 0 { > + reg = <0>; > + }; > + > + core1: core at 1 { > + reg = <1>; > + }; > + > + }; > + }; > + > + cluster1: cluster at 1 { > + reg = <1>; > + cores { > + #address-cells = <1>; > + #size-cells = <0>; > + > + core2: core at 0 { > + reg = <0>; > + }; > + > + core3: core at 1 { > + reg = <1>; > + }; > + > + core4: core at 2 { > + reg = <2>; > + }; > + }; > + }; > + }; > + > cpus { > #address-cells = <1>; > #size-cells = <0>; > @@ -37,36 +80,56 @@ > device_type = "cpu"; > compatible = "arm,cortex-a15"; > reg = <0>; > + cluster = <&cluster0>; > + core = <&core0>; > + clock-frequency = <1000000000>; > + cci-control-port = <&cci_control1>; > }; > > cpu1: cpu at 1 { > device_type = "cpu"; > compatible = "arm,cortex-a15"; > reg = <1>; > + cluster = <&cluster0>; > + core = <&core1>; > + clock-frequency = <1000000000>; > + cci-control-port = <&cci_control1>; > }; > > cpu2: cpu at 2 { > device_type = "cpu"; > compatible = "arm,cortex-a7"; > reg = <0x100>; > + cluster = <&cluster1>; > + core = <&core2>; > + clock-frequency = <800000000>; > + cci-control-port = <&cci_control2>; > }; > > cpu3: cpu at 3 { > device_type = "cpu"; > compatible = "arm,cortex-a7"; > reg = <0x101>; > + cluster = <&cluster1>; > + core = <&core3>; > + clock-frequency = <800000000>; > + cci-control-port = <&cci_control2>; > }; > > cpu4: cpu at 4 { > device_type = "cpu"; > compatible = "arm,cortex-a7"; > reg = <0x102>; > + cluster = <&cluster1>; > + core = <&core4>; > + clock-frequency = <800000000>; > + cci-control-port = <&cci_control2>; > }; > }; > > memory at 80000000 { > device_type = "memory"; > - reg = <0 0x80000000 0 0x40000000>; > + reg = <0 0x80000000 0 0x80000000>; > }; > > wdt at 2a490000 { > @@ -81,6 +144,8 @@ > compatible = "arm,hdlcd"; > reg = <0 0x2b000000 0 0x1000>; > interrupts = <0 85 4>; > + mode = "1024x768-16 at 60"; > + framebuffer = <0 0xff000000 0 0x01000000>; > clocks = <&oscclk5>; > clock-names = "pxlclk"; > }; > @@ -104,6 +169,36 @@ > interrupts = <1 9 0xf04>; > }; > > + cci at 2c090000 { > + compatible = "arm,cci-400"; > + #address-cells = <1>; > + #size-cells = <1>; > + reg = <0 0x2c090000 0 0x1000>; > + ranges = <0x0 0x0 0x2c090000 0x10000>; > + > + cci_control1: slave-if at 4000 { > + compatible = "arm,cci-400-ctrl-if"; > + interface-type = "ace"; > + reg = <0x4000 0x1000>; > + }; > + > + cci_control2: slave-if at 5000 { > + compatible = "arm,cci-400-ctrl-if"; > + interface-type = "ace"; > + reg = <0x5000 0x1000>; > + }; > + }; > + > + cci-pmu at 2c099000 { > + compatible = "arm,cci-400-pmu"; > + reg = <0 0x2c099000 0 0x6000>; > + interrupts = <0 101 4>, > + <0 102 4>, > + <0 103 4>, > + <0 104 4>, > + <0 105 4>; > + }; > + > memory-controller at 7ffd0000 { > compatible = "arm,pl354", "arm,primecell"; > reg = <0 0x7ffd0000 0 0x1000>; > @@ -125,6 +220,12 @@ > clock-names = "apb_pclk"; > }; > > + spc at 7fff0000 { > + compatible = "arm,vexpress-spc,v2p-ca15_a7","arm,vexpress-spc"; > + reg = <0 0x7fff0000 0 0x1000>; > + interrupts = <0 95 4>; > + }; > + > timer { > compatible = "arm,armv7-timer"; > interrupts = <1 13 0xf08>, > > With this I see that secondary CPU's are not booted. Please see log below > > PERCPU: Embedded 7 pages/cpu @80d12000 s7296 r8192 d13184 u32768 > Built 1 zonelists in Zone order, mobility grouping on. Total pages: 260096 > Kernel command line: console=ttyAMA0,38400n8 root=/dev/nfs rw ip=dhcp > nfsroot=10.167.100.215:/mnt/be_rfs > PID hash table entries: 4096 (order: 2, 16384 bytes) > Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) > Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) > Memory: 1034252K/1048576K available (3579K kernel code, 166K rwdata, > 1020K rodata, 203K init, 139K bss, 14324K reserved) > Virtual kernel memory layout: > vector : 0xffff0000 - 0xffff1000 ( 4 kB) > fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB) > vmalloc : 0xc0800000 - 0xff000000 (1000 MB) > lowmem : 0x80000000 - 0xc0000000 (1024 MB) > modules : 0x7f000000 - 0x80000000 ( 16 MB) > .text : 0x80008000 - 0x804862ac (4601 kB) > .init : 0x80487000 - 0x804b9c80 ( 204 kB) > .data : 0x804ba000 - 0x804e39e0 ( 167 kB) > .bss : 0x804e39e0 - 0x805068d0 ( 140 kB) > SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 > Hierarchical RCU implementation. > NR_IRQS:16 nr_irqs:16 16 > sched_clock: 32 bits at 1000kHz, resolution 1000ns, wraps every 4294967ms > sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms > Console: colour dummy device 80x30 > Calibrating delay loop... 1987.37 BogoMIPS (lpj=9936896) > pid_max: default: 32768 minimum: 301 > Mount-cache hash table entries: 512 > CPU: Testing write buffer coherency: ok > CPU0: update cpu_power 1441 > CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 > Setting up static identity map for 0x80365b78 - 0x80365bd0 > vexpress-spc loaded at c0808000 > ARM CCI driver probed > TC2 power management initialized > CPU1: failed to come online > CPU2: failed to come online > CPU3: failed to come online > Brought up 1 CPUs > SMP: Total of 1 processors activated (1987.37 BogoMIPS). > CPU: All CPU(s) started in SVC mode. > > I am using following firware versions > > MB: mbb_v312.ebf > DBB: dbb_v110.ebf > > and board.txt in DBB is as follows > > SCC: 0x700 0x0032F003 ;CFGRW48 - Cluster configuration > register (Default 0x0032F003) > ; [ 28] Boot Cluster (default CA15) > ; [25:24] Boot CPU (default 0) > ; [ 15] A7 Event stream > generation (default: enabled) > ; [ 14] A15 Event stream > generation (default: enabled) > ; [ 13] Power down the > non-boot cluster (default: enabled) > ; [ 12] Use per-cpu > mailboxes for power management (default: enabled) > ; [ 11] A15 executes WFEs > as nops (default: disabled) > > SCC: 0x400 0x33330C00 ;CFGRW41 - A15 configuration register > 0 (Default 0x33330C00) > ; [29:28] SPNIDEN > ; [25:24] SPIDEN > ; [21:20] NIDEN > ; [17:16] DBGEN > ; [13:12] CFGTE > ; [ 9: 8] VINITHI_CORE > ; [ 7] IMINLN > ; [ 3: 0] CLUSTER_ID > > .. > ;Power management interface > SCC: 0xC00 0x00000007 ;Control: [0]PMI_EN [1]DBG_EN > [2]SPC_SYSCFG (disable DBG_EN for power measurements) > > In fact, I have updated complete firmware to v5.2 version, with this > Boot monitor version is v5.2.1 > and as I mentioned, I am using u-boot for booting > > Please let me know what is going wrong here? > After using v5.0 firmware version + CPU migration patch and making changes to board.txt according to http://lists.linaro.org/pipermail/linaro-dev/2013-January/015095.html Now all the CPU's are booting up. I will check now Kexec >> Nicolas ^ permalink raw reply [flat|nested] 13+ messages in thread
* Kexec: BE kernel on ARM VE TC2 2013-08-19 12:17 ` Vijay Kilari @ 2013-08-20 10:31 ` Vijay Kilari 0 siblings, 0 replies; 13+ messages in thread From: Vijay Kilari @ 2013-08-20 10:31 UTC (permalink / raw) To: linux-arm-kernel On Mon, Aug 19, 2013 at 5:47 PM, Vijay Kilari <vijay.kilari@gmail.com> wrote: > Hi Nicolas, > > On Mon, Aug 19, 2013 at 1:01 PM, Vijay Kilari <vijay.kilari@gmail.com> wrote: >> On Wed, Aug 14, 2013 at 8:49 PM, Nicolas Pitre <nico@fluxnic.net> wrote: >>> On Wed, 14 Aug 2013, Vijay Kilari wrote: >>> >>>> On Wed, Aug 14, 2013 at 4:22 AM, Nicolas Pitre <nico@fluxnic.net> wrote: >>>> > On Thu, 8 Aug 2013, Will Deacon wrote: >>>> > >>>> >> On Mon, Aug 05, 2013 at 01:12:17PM +0100, Vijay Kilari wrote: >>>> >> > Hi Will, >>>> >> > >>>> >> > I am trying to make kexec work on BE kernel on ARM VE TC2. >>>> >> > >>>> >> > First, to make KEXEC work with SMP on ARM VE TC2 board, >>>> >> > I set nr_cpus=2 (i.e boot only A15's) this works with LE kernel. >>>> >> >>>> >> Interesting, is this with a mainline kernel? I don't see how SMP kexec can >>>> >> work on TC2 without additional patches to park the secondary cores safely. >>>> > >>>> > BTW those patches are available in linux-next at the moment. >>>> > > After using v5.0 firmware version + CPU migration patch and making changes to > board.txt according to > http://lists.linaro.org/pipermail/linaro-dev/2013-January/015095.html > > Now all the CPU's are booting up. I will check now Kexec > > I see two issues: 1) KEXEC rebooting with Thumb2 kernel fails when booted on LE Kernel. 2) Secondary CPU's are not booted with BE kernel with TC2 Power mgmt enabled Where as with LE, secondary CPU's are booted >>> Nicolas ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2013-08-20 10:31 UTC | newest] Thread overview: 13+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-08-05 12:12 Kexec: BE kernel on ARM VE TC2 Vijay Kilari 2013-08-05 15:28 ` Ben Dooks 2013-08-08 6:16 ` Vijay Kilari 2013-08-08 8:36 ` Russell King - ARM Linux 2013-08-08 21:50 ` Will Deacon 2013-08-12 9:59 ` Vijay Kilari 2013-08-13 11:15 ` Will Deacon 2013-08-13 22:52 ` Nicolas Pitre 2013-08-14 5:46 ` Vijay Kilari 2013-08-14 15:19 ` Nicolas Pitre 2013-08-19 7:31 ` Vijay Kilari 2013-08-19 12:17 ` Vijay Kilari 2013-08-20 10:31 ` Vijay Kilari
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).