* [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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.