* [BUG] ARM: socfpga: L2 cache init @ 2015-02-06 10:39 Steffen Trumtrar 2015-02-06 11:05 ` Russell King - ARM Linux 0 siblings, 1 reply; 18+ messages in thread From: Steffen Trumtrar @ 2015-02-06 10:39 UTC (permalink / raw) To: linux-arm-kernel Hi! I have run into a bug on the Socfpga platform. My boards sometimes fail to boot when I have the commit commit 8b5c18f05621394eb108d3fbc9bf98b05e8162db Author: Russell King <rmk+kernel@arm.linux.org.uk> Date: Mon Apr 28 15:55:59 2014 +0100 ARM: l2c: socfpga: convert to generic l2c OF initialisation Remove the explicit call to l2x0_of_init(), converting to the generic infrastructure instead. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> in my tree. I don't really understand why this would change anything, but I can reproduce the problem with the following ktest.pl tests: TEST_START ITERATE 20 TEST_TYPE = boot CHECKOUT = v3.19-rc7 BUILD_TYPE = socfpga_defconfig POST_BUILD = BUILD_NOCLEAN = 1 TEST_START ITERATE 20 TEST_TYPE = boot CHECKOUT = v3.19-rc7 PRE_BUILD = git revert --no-edit 8b5c18f05621394eb108d3fbc9bf98b05e8162db BUILD_TYPE = socfpga_defconfig POST_BUILD = BUILD_NOCLEAN = 1 The first test fails in 3-6 cases and the second one is always successful. Failing means: I don't see anything. From my understanding the generic l2x0_of_init runs before console_init(), so that is why I don't see any messages from the kernel at all, even with earlyprintk. The bug can be reproduced on a Sockit, Socrates and a custom board. So, it all looks like a common socfpga problem, that should be reproducable on other boards as well. Help for understanding and fixing the problem is much appreciated. Thanks, Steffen Trumtrar -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | ^ permalink raw reply [flat|nested] 18+ messages in thread
* [BUG] ARM: socfpga: L2 cache init 2015-02-06 10:39 [BUG] ARM: socfpga: L2 cache init Steffen Trumtrar @ 2015-02-06 11:05 ` Russell King - ARM Linux 2015-02-09 15:53 ` Steffen Trumtrar 0 siblings, 1 reply; 18+ messages in thread From: Russell King - ARM Linux @ 2015-02-06 11:05 UTC (permalink / raw) To: linux-arm-kernel On Fri, Feb 06, 2015 at 11:39:46AM +0100, Steffen Trumtrar wrote: > I have run into a bug on the Socfpga platform. My boards sometimes fail > to boot when I have the commit > > commit 8b5c18f05621394eb108d3fbc9bf98b05e8162db > Author: Russell King <rmk+kernel@arm.linux.org.uk> > Date: Mon Apr 28 15:55:59 2014 +0100 > > ARM: l2c: socfpga: convert to generic l2c OF initialisation > > Remove the explicit call to l2x0_of_init(), converting to the generic > infrastructure instead. > > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> > That should only result in the L2 cache being turned on earlier (before the secondary CPUs come up.) I wonder if there's a bug in the secondary CPU code which is being tickled by it. What we need is some information on the failure - and as you've noticed, the failure occurs before the console is initialised. There's two solutions to that: 1. Enable early printk support (and hope that works) 2. Enable DEBUG_LL support, selecting the DEBUG_SOCFPGA_UART option, and add: { extern void printascii(const char *); printascii(text); } after the vscnprintf() in kernel/printk/printk.c. (I've always used method 2, since that existed long before early printk support was merged - so I've never used method 1 myself.) Thanks. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. ^ permalink raw reply [flat|nested] 18+ messages in thread
* [BUG] ARM: socfpga: L2 cache init 2015-02-06 11:05 ` Russell King - ARM Linux @ 2015-02-09 15:53 ` Steffen Trumtrar 2015-02-09 16:43 ` Dinh Nguyen 0 siblings, 1 reply; 18+ messages in thread From: Steffen Trumtrar @ 2015-02-09 15:53 UTC (permalink / raw) To: linux-arm-kernel Hi! On Fri, Feb 06, 2015 at 11:05:57AM +0000, Russell King - ARM Linux wrote: > On Fri, Feb 06, 2015 at 11:39:46AM +0100, Steffen Trumtrar wrote: > > I have run into a bug on the Socfpga platform. My boards sometimes fail > > to boot when I have the commit > > > > commit 8b5c18f05621394eb108d3fbc9bf98b05e8162db > > Author: Russell King <rmk+kernel@arm.linux.org.uk> > > Date: Mon Apr 28 15:55:59 2014 +0100 > > > > ARM: l2c: socfpga: convert to generic l2c OF initialisation > > > > Remove the explicit call to l2x0_of_init(), converting to the generic > > infrastructure instead. > > > > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> > > > > That should only result in the L2 cache being turned on earlier (before > the secondary CPUs come up.) I wonder if there's a bug in the secondary > CPU code which is being tickled by it. > > What we need is some information on the failure - and as you've noticed, > the failure occurs before the console is initialised. There's two > solutions to that: > > 1. Enable early printk support (and hope that works) Thanks. I actually got it working. Seems I had forgotten something in the config. So, the bootlog now prints Uncompressing Linux... done, booting the kernel. [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Linux version 3.19.0-rc7-test-00001-g7c10eb5fb252 (str at dude) (gcc version 4.9.2 (OSELAS.Toolchain-2014.12.0) ) #163 SMP PREEMPT Mon Feb 9 16:35:27 CET 2015 [ 0.000000] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c5387d [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [ 0.000000] Machine model: Terasic SoCkit [ 0.000000] bootconsole [earlycon0] enabled [ 0.000000] Memory policy: Data cache writealloc [ 0.000000] BUG: mapping for 0xfffec000 at 0xfffec000 out of vmalloc space Early printk initialized [ 0.000000] PERCPU: Embedded 10 pages/cpu @bf7d4000 s11456 r8192 d21312 u40960 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 260096 [ 0.000000] Kernel command line: console=ttyS0,115200 earlyprintk ip=dhcp root=/dev/nfs nfsroot=/home/str/nfsroot/sockit,v3,tcp [ 0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes) [ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [ 0.000000] Memory: 1032636K/1048576K available (4716K kernel code, 222K rwdata, 1412K rodata, 276K init, 127K bss, 15940K reserved, 0K cma-reserved) [ 0.000000] Virtual kernel memory layout: [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) [ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB) [ 0.000000] vmalloc : 0xc0800000 - 0xff000000 (1000 MB) [ 0.000000] lowmem : 0x80000000 - 0xc0000000 (1024 MB) [ 0.000000] modules : 0x7f000000 - 0x80000000 ( 16 MB) [ 0.000000] .text : 0x80008000 - 0x806044d8 (6130 kB) [ 0.000000] .init : 0x80605000 - 0x8064a000 ( 276 kB) [ 0.000000] .data : 0x8064a000 - 0x80681a14 ( 223 kB) [ 0.000000] .bss : 0x80681a14 - 0x806a161c ( 128 kB) [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 [ 0.000000] Preemptible hierarchical RCU implementation. [ 0.000000] NR_IRQS:16 nr_irqs:16 16 [ 0.000000] L2C-310 enabling early BRESP for Cortex-A9 [ 0.000000] L2C-310 full line of zeros enabled for Cortex-A9 [ 0.000000] L2C-310 dynamic clock gating enabled, standby mode enabled [ 0.000000] L2C-310 cache controller enabled, 8 ways, 512 kB [ 0.000000] L2C-310: CACHE_ID 0x410030c9, AUX_CTRL 0x46060001 [ 0.000013] sched_clock: 32 bits at 100MHz, resolution 10ns, wraps every 42949672950ns [ 0.008119] Console: colour dummy device 80x30 [ 0.012670] Calibrating delay loop... 1594.16 BogoMIPS (lpj=7970816) [ 0.052740] pid_max: default: 32768 minimum: 301 [ 0.057509] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes) [ 0.064195] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes) [ 0.071877] CPU: Testing write buffer coherency: ok [ 0.077012] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 [ 0.082841] Setting up static identity map for 0x47cc10 - 0x47cc68 [ 1.139876] CPU1: failed to come online [ 1.143808] Brought up 1 CPUs [ 1.146851] SMP: Total of 1 processors activated (1594.16 BogoMIPS). It looks like there actually is something wrong with the SMP setup. The SoC is a Cortex-A9 dual core and normally both CPUs are started. Maybe it has something to do with BUG: mapping for 0xfffec000 at 0xfffec000 out of vmalloc space 0xfffec000 is the SCU base address. Regards, Steffen -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | ^ permalink raw reply [flat|nested] 18+ messages in thread
* [BUG] ARM: socfpga: L2 cache init 2015-02-09 15:53 ` Steffen Trumtrar @ 2015-02-09 16:43 ` Dinh Nguyen 2015-02-09 18:58 ` Steffen Trumtrar 0 siblings, 1 reply; 18+ messages in thread From: Dinh Nguyen @ 2015-02-09 16:43 UTC (permalink / raw) To: linux-arm-kernel Hi Steffen, On 02/09/2015 09:53 AM, Steffen Trumtrar wrote: > Hi! > > On Fri, Feb 06, 2015 at 11:05:57AM +0000, Russell King - ARM Linux wrote: >> On Fri, Feb 06, 2015 at 11:39:46AM +0100, Steffen Trumtrar wrote: >>> I have run into a bug on the Socfpga platform. My boards sometimes fail >>> to boot when I have the commit >>> >>> commit 8b5c18f05621394eb108d3fbc9bf98b05e8162db >>> Author: Russell King <rmk+kernel@arm.linux.org.uk> >>> Date: Mon Apr 28 15:55:59 2014 +0100 >>> >>> ARM: l2c: socfpga: convert to generic l2c OF initialisation >>> >>> Remove the explicit call to l2x0_of_init(), converting to the generic >>> infrastructure instead. >>> >>> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> >>> >> >> That should only result in the L2 cache being turned on earlier (before >> the secondary CPUs come up.) I wonder if there's a bug in the secondary >> CPU code which is being tickled by it. >> >> What we need is some information on the failure - and as you've noticed, >> the failure occurs before the console is initialised. There's two >> solutions to that: >> >> 1. Enable early printk support (and hope that works) > > Thanks. I actually got it working. Seems I had forgotten something in the > config. So, the bootlog now prints > > Uncompressing Linux... done, booting the kernel. > [ 0.000000] Booting Linux on physical CPU 0x0 > [ 0.000000] Initializing cgroup subsys cpuset > [ 0.000000] Linux version 3.19.0-rc7-test-00001-g7c10eb5fb252 (str at dude) (gcc version 4.9.2 (OSELAS.Toolchain-2014.12.0) ) #163 SMP PREEMPT Mon Feb 9 16:35:27 CET 2015 > [ 0.000000] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c5387d > [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache > [ 0.000000] Machine model: Terasic SoCkit > [ 0.000000] bootconsole [earlycon0] enabled > [ 0.000000] Memory policy: Data cache writealloc > [ 0.000000] BUG: mapping for 0xfffec000 at 0xfffec000 out of vmalloc space > Early printk initialized > [ 0.000000] PERCPU: Embedded 10 pages/cpu @bf7d4000 s11456 r8192 d21312 u40960 > [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 260096 > [ 0.000000] Kernel command line: console=ttyS0,115200 earlyprintk ip=dhcp root=/dev/nfs nfsroot=/home/str/nfsroot/sockit,v3,tcp > [ 0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes) > [ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) > [ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) > [ 0.000000] Memory: 1032636K/1048576K available (4716K kernel code, 222K rwdata, 1412K rodata, 276K init, 127K bss, 15940K reserved, 0K cma-reserved) > [ 0.000000] Virtual kernel memory layout: > [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) > [ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB) > [ 0.000000] vmalloc : 0xc0800000 - 0xff000000 (1000 MB) > [ 0.000000] lowmem : 0x80000000 - 0xc0000000 (1024 MB) > [ 0.000000] modules : 0x7f000000 - 0x80000000 ( 16 MB) > [ 0.000000] .text : 0x80008000 - 0x806044d8 (6130 kB) > [ 0.000000] .init : 0x80605000 - 0x8064a000 ( 276 kB) > [ 0.000000] .data : 0x8064a000 - 0x80681a14 ( 223 kB) > [ 0.000000] .bss : 0x80681a14 - 0x806a161c ( 128 kB) > [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 > [ 0.000000] Preemptible hierarchical RCU implementation. > [ 0.000000] NR_IRQS:16 nr_irqs:16 16 > [ 0.000000] L2C-310 enabling early BRESP for Cortex-A9 > [ 0.000000] L2C-310 full line of zeros enabled for Cortex-A9 > [ 0.000000] L2C-310 dynamic clock gating enabled, standby mode enabled > [ 0.000000] L2C-310 cache controller enabled, 8 ways, 512 kB > [ 0.000000] L2C-310: CACHE_ID 0x410030c9, AUX_CTRL 0x46060001 > [ 0.000013] sched_clock: 32 bits at 100MHz, resolution 10ns, wraps every 42949672950ns > [ 0.008119] Console: colour dummy device 80x30 > [ 0.012670] Calibrating delay loop... 1594.16 BogoMIPS (lpj=7970816) > [ 0.052740] pid_max: default: 32768 minimum: 301 > [ 0.057509] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes) > [ 0.064195] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes) > [ 0.071877] CPU: Testing write buffer coherency: ok > [ 0.077012] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 > [ 0.082841] Setting up static identity map for 0x47cc10 - 0x47cc68 > [ 1.139876] CPU1: failed to come online > [ 1.143808] Brought up 1 CPUs > [ 1.146851] SMP: Total of 1 processors activated (1594.16 BogoMIPS). > > > It looks like there actually is something wrong with the SMP setup. > The SoC is a Cortex-A9 dual core and normally both CPUs are started. > Maybe it has something to do with > > BUG: mapping for 0xfffec000 at 0xfffec000 out of vmalloc space > > 0xfffec000 is the SCU base address. > This printout has been there for quite a while. The fix should be to remove the static define SOCFPGA_SCU_VIRT_BASE. I have a patch for this queue up but haven't had a chance to send it yet. I was able to recreate this error(only 1 CPU coming online), when I build for socfpga_defconfig. But I cannot seem to recreate it if I build for multi_v7_defconfig, both CPUs come up just fine. Would it be possible for you to run your test with multi_v7_defconfig? Thanks, Dinh ^ permalink raw reply [flat|nested] 18+ messages in thread
* [BUG] ARM: socfpga: L2 cache init 2015-02-09 16:43 ` Dinh Nguyen @ 2015-02-09 18:58 ` Steffen Trumtrar 2015-02-09 21:30 ` Steffen Trumtrar 0 siblings, 1 reply; 18+ messages in thread From: Steffen Trumtrar @ 2015-02-09 18:58 UTC (permalink / raw) To: linux-arm-kernel Hi Dinh! On Mon, Feb 09, 2015 at 10:43:39AM -0600, Dinh Nguyen wrote: > Hi Steffen, > > On 02/09/2015 09:53 AM, Steffen Trumtrar wrote: > > Hi! > > > > On Fri, Feb 06, 2015 at 11:05:57AM +0000, Russell King - ARM Linux wrote: > >> On Fri, Feb 06, 2015 at 11:39:46AM +0100, Steffen Trumtrar wrote: > >>> I have run into a bug on the Socfpga platform. My boards sometimes fail > >>> to boot when I have the commit > >>> > >>> commit 8b5c18f05621394eb108d3fbc9bf98b05e8162db > >>> Author: Russell King <rmk+kernel@arm.linux.org.uk> > >>> Date: Mon Apr 28 15:55:59 2014 +0100 > >>> > >>> ARM: l2c: socfpga: convert to generic l2c OF initialisation > >>> > >>> Remove the explicit call to l2x0_of_init(), converting to the generic > >>> infrastructure instead. > >>> > >>> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> > >>> > >> > >> That should only result in the L2 cache being turned on earlier (before > >> the secondary CPUs come up.) I wonder if there's a bug in the secondary > >> CPU code which is being tickled by it. > >> > >> What we need is some information on the failure - and as you've noticed, > >> the failure occurs before the console is initialised. There's two > >> solutions to that: > >> > >> 1. Enable early printk support (and hope that works) > > > > Thanks. I actually got it working. Seems I had forgotten something in the > > config. So, the bootlog now prints > > > > Uncompressing Linux... done, booting the kernel. > > [ 0.000000] Booting Linux on physical CPU 0x0 > > [ 0.000000] Initializing cgroup subsys cpuset > > [ 0.000000] Linux version 3.19.0-rc7-test-00001-g7c10eb5fb252 (str at dude) (gcc version 4.9.2 (OSELAS.Toolchain-2014.12.0) ) #163 SMP PREEMPT Mon Feb 9 16:35:27 CET 2015 > > [ 0.000000] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c5387d > > [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache > > [ 0.000000] Machine model: Terasic SoCkit > > [ 0.000000] bootconsole [earlycon0] enabled > > [ 0.000000] Memory policy: Data cache writealloc > > [ 0.000000] BUG: mapping for 0xfffec000 at 0xfffec000 out of vmalloc space > > Early printk initialized > > [ 0.000000] PERCPU: Embedded 10 pages/cpu @bf7d4000 s11456 r8192 d21312 u40960 > > [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 260096 > > [ 0.000000] Kernel command line: console=ttyS0,115200 earlyprintk ip=dhcp root=/dev/nfs nfsroot=/home/str/nfsroot/sockit,v3,tcp > > [ 0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes) > > [ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) > > [ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) > > [ 0.000000] Memory: 1032636K/1048576K available (4716K kernel code, 222K rwdata, 1412K rodata, 276K init, 127K bss, 15940K reserved, 0K cma-reserved) > > [ 0.000000] Virtual kernel memory layout: > > [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) > > [ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB) > > [ 0.000000] vmalloc : 0xc0800000 - 0xff000000 (1000 MB) > > [ 0.000000] lowmem : 0x80000000 - 0xc0000000 (1024 MB) > > [ 0.000000] modules : 0x7f000000 - 0x80000000 ( 16 MB) > > [ 0.000000] .text : 0x80008000 - 0x806044d8 (6130 kB) > > [ 0.000000] .init : 0x80605000 - 0x8064a000 ( 276 kB) > > [ 0.000000] .data : 0x8064a000 - 0x80681a14 ( 223 kB) > > [ 0.000000] .bss : 0x80681a14 - 0x806a161c ( 128 kB) > > [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 > > [ 0.000000] Preemptible hierarchical RCU implementation. > > [ 0.000000] NR_IRQS:16 nr_irqs:16 16 > > [ 0.000000] L2C-310 enabling early BRESP for Cortex-A9 > > [ 0.000000] L2C-310 full line of zeros enabled for Cortex-A9 > > [ 0.000000] L2C-310 dynamic clock gating enabled, standby mode enabled > > [ 0.000000] L2C-310 cache controller enabled, 8 ways, 512 kB > > [ 0.000000] L2C-310: CACHE_ID 0x410030c9, AUX_CTRL 0x46060001 > > [ 0.000013] sched_clock: 32 bits at 100MHz, resolution 10ns, wraps every 42949672950ns > > [ 0.008119] Console: colour dummy device 80x30 > > [ 0.012670] Calibrating delay loop... 1594.16 BogoMIPS (lpj=7970816) > > [ 0.052740] pid_max: default: 32768 minimum: 301 > > [ 0.057509] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes) > > [ 0.064195] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes) > > [ 0.071877] CPU: Testing write buffer coherency: ok > > [ 0.077012] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 > > [ 0.082841] Setting up static identity map for 0x47cc10 - 0x47cc68 > > [ 1.139876] CPU1: failed to come online > > [ 1.143808] Brought up 1 CPUs > > [ 1.146851] SMP: Total of 1 processors activated (1594.16 BogoMIPS). > > > > > > It looks like there actually is something wrong with the SMP setup. > > The SoC is a Cortex-A9 dual core and normally both CPUs are started. > > Maybe it has something to do with > > > > BUG: mapping for 0xfffec000 at 0xfffec000 out of vmalloc space > > > > 0xfffec000 is the SCU base address. > > > > This printout has been there for quite a while. The fix should be to > remove the static define SOCFPGA_SCU_VIRT_BASE. I have a patch for this > queue up but haven't had a chance to send it yet. > Cool. > I was able to recreate this error(only 1 CPU coming online), when I > build for socfpga_defconfig. But I cannot seem to recreate it if I build > for multi_v7_defconfig, both CPUs come up just fine. > Interessting. > Would it be possible for you to run your test with multi_v7_defconfig? No problem. Will do and get back with the result. Regards, Steffen -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | ^ permalink raw reply [flat|nested] 18+ messages in thread
* [BUG] ARM: socfpga: L2 cache init 2015-02-09 18:58 ` Steffen Trumtrar @ 2015-02-09 21:30 ` Steffen Trumtrar 2015-02-12 22:39 ` Dinh Nguyen 0 siblings, 1 reply; 18+ messages in thread From: Steffen Trumtrar @ 2015-02-09 21:30 UTC (permalink / raw) To: linux-arm-kernel On Mon, Feb 09, 2015 at 07:58:20PM +0100, Steffen Trumtrar wrote: > Hi Dinh! > > On Mon, Feb 09, 2015 at 10:43:39AM -0600, Dinh Nguyen wrote: > > Hi Steffen, > > > > On 02/09/2015 09:53 AM, Steffen Trumtrar wrote: > > > Hi! > > > > > > On Fri, Feb 06, 2015 at 11:05:57AM +0000, Russell King - ARM Linux wrote: > > >> On Fri, Feb 06, 2015 at 11:39:46AM +0100, Steffen Trumtrar wrote: > > >>> I have run into a bug on the Socfpga platform. My boards sometimes fail > > >>> to boot when I have the commit > > >>> > > >>> commit 8b5c18f05621394eb108d3fbc9bf98b05e8162db > > >>> Author: Russell King <rmk+kernel@arm.linux.org.uk> > > >>> Date: Mon Apr 28 15:55:59 2014 +0100 > > >>> > > >>> ARM: l2c: socfpga: convert to generic l2c OF initialisation > > >>> > > >>> Remove the explicit call to l2x0_of_init(), converting to the generic > > >>> infrastructure instead. > > >>> > > >>> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> > > >>> > > >> > > >> That should only result in the L2 cache being turned on earlier (before > > >> the secondary CPUs come up.) I wonder if there's a bug in the secondary > > >> CPU code which is being tickled by it. > > >> > > >> What we need is some information on the failure - and as you've noticed, > > >> the failure occurs before the console is initialised. There's two > > >> solutions to that: > > >> > > >> 1. Enable early printk support (and hope that works) > > > > > > Thanks. I actually got it working. Seems I had forgotten something in the > > > config. So, the bootlog now prints > > > > > > Uncompressing Linux... done, booting the kernel. > > > [ 0.000000] Booting Linux on physical CPU 0x0 > > > [ 0.000000] Initializing cgroup subsys cpuset > > > [ 0.000000] Linux version 3.19.0-rc7-test-00001-g7c10eb5fb252 (str at dude) (gcc version 4.9.2 (OSELAS.Toolchain-2014.12.0) ) #163 SMP PREEMPT Mon Feb 9 16:35:27 CET 2015 > > > [ 0.000000] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c5387d > > > [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache > > > [ 0.000000] Machine model: Terasic SoCkit > > > [ 0.000000] bootconsole [earlycon0] enabled > > > [ 0.000000] Memory policy: Data cache writealloc > > > [ 0.000000] BUG: mapping for 0xfffec000 at 0xfffec000 out of vmalloc space > > > Early printk initialized > > > [ 0.000000] PERCPU: Embedded 10 pages/cpu @bf7d4000 s11456 r8192 d21312 u40960 > > > [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 260096 > > > [ 0.000000] Kernel command line: console=ttyS0,115200 earlyprintk ip=dhcp root=/dev/nfs nfsroot=/home/str/nfsroot/sockit,v3,tcp > > > [ 0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes) > > > [ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) > > > [ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) > > > [ 0.000000] Memory: 1032636K/1048576K available (4716K kernel code, 222K rwdata, 1412K rodata, 276K init, 127K bss, 15940K reserved, 0K cma-reserved) > > > [ 0.000000] Virtual kernel memory layout: > > > [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) > > > [ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB) > > > [ 0.000000] vmalloc : 0xc0800000 - 0xff000000 (1000 MB) > > > [ 0.000000] lowmem : 0x80000000 - 0xc0000000 (1024 MB) > > > [ 0.000000] modules : 0x7f000000 - 0x80000000 ( 16 MB) > > > [ 0.000000] .text : 0x80008000 - 0x806044d8 (6130 kB) > > > [ 0.000000] .init : 0x80605000 - 0x8064a000 ( 276 kB) > > > [ 0.000000] .data : 0x8064a000 - 0x80681a14 ( 223 kB) > > > [ 0.000000] .bss : 0x80681a14 - 0x806a161c ( 128 kB) > > > [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 > > > [ 0.000000] Preemptible hierarchical RCU implementation. > > > [ 0.000000] NR_IRQS:16 nr_irqs:16 16 > > > [ 0.000000] L2C-310 enabling early BRESP for Cortex-A9 > > > [ 0.000000] L2C-310 full line of zeros enabled for Cortex-A9 > > > [ 0.000000] L2C-310 dynamic clock gating enabled, standby mode enabled > > > [ 0.000000] L2C-310 cache controller enabled, 8 ways, 512 kB > > > [ 0.000000] L2C-310: CACHE_ID 0x410030c9, AUX_CTRL 0x46060001 > > > [ 0.000013] sched_clock: 32 bits at 100MHz, resolution 10ns, wraps every 42949672950ns > > > [ 0.008119] Console: colour dummy device 80x30 > > > [ 0.012670] Calibrating delay loop... 1594.16 BogoMIPS (lpj=7970816) > > > [ 0.052740] pid_max: default: 32768 minimum: 301 > > > [ 0.057509] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes) > > > [ 0.064195] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes) > > > [ 0.071877] CPU: Testing write buffer coherency: ok > > > [ 0.077012] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 > > > [ 0.082841] Setting up static identity map for 0x47cc10 - 0x47cc68 > > > [ 1.139876] CPU1: failed to come online > > > [ 1.143808] Brought up 1 CPUs > > > [ 1.146851] SMP: Total of 1 processors activated (1594.16 BogoMIPS). > > > > > > > > > It looks like there actually is something wrong with the SMP setup. > > > The SoC is a Cortex-A9 dual core and normally both CPUs are started. > > > Maybe it has something to do with > > > > > > BUG: mapping for 0xfffec000 at 0xfffec000 out of vmalloc space > > > > > > 0xfffec000 is the SCU base address. > > > > > > > This printout has been there for quite a while. The fix should be to > > remove the static define SOCFPGA_SCU_VIRT_BASE. I have a patch for this > > queue up but haven't had a chance to send it yet. > > > > Cool. > > > I was able to recreate this error(only 1 CPU coming online), when I > > build for socfpga_defconfig. But I cannot seem to recreate it if I build > > for multi_v7_defconfig, both CPUs come up just fine. > > > > Interessting. > > > Would it be possible for you to run your test with multi_v7_defconfig? > > No problem. Will do and get back with the result. > Doesn't seem to make such a big difference for me. It still sometimes doesn't boot. (I can't give any statistics, because ktest.pl is sadly not very reliable in finding all successful/failed boots and I'm to lazy to count) Regards, Steffen -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | ^ permalink raw reply [flat|nested] 18+ messages in thread
* [BUG] ARM: socfpga: L2 cache init 2015-02-09 21:30 ` Steffen Trumtrar @ 2015-02-12 22:39 ` Dinh Nguyen 2015-02-13 8:01 ` Steffen Trumtrar 0 siblings, 1 reply; 18+ messages in thread From: Dinh Nguyen @ 2015-02-12 22:39 UTC (permalink / raw) To: linux-arm-kernel Hi Steffen, On 02/09/2015 03:30 PM, Steffen Trumtrar wrote: > On Mon, Feb 09, 2015 at 07:58:20PM +0100, Steffen Trumtrar wrote: >> Hi Dinh! >> >> On Mon, Feb 09, 2015 at 10:43:39AM -0600, Dinh Nguyen wrote: >>> Hi Steffen, >>> >>> On 02/09/2015 09:53 AM, Steffen Trumtrar wrote: >>>> Hi! >>>> >>>> On Fri, Feb 06, 2015 at 11:05:57AM +0000, Russell King - ARM Linux wrote: >>>>> On Fri, Feb 06, 2015 at 11:39:46AM +0100, Steffen Trumtrar wrote: >>>>>> I have run into a bug on the Socfpga platform. My boards sometimes fail >>>>>> to boot when I have the commit >>>>>> >>>>>> commit 8b5c18f05621394eb108d3fbc9bf98b05e8162db >>>>>> Author: Russell King <rmk+kernel@arm.linux.org.uk> >>>>>> Date: Mon Apr 28 15:55:59 2014 +0100 >>>>>> >>>>>> ARM: l2c: socfpga: convert to generic l2c OF initialisation >>>>>> >>>>>> Remove the explicit call to l2x0_of_init(), converting to the generic >>>>>> infrastructure instead. >>>>>> >>>>>> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> >>>>>> >>>>> >>>>> That should only result in the L2 cache being turned on earlier (before >>>>> the secondary CPUs come up.) I wonder if there's a bug in the secondary >>>>> CPU code which is being tickled by it. >>>>> >>>>> What we need is some information on the failure - and as you've noticed, >>>>> the failure occurs before the console is initialised. There's two >>>>> solutions to that: >>>>> >>>>> 1. Enable early printk support (and hope that works) >>>> >>>> Thanks. I actually got it working. Seems I had forgotten something in the >>>> config. So, the bootlog now prints >>>> >>>> Uncompressing Linux... done, booting the kernel. >>>> [ 0.000000] Booting Linux on physical CPU 0x0 >>>> [ 0.000000] Initializing cgroup subsys cpuset >>>> [ 0.000000] Linux version 3.19.0-rc7-test-00001-g7c10eb5fb252 (str at dude) (gcc version 4.9.2 (OSELAS.Toolchain-2014.12.0) ) #163 SMP PREEMPT Mon Feb 9 16:35:27 CET 2015 >>>> [ 0.000000] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c5387d >>>> [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache >>>> [ 0.000000] Machine model: Terasic SoCkit >>>> [ 0.000000] bootconsole [earlycon0] enabled >>>> [ 0.000000] Memory policy: Data cache writealloc >>>> [ 0.000000] BUG: mapping for 0xfffec000 at 0xfffec000 out of vmalloc space >>>> Early printk initialized >>>> [ 0.000000] PERCPU: Embedded 10 pages/cpu @bf7d4000 s11456 r8192 d21312 u40960 >>>> [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 260096 >>>> [ 0.000000] Kernel command line: console=ttyS0,115200 earlyprintk ip=dhcp root=/dev/nfs nfsroot=/home/str/nfsroot/sockit,v3,tcp >>>> [ 0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes) >>>> [ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) >>>> [ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) >>>> [ 0.000000] Memory: 1032636K/1048576K available (4716K kernel code, 222K rwdata, 1412K rodata, 276K init, 127K bss, 15940K reserved, 0K cma-reserved) >>>> [ 0.000000] Virtual kernel memory layout: >>>> [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) >>>> [ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB) >>>> [ 0.000000] vmalloc : 0xc0800000 - 0xff000000 (1000 MB) >>>> [ 0.000000] lowmem : 0x80000000 - 0xc0000000 (1024 MB) >>>> [ 0.000000] modules : 0x7f000000 - 0x80000000 ( 16 MB) >>>> [ 0.000000] .text : 0x80008000 - 0x806044d8 (6130 kB) >>>> [ 0.000000] .init : 0x80605000 - 0x8064a000 ( 276 kB) >>>> [ 0.000000] .data : 0x8064a000 - 0x80681a14 ( 223 kB) >>>> [ 0.000000] .bss : 0x80681a14 - 0x806a161c ( 128 kB) >>>> [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 >>>> [ 0.000000] Preemptible hierarchical RCU implementation. >>>> [ 0.000000] NR_IRQS:16 nr_irqs:16 16 >>>> [ 0.000000] L2C-310 enabling early BRESP for Cortex-A9 >>>> [ 0.000000] L2C-310 full line of zeros enabled for Cortex-A9 >>>> [ 0.000000] L2C-310 dynamic clock gating enabled, standby mode enabled >>>> [ 0.000000] L2C-310 cache controller enabled, 8 ways, 512 kB >>>> [ 0.000000] L2C-310: CACHE_ID 0x410030c9, AUX_CTRL 0x46060001 >>>> [ 0.000013] sched_clock: 32 bits at 100MHz, resolution 10ns, wraps every 42949672950ns >>>> [ 0.008119] Console: colour dummy device 80x30 >>>> [ 0.012670] Calibrating delay loop... 1594.16 BogoMIPS (lpj=7970816) >>>> [ 0.052740] pid_max: default: 32768 minimum: 301 >>>> [ 0.057509] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes) >>>> [ 0.064195] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes) >>>> [ 0.071877] CPU: Testing write buffer coherency: ok >>>> [ 0.077012] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 >>>> [ 0.082841] Setting up static identity map for 0x47cc10 - 0x47cc68 >>>> [ 1.139876] CPU1: failed to come online >>>> [ 1.143808] Brought up 1 CPUs >>>> [ 1.146851] SMP: Total of 1 processors activated (1594.16 BogoMIPS). >>>> >>>> >>>> It looks like there actually is something wrong with the SMP setup. >>>> The SoC is a Cortex-A9 dual core and normally both CPUs are started. >>>> Maybe it has something to do with >>>> >>>> BUG: mapping for 0xfffec000 at 0xfffec000 out of vmalloc space >>>> >>>> 0xfffec000 is the SCU base address. >>>> >>> >>> This printout has been there for quite a while. The fix should be to >>> remove the static define SOCFPGA_SCU_VIRT_BASE. I have a patch for this >>> queue up but haven't had a chance to send it yet. >>> >> >> Cool. >> >>> I was able to recreate this error(only 1 CPU coming online), when I >>> build for socfpga_defconfig. But I cannot seem to recreate it if I build >>> for multi_v7_defconfig, both CPUs come up just fine. >>> >> >> Interessting. >> >>> Would it be possible for you to run your test with multi_v7_defconfig? >> >> No problem. Will do and get back with the result. >> > > Doesn't seem to make such a big difference for me. It still sometimes > doesn't boot. (I can't give any statistics, because ktest.pl is sadly > not very reliable in finding all successful/failed boots and I'm to > lazy to count) > Yes, after a while I can reproduce it with both socfpga_defconfig and multi_v7_defconfig. Just seems that the failure is easier to reproduce with socfpga_defconfig. Like Russell said, it seems that enabling the L2 before bringing up the secondary CPU is triggering a bug somewhere. I'm digging around. Thanks, Dinh ^ permalink raw reply [flat|nested] 18+ messages in thread
* [BUG] ARM: socfpga: L2 cache init 2015-02-12 22:39 ` Dinh Nguyen @ 2015-02-13 8:01 ` Steffen Trumtrar 2015-02-17 22:00 ` Dinh Nguyen 0 siblings, 1 reply; 18+ messages in thread From: Steffen Trumtrar @ 2015-02-13 8:01 UTC (permalink / raw) To: linux-arm-kernel Hi Dinh, On Thu, Feb 12, 2015 at 04:39:47PM -0600, Dinh Nguyen wrote: > Hi Steffen, > > On 02/09/2015 03:30 PM, Steffen Trumtrar wrote: > > On Mon, Feb 09, 2015 at 07:58:20PM +0100, Steffen Trumtrar wrote: > >> Hi Dinh! > >> > >> On Mon, Feb 09, 2015 at 10:43:39AM -0600, Dinh Nguyen wrote: > >>> Hi Steffen, > >>> > >>> On 02/09/2015 09:53 AM, Steffen Trumtrar wrote: > >>>> Hi! > >>>> > >>>> On Fri, Feb 06, 2015 at 11:05:57AM +0000, Russell King - ARM Linux wrote: > >>>>> On Fri, Feb 06, 2015 at 11:39:46AM +0100, Steffen Trumtrar wrote: > >>>>>> I have run into a bug on the Socfpga platform. My boards sometimes fail > >>>>>> to boot when I have the commit > >>>>>> > >>>>>> commit 8b5c18f05621394eb108d3fbc9bf98b05e8162db > >>>>>> Author: Russell King <rmk+kernel@arm.linux.org.uk> > >>>>>> Date: Mon Apr 28 15:55:59 2014 +0100 > >>>>>> > >>>>>> ARM: l2c: socfpga: convert to generic l2c OF initialisation > >>>>>> > >>>>>> Remove the explicit call to l2x0_of_init(), converting to the generic > >>>>>> infrastructure instead. > >>>>>> > >>>>>> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> > >>>>>> > >>>>> > >>>>> That should only result in the L2 cache being turned on earlier (before > >>>>> the secondary CPUs come up.) I wonder if there's a bug in the secondary > >>>>> CPU code which is being tickled by it. > >>>>> > >>>>> What we need is some information on the failure - and as you've noticed, > >>>>> the failure occurs before the console is initialised. There's two > >>>>> solutions to that: > >>>>> > >>>>> 1. Enable early printk support (and hope that works) > >>>> > >>>> Thanks. I actually got it working. Seems I had forgotten something in the > >>>> config. So, the bootlog now prints > >>>> > >>>> Uncompressing Linux... done, booting the kernel. > >>>> [ 0.000000] Booting Linux on physical CPU 0x0 > >>>> [ 0.000000] Initializing cgroup subsys cpuset > >>>> [ 0.000000] Linux version 3.19.0-rc7-test-00001-g7c10eb5fb252 (str at dude) (gcc version 4.9.2 (OSELAS.Toolchain-2014.12.0) ) #163 SMP PREEMPT Mon Feb 9 16:35:27 CET 2015 > >>>> [ 0.000000] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c5387d > >>>> [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache > >>>> [ 0.000000] Machine model: Terasic SoCkit > >>>> [ 0.000000] bootconsole [earlycon0] enabled > >>>> [ 0.000000] Memory policy: Data cache writealloc > >>>> [ 0.000000] BUG: mapping for 0xfffec000 at 0xfffec000 out of vmalloc space > >>>> Early printk initialized > >>>> [ 0.000000] PERCPU: Embedded 10 pages/cpu @bf7d4000 s11456 r8192 d21312 u40960 > >>>> [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 260096 > >>>> [ 0.000000] Kernel command line: console=ttyS0,115200 earlyprintk ip=dhcp root=/dev/nfs nfsroot=/home/str/nfsroot/sockit,v3,tcp > >>>> [ 0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes) > >>>> [ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) > >>>> [ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) > >>>> [ 0.000000] Memory: 1032636K/1048576K available (4716K kernel code, 222K rwdata, 1412K rodata, 276K init, 127K bss, 15940K reserved, 0K cma-reserved) > >>>> [ 0.000000] Virtual kernel memory layout: > >>>> [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) > >>>> [ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB) > >>>> [ 0.000000] vmalloc : 0xc0800000 - 0xff000000 (1000 MB) > >>>> [ 0.000000] lowmem : 0x80000000 - 0xc0000000 (1024 MB) > >>>> [ 0.000000] modules : 0x7f000000 - 0x80000000 ( 16 MB) > >>>> [ 0.000000] .text : 0x80008000 - 0x806044d8 (6130 kB) > >>>> [ 0.000000] .init : 0x80605000 - 0x8064a000 ( 276 kB) > >>>> [ 0.000000] .data : 0x8064a000 - 0x80681a14 ( 223 kB) > >>>> [ 0.000000] .bss : 0x80681a14 - 0x806a161c ( 128 kB) > >>>> [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 > >>>> [ 0.000000] Preemptible hierarchical RCU implementation. > >>>> [ 0.000000] NR_IRQS:16 nr_irqs:16 16 > >>>> [ 0.000000] L2C-310 enabling early BRESP for Cortex-A9 > >>>> [ 0.000000] L2C-310 full line of zeros enabled for Cortex-A9 > >>>> [ 0.000000] L2C-310 dynamic clock gating enabled, standby mode enabled > >>>> [ 0.000000] L2C-310 cache controller enabled, 8 ways, 512 kB > >>>> [ 0.000000] L2C-310: CACHE_ID 0x410030c9, AUX_CTRL 0x46060001 > >>>> [ 0.000013] sched_clock: 32 bits at 100MHz, resolution 10ns, wraps every 42949672950ns > >>>> [ 0.008119] Console: colour dummy device 80x30 > >>>> [ 0.012670] Calibrating delay loop... 1594.16 BogoMIPS (lpj=7970816) > >>>> [ 0.052740] pid_max: default: 32768 minimum: 301 > >>>> [ 0.057509] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes) > >>>> [ 0.064195] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes) > >>>> [ 0.071877] CPU: Testing write buffer coherency: ok > >>>> [ 0.077012] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 > >>>> [ 0.082841] Setting up static identity map for 0x47cc10 - 0x47cc68 > >>>> [ 1.139876] CPU1: failed to come online > >>>> [ 1.143808] Brought up 1 CPUs > >>>> [ 1.146851] SMP: Total of 1 processors activated (1594.16 BogoMIPS). > >>>> > >>>> > >>>> It looks like there actually is something wrong with the SMP setup. > >>>> The SoC is a Cortex-A9 dual core and normally both CPUs are started. > >>>> Maybe it has something to do with > >>>> > >>>> BUG: mapping for 0xfffec000 at 0xfffec000 out of vmalloc space > >>>> > >>>> 0xfffec000 is the SCU base address. > >>>> > >>> > >>> This printout has been there for quite a while. The fix should be to > >>> remove the static define SOCFPGA_SCU_VIRT_BASE. I have a patch for this > >>> queue up but haven't had a chance to send it yet. > >>> > >> > >> Cool. > >> > >>> I was able to recreate this error(only 1 CPU coming online), when I > >>> build for socfpga_defconfig. But I cannot seem to recreate it if I build > >>> for multi_v7_defconfig, both CPUs come up just fine. > >>> > >> > >> Interessting. > >> > >>> Would it be possible for you to run your test with multi_v7_defconfig? > >> > >> No problem. Will do and get back with the result. > >> > > > > Doesn't seem to make such a big difference for me. It still sometimes > > doesn't boot. (I can't give any statistics, because ktest.pl is sadly > > not very reliable in finding all successful/failed boots and I'm to > > lazy to count) > > > > Yes, after a while I can reproduce it with both socfpga_defconfig and > multi_v7_defconfig. Just seems that the failure is easier to reproduce > with socfpga_defconfig. > That is "good". At least it shows, that there is a common bug for SoCFPGA and not only in my setup. > Like Russell said, it seems that enabling the L2 before bringing up the > secondary CPU is triggering a bug somewhere. > Yes, seems very likely that Russell is right. > I'm digging around. > Great. Thanks, Steffen -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | ^ permalink raw reply [flat|nested] 18+ messages in thread
* [BUG] ARM: socfpga: L2 cache init 2015-02-13 8:01 ` Steffen Trumtrar @ 2015-02-17 22:00 ` Dinh Nguyen 2015-02-17 22:28 ` Russell King - ARM Linux 0 siblings, 1 reply; 18+ messages in thread From: Dinh Nguyen @ 2015-02-17 22:00 UTC (permalink / raw) To: linux-arm-kernel On Fri, Feb 13, 2015 at 2:01 AM, Steffen Trumtrar <s.trumtrar@pengutronix.de> wrote: > Hi Dinh, > > On Thu, Feb 12, 2015 at 04:39:47PM -0600, Dinh Nguyen wrote: >> Hi Steffen, >> >> On 02/09/2015 03:30 PM, Steffen Trumtrar wrote: >> > On Mon, Feb 09, 2015 at 07:58:20PM +0100, Steffen Trumtrar wrote: >> >> Hi Dinh! >> >> >> >> On Mon, Feb 09, 2015 at 10:43:39AM -0600, Dinh Nguyen wrote: >> >>> Hi Steffen, >> >>> >> >>> On 02/09/2015 09:53 AM, Steffen Trumtrar wrote: >> >>>> Hi! >> >>>> >> >>>> On Fri, Feb 06, 2015 at 11:05:57AM +0000, Russell King - ARM Linux wrote: >> >>>>> On Fri, Feb 06, 2015 at 11:39:46AM +0100, Steffen Trumtrar wrote: >> >>>>>> I have run into a bug on the Socfpga platform. My boards sometimes fail >> >>>>>> to boot when I have the commit >> >>>>>> >> >>>>>> commit 8b5c18f05621394eb108d3fbc9bf98b05e8162db >> >>>>>> Author: Russell King <rmk+kernel@arm.linux.org.uk> >> >>>>>> Date: Mon Apr 28 15:55:59 2014 +0100 >> >>>>>> >> >>>>>> ARM: l2c: socfpga: convert to generic l2c OF initialisation >> >>>>>> >> >>>>>> Remove the explicit call to l2x0_of_init(), converting to the generic >> >>>>>> infrastructure instead. >> >>>>>> >> >>>>>> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> >> >>>>>> >> >>>>> >> >>>>> That should only result in the L2 cache being turned on earlier (before >> >>>>> the secondary CPUs come up.) I wonder if there's a bug in the secondary >> >>>>> CPU code which is being tickled by it. >> >>>>> >> >>>>> What we need is some information on the failure - and as you've noticed, >> >>>>> the failure occurs before the console is initialised. There's two >> >>>>> solutions to that: >> >>>>> >> >>>>> 1. Enable early printk support (and hope that works) >> >>>> >> >>>> Thanks. I actually got it working. Seems I had forgotten something in the >> >>>> config. So, the bootlog now prints >> >>>> >> >>>> Uncompressing Linux... done, booting the kernel. >> >>>> [ 0.000000] Booting Linux on physical CPU 0x0 >> >>>> [ 0.000000] Initializing cgroup subsys cpuset >> >>>> [ 0.000000] Linux version 3.19.0-rc7-test-00001-g7c10eb5fb252 (str at dude) (gcc version 4.9.2 (OSELAS.Toolchain-2014.12.0) ) #163 SMP PREEMPT Mon Feb 9 16:35:27 CET 2015 >> >>>> [ 0.000000] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c5387d >> >>>> [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache >> >>>> [ 0.000000] Machine model: Terasic SoCkit >> >>>> [ 0.000000] bootconsole [earlycon0] enabled >> >>>> [ 0.000000] Memory policy: Data cache writealloc >> >>>> [ 0.000000] BUG: mapping for 0xfffec000 at 0xfffec000 out of vmalloc space >> >>>> Early printk initialized >> >>>> [ 0.000000] PERCPU: Embedded 10 pages/cpu @bf7d4000 s11456 r8192 d21312 u40960 >> >>>> [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 260096 >> >>>> [ 0.000000] Kernel command line: console=ttyS0,115200 earlyprintk ip=dhcp root=/dev/nfs nfsroot=/home/str/nfsroot/sockit,v3,tcp >> >>>> [ 0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes) >> >>>> [ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) >> >>>> [ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) >> >>>> [ 0.000000] Memory: 1032636K/1048576K available (4716K kernel code, 222K rwdata, 1412K rodata, 276K init, 127K bss, 15940K reserved, 0K cma-reserved) >> >>>> [ 0.000000] Virtual kernel memory layout: >> >>>> [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) >> >>>> [ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB) >> >>>> [ 0.000000] vmalloc : 0xc0800000 - 0xff000000 (1000 MB) >> >>>> [ 0.000000] lowmem : 0x80000000 - 0xc0000000 (1024 MB) >> >>>> [ 0.000000] modules : 0x7f000000 - 0x80000000 ( 16 MB) >> >>>> [ 0.000000] .text : 0x80008000 - 0x806044d8 (6130 kB) >> >>>> [ 0.000000] .init : 0x80605000 - 0x8064a000 ( 276 kB) >> >>>> [ 0.000000] .data : 0x8064a000 - 0x80681a14 ( 223 kB) >> >>>> [ 0.000000] .bss : 0x80681a14 - 0x806a161c ( 128 kB) >> >>>> [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 >> >>>> [ 0.000000] Preemptible hierarchical RCU implementation. >> >>>> [ 0.000000] NR_IRQS:16 nr_irqs:16 16 >> >>>> [ 0.000000] L2C-310 enabling early BRESP for Cortex-A9 >> >>>> [ 0.000000] L2C-310 full line of zeros enabled for Cortex-A9 >> >>>> [ 0.000000] L2C-310 dynamic clock gating enabled, standby mode enabled >> >>>> [ 0.000000] L2C-310 cache controller enabled, 8 ways, 512 kB >> >>>> [ 0.000000] L2C-310: CACHE_ID 0x410030c9, AUX_CTRL 0x46060001 >> >>>> [ 0.000013] sched_clock: 32 bits at 100MHz, resolution 10ns, wraps every 42949672950ns >> >>>> [ 0.008119] Console: colour dummy device 80x30 >> >>>> [ 0.012670] Calibrating delay loop... 1594.16 BogoMIPS (lpj=7970816) >> >>>> [ 0.052740] pid_max: default: 32768 minimum: 301 >> >>>> [ 0.057509] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes) >> >>>> [ 0.064195] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes) >> >>>> [ 0.071877] CPU: Testing write buffer coherency: ok >> >>>> [ 0.077012] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 >> >>>> [ 0.082841] Setting up static identity map for 0x47cc10 - 0x47cc68 >> >>>> [ 1.139876] CPU1: failed to come online >> >>>> [ 1.143808] Brought up 1 CPUs >> >>>> [ 1.146851] SMP: Total of 1 processors activated (1594.16 BogoMIPS). >> >>>> >> >>>> >> >>>> It looks like there actually is something wrong with the SMP setup. >> >>>> The SoC is a Cortex-A9 dual core and normally both CPUs are started. >> >>>> Maybe it has something to do with >> >>>> >> >>>> BUG: mapping for 0xfffec000 at 0xfffec000 out of vmalloc space >> >>>> >> >>>> 0xfffec000 is the SCU base address. >> >>>> >> >>> >> >>> This printout has been there for quite a while. The fix should be to >> >>> remove the static define SOCFPGA_SCU_VIRT_BASE. I have a patch for this >> >>> queue up but haven't had a chance to send it yet. >> >>> >> >> >> >> Cool. >> >> >> >>> I was able to recreate this error(only 1 CPU coming online), when I >> >>> build for socfpga_defconfig. But I cannot seem to recreate it if I build >> >>> for multi_v7_defconfig, both CPUs come up just fine. >> >>> >> >> >> >> Interessting. >> >> >> >>> Would it be possible for you to run your test with multi_v7_defconfig? >> >> >> >> No problem. Will do and get back with the result. >> >> >> > >> > Doesn't seem to make such a big difference for me. It still sometimes >> > doesn't boot. (I can't give any statistics, because ktest.pl is sadly >> > not very reliable in finding all successful/failed boots and I'm to >> > lazy to count) >> > >> >> Yes, after a while I can reproduce it with both socfpga_defconfig and >> multi_v7_defconfig. Just seems that the failure is easier to reproduce >> with socfpga_defconfig. >> > > That is "good". At least it shows, that there is a common bug for SoCFPGA > and not only in my setup. > >> Like Russell said, it seems that enabling the L2 before bringing up the >> secondary CPU is triggering a bug somewhere. >> > > Yes, seems very likely that Russell is right. The bug doesn't happen if I disable the L2. Digging more... Dinh ^ permalink raw reply [flat|nested] 18+ messages in thread
* [BUG] ARM: socfpga: L2 cache init 2015-02-17 22:00 ` Dinh Nguyen @ 2015-02-17 22:28 ` Russell King - ARM Linux 2015-02-24 23:55 ` Dinh Nguyen 0 siblings, 1 reply; 18+ messages in thread From: Russell King - ARM Linux @ 2015-02-17 22:28 UTC (permalink / raw) To: linux-arm-kernel On Tue, Feb 17, 2015 at 04:00:47PM -0600, Dinh Nguyen wrote: > On Fri, Feb 13, 2015 at 2:01 AM, Steffen Trumtrar > <s.trumtrar@pengutronix.de> wrote: > > Yes, seems very likely that Russell is right. > > The bug doesn't happen if I disable the L2. Digging more... What ensures that the value written to socfpga_cpu1start_addr (by of_property_read_u32() in socfpga_sysmgr_init(), called at .init_irq time) is visible to the secondary CPU? >From what I can see, the physical address written there is not guaranteed to be flushed from all levels of cache. The flush_cache_all() in socfpga_boot_secondary() won't do the job - that won't touch the L2C-310. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. ^ permalink raw reply [flat|nested] 18+ messages in thread
* [BUG] ARM: socfpga: L2 cache init 2015-02-17 22:28 ` Russell King - ARM Linux @ 2015-02-24 23:55 ` Dinh Nguyen 2015-02-25 8:21 ` Steffen Trumtrar 2015-02-25 9:26 ` Russell King - ARM Linux 0 siblings, 2 replies; 18+ messages in thread From: Dinh Nguyen @ 2015-02-24 23:55 UTC (permalink / raw) To: linux-arm-kernel On Tue, Feb 17, 2015 at 4:28 PM, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > On Tue, Feb 17, 2015 at 04:00:47PM -0600, Dinh Nguyen wrote: >> On Fri, Feb 13, 2015 at 2:01 AM, Steffen Trumtrar >> <s.trumtrar@pengutronix.de> wrote: >> > Yes, seems very likely that Russell is right. >> >> The bug doesn't happen if I disable the L2. Digging more... > > What ensures that the value written to socfpga_cpu1start_addr (by > of_property_read_u32() in socfpga_sysmgr_init(), called at .init_irq > time) is visible to the secondary CPU? Yes, I was able use a JTAG debugger and can see that the secondary CPU is not seeing socfpga_cpu1start_addr correctly when the error occurs. > > From what I can see, the physical address written there is not > guaranteed to be flushed from all levels of cache. > > The flush_cache_all() in socfpga_boot_secondary() won't do the job - > that won't touch the L2C-310. > Do you have a recommendation on what should be done? Thanks, Dinh ^ permalink raw reply [flat|nested] 18+ messages in thread
* [BUG] ARM: socfpga: L2 cache init 2015-02-24 23:55 ` Dinh Nguyen @ 2015-02-25 8:21 ` Steffen Trumtrar 2015-02-25 9:26 ` Russell King - ARM Linux 1 sibling, 0 replies; 18+ messages in thread From: Steffen Trumtrar @ 2015-02-25 8:21 UTC (permalink / raw) To: linux-arm-kernel On Tue, Feb 24, 2015 at 05:55:05PM -0600, Dinh Nguyen wrote: > On Tue, Feb 17, 2015 at 4:28 PM, Russell King - ARM Linux > <linux@arm.linux.org.uk> wrote: > > On Tue, Feb 17, 2015 at 04:00:47PM -0600, Dinh Nguyen wrote: > >> On Fri, Feb 13, 2015 at 2:01 AM, Steffen Trumtrar > >> <s.trumtrar@pengutronix.de> wrote: > >> > Yes, seems very likely that Russell is right. > >> > >> The bug doesn't happen if I disable the L2. Digging more... > > > > What ensures that the value written to socfpga_cpu1start_addr (by > > of_property_read_u32() in socfpga_sysmgr_init(), called at .init_irq > > time) is visible to the secondary CPU? > > Yes, I was able use a JTAG debugger and can see that the > secondary CPU is not seeing socfpga_cpu1start_addr correctly when the > error occurs. > \o/ very good. That sounds like the bug can be fixed soon. Thanks, Steffen -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | ^ permalink raw reply [flat|nested] 18+ messages in thread
* [BUG] ARM: socfpga: L2 cache init 2015-02-24 23:55 ` Dinh Nguyen 2015-02-25 8:21 ` Steffen Trumtrar @ 2015-02-25 9:26 ` Russell King - ARM Linux 2015-02-25 16:30 ` Dinh Nguyen 1 sibling, 1 reply; 18+ messages in thread From: Russell King - ARM Linux @ 2015-02-25 9:26 UTC (permalink / raw) To: linux-arm-kernel On Tue, Feb 24, 2015 at 05:55:05PM -0600, Dinh Nguyen wrote: > Do you have a recommendation on what should be done? Please try this: arch/arm/mach-socfpga/socfpga.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/arch/arm/mach-socfpga/socfpga.c b/arch/arm/mach-socfpga/socfpga.c index 383d61e138af..f5e597c207b9 100644 --- a/arch/arm/mach-socfpga/socfpga.c +++ b/arch/arm/mach-socfpga/socfpga.c @@ -23,6 +23,7 @@ #include <asm/hardware/cache-l2x0.h> #include <asm/mach/arch.h> #include <asm/mach/map.h> +#include <asm/cacheflush.h> #include "core.h" @@ -73,6 +74,10 @@ void __init socfpga_sysmgr_init(void) (u32 *) &socfpga_cpu1start_addr)) pr_err("SMP: Need cpu1-start-addr in device tree.\n"); + /* Ensure that socfpga_cpu1start_addr is visible to other CPUs */ + smp_wmb(); + sync_cache_w(&socfpga_cpu1start_addr); + sys_manager_base_addr = of_iomap(np, 0); np = of_find_compatible_node(NULL, NULL, "altr,rst-mgr"); -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. ^ permalink raw reply related [flat|nested] 18+ messages in thread
* [BUG] ARM: socfpga: L2 cache init 2015-02-25 9:26 ` Russell King - ARM Linux @ 2015-02-25 16:30 ` Dinh Nguyen 2015-02-26 8:30 ` Steffen Trumtrar 2015-03-04 10:23 ` Steffen Trumtrar 0 siblings, 2 replies; 18+ messages in thread From: Dinh Nguyen @ 2015-02-25 16:30 UTC (permalink / raw) To: linux-arm-kernel On Wed, Feb 25, 2015 at 3:26 AM, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > On Tue, Feb 24, 2015 at 05:55:05PM -0600, Dinh Nguyen wrote: >> Do you have a recommendation on what should be done? > > Please try this: > > arch/arm/mach-socfpga/socfpga.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/arch/arm/mach-socfpga/socfpga.c b/arch/arm/mach-socfpga/socfpga.c > index 383d61e138af..f5e597c207b9 100644 > --- a/arch/arm/mach-socfpga/socfpga.c > +++ b/arch/arm/mach-socfpga/socfpga.c > @@ -23,6 +23,7 @@ > #include <asm/hardware/cache-l2x0.h> > #include <asm/mach/arch.h> > #include <asm/mach/map.h> > +#include <asm/cacheflush.h> > > #include "core.h" > > @@ -73,6 +74,10 @@ void __init socfpga_sysmgr_init(void) > (u32 *) &socfpga_cpu1start_addr)) > pr_err("SMP: Need cpu1-start-addr in device tree.\n"); > > + /* Ensure that socfpga_cpu1start_addr is visible to other CPUs */ > + smp_wmb(); > + sync_cache_w(&socfpga_cpu1start_addr); > + > sys_manager_base_addr = of_iomap(np, 0); > > np = of_find_compatible_node(NULL, NULL, "altr,rst-mgr"); > > -- Thanks Russell! I have been able to run the test for > 30 minutes now with both cores coming up just fine. Do you mind taking this patch for 4.0-rc? If so, Tested-by: Dinh Nguyen <dinguyen@opensource.altera.com> Steffen, if you don't mind, do you want to test on your setup as well? Thanks, Dinh ^ permalink raw reply [flat|nested] 18+ messages in thread
* [BUG] ARM: socfpga: L2 cache init 2015-02-25 16:30 ` Dinh Nguyen @ 2015-02-26 8:30 ` Steffen Trumtrar 2015-03-04 10:23 ` Steffen Trumtrar 1 sibling, 0 replies; 18+ messages in thread From: Steffen Trumtrar @ 2015-02-26 8:30 UTC (permalink / raw) To: linux-arm-kernel On Wed, Feb 25, 2015 at 10:30:32AM -0600, Dinh Nguyen wrote: > On Wed, Feb 25, 2015 at 3:26 AM, Russell King - ARM Linux > <linux@arm.linux.org.uk> wrote: > > On Tue, Feb 24, 2015 at 05:55:05PM -0600, Dinh Nguyen wrote: > >> Do you have a recommendation on what should be done? > > > > Please try this: > > > > arch/arm/mach-socfpga/socfpga.c | 5 +++++ > > 1 file changed, 5 insertions(+) > > > > diff --git a/arch/arm/mach-socfpga/socfpga.c b/arch/arm/mach-socfpga/socfpga.c > > index 383d61e138af..f5e597c207b9 100644 > > --- a/arch/arm/mach-socfpga/socfpga.c > > +++ b/arch/arm/mach-socfpga/socfpga.c > > @@ -23,6 +23,7 @@ > > #include <asm/hardware/cache-l2x0.h> > > #include <asm/mach/arch.h> > > #include <asm/mach/map.h> > > +#include <asm/cacheflush.h> > > > > #include "core.h" > > > > @@ -73,6 +74,10 @@ void __init socfpga_sysmgr_init(void) > > (u32 *) &socfpga_cpu1start_addr)) > > pr_err("SMP: Need cpu1-start-addr in device tree.\n"); > > > > + /* Ensure that socfpga_cpu1start_addr is visible to other CPUs */ > > + smp_wmb(); > > + sync_cache_w(&socfpga_cpu1start_addr); > > + > > sys_manager_base_addr = of_iomap(np, 0); > > > > np = of_find_compatible_node(NULL, NULL, "altr,rst-mgr"); > > > > -- > > > Thanks Russell! I have been able to run the test for > 30 minutes now > with both cores coming up just fine. > \o/ That sounds very good. > Do you mind taking this patch for 4.0-rc? If so, > > Tested-by: Dinh Nguyen <dinguyen@opensource.altera.com> > > Steffen, if you don't mind, do you want to test on your setup as well? > Yes, of course. Let's see how fast I can get my test running again, my Sockit is at the Embedded World ATM :-( Thanks, Steffen -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | ^ permalink raw reply [flat|nested] 18+ messages in thread
* [BUG] ARM: socfpga: L2 cache init 2015-02-25 16:30 ` Dinh Nguyen 2015-02-26 8:30 ` Steffen Trumtrar @ 2015-03-04 10:23 ` Steffen Trumtrar 2015-03-04 18:37 ` Dinh Nguyen 1 sibling, 1 reply; 18+ messages in thread From: Steffen Trumtrar @ 2015-03-04 10:23 UTC (permalink / raw) To: linux-arm-kernel On Wed, Feb 25, 2015 at 10:30:32AM -0600, Dinh Nguyen wrote: > On Wed, Feb 25, 2015 at 3:26 AM, Russell King - ARM Linux > <linux@arm.linux.org.uk> wrote: > > On Tue, Feb 24, 2015 at 05:55:05PM -0600, Dinh Nguyen wrote: > >> Do you have a recommendation on what should be done? > > > > Please try this: > > > > arch/arm/mach-socfpga/socfpga.c | 5 +++++ > > 1 file changed, 5 insertions(+) > > > > diff --git a/arch/arm/mach-socfpga/socfpga.c b/arch/arm/mach-socfpga/socfpga.c > > index 383d61e138af..f5e597c207b9 100644 > > --- a/arch/arm/mach-socfpga/socfpga.c > > +++ b/arch/arm/mach-socfpga/socfpga.c > > @@ -23,6 +23,7 @@ > > #include <asm/hardware/cache-l2x0.h> > > #include <asm/mach/arch.h> > > #include <asm/mach/map.h> > > +#include <asm/cacheflush.h> > > > > #include "core.h" > > > > @@ -73,6 +74,10 @@ void __init socfpga_sysmgr_init(void) > > (u32 *) &socfpga_cpu1start_addr)) > > pr_err("SMP: Need cpu1-start-addr in device tree.\n"); > > > > + /* Ensure that socfpga_cpu1start_addr is visible to other CPUs */ > > + smp_wmb(); > > + sync_cache_w(&socfpga_cpu1start_addr); > > + > > sys_manager_base_addr = of_iomap(np, 0); > > > > np = of_find_compatible_node(NULL, NULL, "altr,rst-mgr"); > > > > -- > > > Thanks Russell! I have been able to run the test for > 30 minutes now > with both cores coming up just fine. > > Do you mind taking this patch for 4.0-rc? If so, > > Tested-by: Dinh Nguyen <dinguyen@opensource.altera.com> > > Steffen, if you don't mind, do you want to test on your setup as well? Looks good for me, too: Tested-by: Steffen Trumtrar <s.trumtrar@pengutronix.de> Thanks, Steffen -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | ^ permalink raw reply [flat|nested] 18+ messages in thread
* [BUG] ARM: socfpga: L2 cache init 2015-03-04 10:23 ` Steffen Trumtrar @ 2015-03-04 18:37 ` Dinh Nguyen 2015-03-09 17:15 ` Russell King - ARM Linux 0 siblings, 1 reply; 18+ messages in thread From: Dinh Nguyen @ 2015-03-04 18:37 UTC (permalink / raw) To: linux-arm-kernel On 03/04/2015 04:23 AM, Steffen Trumtrar wrote: > On Wed, Feb 25, 2015 at 10:30:32AM -0600, Dinh Nguyen wrote: >> On Wed, Feb 25, 2015 at 3:26 AM, Russell King - ARM Linux >> <linux@arm.linux.org.uk> wrote: >>> On Tue, Feb 24, 2015 at 05:55:05PM -0600, Dinh Nguyen wrote: >>>> Do you have a recommendation on what should be done? >>> >>> Please try this: >>> >>> arch/arm/mach-socfpga/socfpga.c | 5 +++++ >>> 1 file changed, 5 insertions(+) >>> >>> diff --git a/arch/arm/mach-socfpga/socfpga.c b/arch/arm/mach-socfpga/socfpga.c >>> index 383d61e138af..f5e597c207b9 100644 >>> --- a/arch/arm/mach-socfpga/socfpga.c >>> +++ b/arch/arm/mach-socfpga/socfpga.c >>> @@ -23,6 +23,7 @@ >>> #include <asm/hardware/cache-l2x0.h> >>> #include <asm/mach/arch.h> >>> #include <asm/mach/map.h> >>> +#include <asm/cacheflush.h> >>> >>> #include "core.h" >>> >>> @@ -73,6 +74,10 @@ void __init socfpga_sysmgr_init(void) >>> (u32 *) &socfpga_cpu1start_addr)) >>> pr_err("SMP: Need cpu1-start-addr in device tree.\n"); >>> >>> + /* Ensure that socfpga_cpu1start_addr is visible to other CPUs */ >>> + smp_wmb(); >>> + sync_cache_w(&socfpga_cpu1start_addr); >>> + >>> sys_manager_base_addr = of_iomap(np, 0); >>> >>> np = of_find_compatible_node(NULL, NULL, "altr,rst-mgr"); >>> >>> -- >> >> >> Thanks Russell! I have been able to run the test for > 30 minutes now >> with both cores coming up just fine. >> >> Do you mind taking this patch for 4.0-rc? If so, >> >> Tested-by: Dinh Nguyen <dinguyen@opensource.altera.com> >> >> Steffen, if you don't mind, do you want to test on your setup as well? > > Looks good for me, too: > > Tested-by: Steffen Trumtrar <s.trumtrar@pengutronix.de> > Steffen, thanks for testing. Russell, if you don't mind, I'll take this patch through my tree as I have a couple of other fixes for 4.0-rc as well. Thanks, Dinh ^ permalink raw reply [flat|nested] 18+ messages in thread
* [BUG] ARM: socfpga: L2 cache init 2015-03-04 18:37 ` Dinh Nguyen @ 2015-03-09 17:15 ` Russell King - ARM Linux 0 siblings, 0 replies; 18+ messages in thread From: Russell King - ARM Linux @ 2015-03-09 17:15 UTC (permalink / raw) To: linux-arm-kernel On Wed, Mar 04, 2015 at 12:37:26PM -0600, Dinh Nguyen wrote: > On 03/04/2015 04:23 AM, Steffen Trumtrar wrote: > > Looks good for me, too: > > > > Tested-by: Steffen Trumtrar <s.trumtrar@pengutronix.de> > > > > Steffen, thanks for testing. > > Russell, if you don't mind, I'll take this patch through my tree as I > have a couple of other fixes for 4.0-rc as well. That's fine, especially as I've been recovering post-op. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2015-03-09 17:15 UTC | newest] Thread overview: 18+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-02-06 10:39 [BUG] ARM: socfpga: L2 cache init Steffen Trumtrar 2015-02-06 11:05 ` Russell King - ARM Linux 2015-02-09 15:53 ` Steffen Trumtrar 2015-02-09 16:43 ` Dinh Nguyen 2015-02-09 18:58 ` Steffen Trumtrar 2015-02-09 21:30 ` Steffen Trumtrar 2015-02-12 22:39 ` Dinh Nguyen 2015-02-13 8:01 ` Steffen Trumtrar 2015-02-17 22:00 ` Dinh Nguyen 2015-02-17 22:28 ` Russell King - ARM Linux 2015-02-24 23:55 ` Dinh Nguyen 2015-02-25 8:21 ` Steffen Trumtrar 2015-02-25 9:26 ` Russell King - ARM Linux 2015-02-25 16:30 ` Dinh Nguyen 2015-02-26 8:30 ` Steffen Trumtrar 2015-03-04 10:23 ` Steffen Trumtrar 2015-03-04 18:37 ` Dinh Nguyen 2015-03-09 17:15 ` Russell King - ARM Linux
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).