| Message ID | 20170518105209.GN22219@n2100.armlinux.org.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Russell, On Thu, May 18, 2017 at 7:52 AM, Russell King - ARM Linux <linux@armlinux.org.uk> wrote: > As a result of a recent bug report, it has been found that certain CPUs > must always have SMP mode enabled in order for the caches to work. > > Remove the conditional on setting the SMP bit(s). > > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> > --- > This needs to be tested on: > > - Cortex A5MP > - Cortex A9MP > - Cortex R7MP > - Cortex A7MP > - Cortex A12MP > - Cortex A15MP > - Cortex A17MP > - Brahma B15 > > and any other CPU that mis-identifies itself with a MP-capable CPUID > signature that might match one of those CPUs. I'm aware of a Cortex > A9 CPU out there that does mis-identify itself as SMP capable but > isn't: > > @ Core indicates it is SMP. Check for Aegis SOC where a single > @ Cortex-A9 CPU is present but SMP operations fault. > > This will also need testing. > > arch/arm/mm/proc-v7.S | 8 ++------ > 1 file changed, 2 insertions(+), 6 deletions(-) > > diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S > index 01d64c0b2563..4d48a4cf563b 100644 > --- a/arch/arm/mm/proc-v7.S > +++ b/arch/arm/mm/proc-v7.S > @@ -286,14 +286,10 @@ ENDPROC(cpu_pj4b_do_resume) > stmia r12, {r1-r6, lr} @ v7_invalidate_l1 touches r0-r6 > bl v7_invalidate_l1 > ldmia r12, {r1-r6, lr} > -#ifdef CONFIG_SMP > + mrc p15, 0, r0, c1, c0, 1 > orr r10, r10, #(1 << 6) @ Enable SMP/nAMP mode > - ALT_SMP(mrc p15, 0, r0, c1, c0, 1) > - ALT_UP(mov r0, r10) @ fake it for UP > orr r10, r10, r0 @ Set required bits > - teq r10, r0 @ Were they already set? > - mcrne p15, 0, r10, c1, c0, 1 @ No, update register > -#endif > + mcr p15, 0, r10, c1, c0, 1 @ No, update register > b __v7_setup_cont I tested this patch on a mx6ul, which is CortexA7 UP using USB serial download mode. In this boot mode the ROM code does not set the SMP bit and I can notice a very slow boot progress with CONFIG_SMP=n with an original 4.12-rc1. With this patch applied it boots with the correct speed, so: Tested-by: Fabio Estevam <fabio.estevam@nxp.com> Adding Kevin on Cc in case kernelci.org could run some tests with this patch applied on other platforms. Thanks
On Thu, May 18, 2017 at 3:09 PM, Fabio Estevam <festevam@gmail.com> wrote: > I tested this patch on a mx6ul, which is CortexA7 UP using USB serial > download mode. > > In this boot mode the ROM code does not set the SMP bit and I can > notice a very slow boot progress with CONFIG_SMP=n with an original > 4.12-rc1. > > With this patch applied it boots with the correct speed, so: However the kernel still takes a long time to decompress when the bootloader or ROM does not set the SMP bit. After it decompress, then it boots quickly. Should the SMP bit be set inside arch/arm/boot/compressed/head.S? Thanks
On Fri, May 19, 2017 at 02:07:28PM -0300, Fabio Estevam wrote: > On Thu, May 18, 2017 at 3:09 PM, Fabio Estevam <festevam@gmail.com> wrote: > > > I tested this patch on a mx6ul, which is CortexA7 UP using USB serial > > download mode. > > > > In this boot mode the ROM code does not set the SMP bit and I can > > notice a very slow boot progress with CONFIG_SMP=n with an original > > 4.12-rc1. > > > > With this patch applied it boots with the correct speed, so: > > However the kernel still takes a long time to decompress when the > bootloader or ROM does not set the SMP bit. > > After it decompress, then it boots quickly. > > Should the SMP bit be set inside arch/arm/boot/compressed/head.S? We could expand the table to positively identify the SMP capable CPUs and enable the SMP bit there, but it's going to add a lot of entries there (one for each specific ARMv7 MP CPU) and is going to have to be endlessly added to each time a new SMP CPU comes out.
To make those handling AM43x aware, To'ing l-o Hi, On Thu, May 18, 2017 at 11:52:10AM +0100, Russell King - ARM Linux wrote: > As a result of a recent bug report, it has been found that certain CPUs > must always have SMP mode enabled in order for the caches to work. > > Remove the conditional on setting the SMP bit(s). > > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> > --- > I'm aware of a Cortex > A9 CPU out there that does mis-identify itself as SMP capable but > isn't: > > @ Core indicates it is SMP. Check for Aegis SOC where a single > @ Cortex-A9 CPU is present but SMP operations fault. > > This will also need testing. With this change, AM437x, i.e. the above mentioned SoC stops booting (multi_v7 config) afzal > > arch/arm/mm/proc-v7.S | 8 ++------ > 1 file changed, 2 insertions(+), 6 deletions(-) > > diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S > index 01d64c0b2563..4d48a4cf563b 100644 > --- a/arch/arm/mm/proc-v7.S > +++ b/arch/arm/mm/proc-v7.S > @@ -286,14 +286,10 @@ ENDPROC(cpu_pj4b_do_resume) > stmia r12, {r1-r6, lr} @ v7_invalidate_l1 touches r0-r6 > bl v7_invalidate_l1 > ldmia r12, {r1-r6, lr} > -#ifdef CONFIG_SMP > + mrc p15, 0, r0, c1, c0, 1 > orr r10, r10, #(1 << 6) @ Enable SMP/nAMP mode > - ALT_SMP(mrc p15, 0, r0, c1, c0, 1) > - ALT_UP(mov r0, r10) @ fake it for UP > orr r10, r10, r0 @ Set required bits > - teq r10, r0 @ Were they already set? > - mcrne p15, 0, r10, c1, c0, 1 @ No, update register > -#endif > + mcr p15, 0, r10, c1, c0, 1 @ No, update register > b __v7_setup_cont > > /* > > -- > RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ > FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up > according to speedtest.net. > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On 05/18/2017 03:52 AM, Russell King - ARM Linux wrote: > As a result of a recent bug report, it has been found that certain CPUs > must always have SMP mode enabled in order for the caches to work. > > Remove the conditional on setting the SMP bit(s). > > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> > --- > This needs to be tested on: > > - Cortex A5MP > - Cortex A9MP > - Cortex R7MP > - Cortex A7MP > - Cortex A12MP > - Cortex A15MP > - Cortex A17MP > - Brahma B15 Sorry just saw this, what kind of test do you want me to run on B15? Should I build a !SMP kernel, or force a SMP kernel with maxcpus=1? > > and any other CPU that mis-identifies itself with a MP-capable CPUID > signature that might match one of those CPUs. I'm aware of a Cortex > A9 CPU out there that does mis-identify itself as SMP capable but > isn't: > > @ Core indicates it is SMP. Check for Aegis SOC where a single > @ Cortex-A9 CPU is present but SMP operations fault. > > This will also need testing. > > arch/arm/mm/proc-v7.S | 8 ++------ > 1 file changed, 2 insertions(+), 6 deletions(-) > > diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S > index 01d64c0b2563..4d48a4cf563b 100644 > --- a/arch/arm/mm/proc-v7.S > +++ b/arch/arm/mm/proc-v7.S > @@ -286,14 +286,10 @@ ENDPROC(cpu_pj4b_do_resume) > stmia r12, {r1-r6, lr} @ v7_invalidate_l1 touches r0-r6 > bl v7_invalidate_l1 > ldmia r12, {r1-r6, lr} > -#ifdef CONFIG_SMP > + mrc p15, 0, r0, c1, c0, 1 > orr r10, r10, #(1 << 6) @ Enable SMP/nAMP mode > - ALT_SMP(mrc p15, 0, r0, c1, c0, 1) > - ALT_UP(mov r0, r10) @ fake it for UP > orr r10, r10, r0 @ Set required bits > - teq r10, r0 @ Were they already set? > - mcrne p15, 0, r10, c1, c0, 1 @ No, update register > -#endif > + mcr p15, 0, r10, c1, c0, 1 @ No, update register > b __v7_setup_cont > > /* >
On Thu, May 25, 2017 at 09:15:19AM -0700, Florian Fainelli wrote: > On 05/18/2017 03:52 AM, Russell King - ARM Linux wrote: > > As a result of a recent bug report, it has been found that certain CPUs > > must always have SMP mode enabled in order for the caches to work. > > > > Remove the conditional on setting the SMP bit(s). > > > > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> > > --- > > This needs to be tested on: > > > > - Cortex A5MP > > - Cortex A9MP > > - Cortex R7MP > > - Cortex A7MP > > - Cortex A12MP > > - Cortex A15MP > > - Cortex A17MP > > - Brahma B15 > > Sorry just saw this, what kind of test do you want me to run on B15? > Should I build a !SMP kernel, or force a SMP kernel with maxcpus=1? What I'm after is testing on any single-core systems with these SMP capable cores. If the core never appears in a single-core configuration, then please let me know so it can be crossed off the list. With the bug that crept in fixed (as pointed out by Tony) there is no difference for kernels built with SMP enabled and detected as a SMP capable CPU.
* Russell King - ARM Linux <linux@armlinux.org.uk> [170525 10:00]: > On Thu, May 25, 2017 at 09:15:19AM -0700, Florian Fainelli wrote: > > On 05/18/2017 03:52 AM, Russell King - ARM Linux wrote: > > > As a result of a recent bug report, it has been found that certain CPUs > > > must always have SMP mode enabled in order for the caches to work. > > > > > > Remove the conditional on setting the SMP bit(s). > > > > > > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> > > > --- > > > This needs to be tested on: > > > > > > - Cortex A5MP > > > - Cortex A9MP > > > - Cortex R7MP > > > - Cortex A7MP > > > - Cortex A12MP > > > - Cortex A15MP > > > - Cortex A17MP > > > - Brahma B15 > > > > Sorry just saw this, what kind of test do you want me to run on B15? > > Should I build a !SMP kernel, or force a SMP kernel with maxcpus=1? > > What I'm after is testing on any single-core systems with these SMP > capable cores. If the core never appears in a single-core configuration, > then please let me know so it can be crossed off the list. > > With the bug that crept in fixed (as pointed out by Tony) there is no > difference for kernels built with SMP enabled and detected as a SMP > capable CPU. At least am437x needs to be tested as it's UP with some quirks. Regards, Tony
On 05/25/2017 09:56 AM, Russell King - ARM Linux wrote: > On Thu, May 25, 2017 at 09:15:19AM -0700, Florian Fainelli wrote: >> On 05/18/2017 03:52 AM, Russell King - ARM Linux wrote: >>> As a result of a recent bug report, it has been found that certain CPUs >>> must always have SMP mode enabled in order for the caches to work. >>> >>> Remove the conditional on setting the SMP bit(s). >>> >>> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> >>> --- >>> This needs to be tested on: >>> >>> - Cortex A5MP >>> - Cortex A9MP >>> - Cortex R7MP >>> - Cortex A7MP >>> - Cortex A12MP >>> - Cortex A15MP >>> - Cortex A17MP >>> - Brahma B15 >> >> Sorry just saw this, what kind of test do you want me to run on B15? >> Should I build a !SMP kernel, or force a SMP kernel with maxcpus=1? > > What I'm after is testing on any single-core systems with these SMP > capable cores. If the core never appears in a single-core configuration, > then please let me know so it can be crossed off the list. We have chips like the 7250 that are single core, and we do run a CONFIG_SMP kernel on this guy as well. Feel free to add: Tested-by: Florian Fainelli <f.fainelli@gmail.com> on 7250 (single core), 7445 (core core) and 7278 (quad core Brahma B53 in 32-bit mode) as well. If you are curious about what we report, B15 report: 7250, 7445: CPU: ARMv7 Processor [420f00f3] revision 3 (ARMv7), cr=30c5387d 7278: CPU: ARMv7 Processor [420f1000] revision 0 (ARMv7), cr=30c5383d > > With the bug that crept in fixed (as pointed out by Tony) there is no > difference for kernels built with SMP enabled and detected as a SMP > capable CPU. > Got it, thanks!
On 18/05/17 11:52, Russell King - ARM Linux wrote: > This needs to be tested on: > ... > - Cortex R7MP I've tested the patch from tonight's linux-next and everything works fine. Cheers Vladimir
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S index 01d64c0b2563..4d48a4cf563b 100644 --- a/arch/arm/mm/proc-v7.S +++ b/arch/arm/mm/proc-v7.S @@ -286,14 +286,10 @@ ENDPROC(cpu_pj4b_do_resume) stmia r12, {r1-r6, lr} @ v7_invalidate_l1 touches r0-r6 bl v7_invalidate_l1 ldmia r12, {r1-r6, lr} -#ifdef CONFIG_SMP + mrc p15, 0, r0, c1, c0, 1 orr r10, r10, #(1 << 6) @ Enable SMP/nAMP mode - ALT_SMP(mrc p15, 0, r0, c1, c0, 1) - ALT_UP(mov r0, r10) @ fake it for UP orr r10, r10, r0 @ Set required bits - teq r10, r0 @ Were they already set? - mcrne p15, 0, r10, c1, c0, 1 @ No, update register -#endif + mcr p15, 0, r10, c1, c0, 1 @ No, update register b __v7_setup_cont /*
As a result of a recent bug report, it has been found that certain CPUs must always have SMP mode enabled in order for the caches to work. Remove the conditional on setting the SMP bit(s). Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> --- This needs to be tested on: - Cortex A5MP - Cortex A9MP - Cortex R7MP - Cortex A7MP - Cortex A12MP - Cortex A15MP - Cortex A17MP - Brahma B15 and any other CPU that mis-identifies itself with a MP-capable CPUID signature that might match one of those CPUs. I'm aware of a Cortex A9 CPU out there that does mis-identify itself as SMP capable but isn't: @ Core indicates it is SMP. Check for Aegis SOC where a single @ Cortex-A9 CPU is present but SMP operations fault. This will also need testing. arch/arm/mm/proc-v7.S | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-)