CPU1 fails to boot on Armada 375 DB with 3.16.0-rc6

CPU1 fails to boot on Armada 375 DB with 3.16.0-rc6

[Ken Wilson]

Hi Thomas,
We're running 3.16.0-rc6 on our Rev 2 Armada 375 DB, and we've found 
that the second CPU is not coming up.
Are there any known issues here?

I've also tried starting the 2nd CPU after boot using the sysfs 
interface, but I get the same error.
We're tftpbooting the kernel, using an in-memory ramdisk

Snip from dmesg:

Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 3.16.0-rc6-dirty (kenw at build-ken) (gcc version 4.8.1 (GCC) 
) #7 SMP Tue Jul 29 09:47:30 EST 2014
CPU: ARMv7 Processor [414fc091] revision 1 (ARMv7), cr=10c5387d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine model: Marvell Armada 375 Development Board
bootconsole [earlycon0] enabled
Memory policy: Data cache writeback
BUG: mapping for 0xf1012000 at 0xfff12000 out of vmalloc space
CPU: All CPU(s) started in SVC mode.
PERCPU: Embedded 7 pages/cpu @ee7d5000 s7680 r8192 d12800 u32768
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 522768
Kernel command line: console=ttyS0,115200 earlyprintk root=/dev/ram
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 2063736K/2097152K available (4932K kernel code, 259K rwdata, 
1324K rodata, 235K init, 205K bss, 33416K reserved, 1318912K highmem)
Virtual kernel memory layout:
     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
     fixmap  : 0xffc00000 - 0xffe00000   (2048 kB)
     vmalloc : 0xf0000000 - 0xff000000   ( 240 MB)
     lowmem  : 0xc0000000 - 0xef800000   ( 760 MB)
     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
       .text : 0xc0008000 - 0xc06242d0   (6257 kB)
       .init : 0xc0625000 - 0xc065fe00   ( 236 kB)
       .data : 0xc0660000 - 0xc06a0e80   ( 260 kB)
        .bss : 0xc06a0e80 - 0xc06d43c0   ( 206 kB)
Hierarchical RCU implementation.
     RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
NR_IRQS:16 nr_irqs:16 16
L2C-310 enabling early BRESP for Cortex-A9
L2C-310 full line of zeros enabled for Cortex-A9
L2C-310 dynamic clock gating enabled, standby mode enabled
L2C-310 cache controller enabled, 8 ways, 256 kB
L2C-310: CACHE_ID 0x410054c9, AUX_CTRL 0x46040001
sched_clock: 32 bits at 6MHz, resolution 160ns, wraps every 687194767200ns
Console: colour dummy device 80x30
Calibrating delay loop... 1594.16 BogoMIPS (lpj=7970816)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
CPU: Testing write buffer coherency: ok
CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
Setting up static identity map for 0x4af758 - 0x4af7b0
mvebu-soc-id: MVEBU SoC ID=0x6720, Rev=0x3
Booting CPU 1
CPU1: failed to come online
Brought up 1 CPUs
SMP: Total of 1 processors activated.
CPU: All CPU(s) started in SVC mode.

CPU1 fails to boot on Armada 375 DB with 3.16.0-rc6

[Andrew Lunn]

On Tue, Jul 29, 2014 at 11:14:12AM +1000, Ken Wilson wrote:
> Hi Thomas,
> We're running 3.16.0-rc6 on our Rev 2 Armada 375 DB, and we've found
> that the second CPU is not coming up.
> Are there any known issues here?
> 
> I've also tried starting the 2nd CPU after boot using the sysfs
> interface, but I get the same error.
> We're tftpbooting the kernel, using an in-memory ramdisk
> 
> Snip from dmesg:
> 
> Uncompressing Linux... done, booting the kernel.
> Booting Linux on physical CPU 0x0
> Linux version 3.16.0-rc6-dirty (kenw at build-ken) (gcc version 4.8.1
> (GCC) ) #7 SMP Tue Jul 29 09:47:30 EST 2014
> CPU: ARMv7 Processor [414fc091] revision 1 (ARMv7), cr=10c5387d
> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> Machine model: Marvell Armada 375 Development Board
> bootconsole [earlycon0] enabled
> Memory policy: Data cache writeback
> BUG: mapping for 0xf1012000 at 0xfff12000 out of vmalloc space

Humm, is that the serial port? Do you get a working serial port?

> CPU: All CPU(s) started in SVC mode.
> PERCPU: Embedded 7 pages/cpu @ee7d5000 s7680 r8192 d12800 u32768
> Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 522768
> Kernel command line: console=ttyS0,115200 earlyprintk root=/dev/ram
> PID hash table entries: 4096 (order: 2, 16384 bytes)
> Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
> Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
> Memory: 2063736K/2097152K available (4932K kernel code, 259K rwdata,

Do you have 2G RAM? The DTS file indicates DB has 1G RAM. But if
u-boot is passing the right stuff to the kernel, that should not
matter.

	Andrew

CPU1 fails to boot on Armada 375 DB with 3.16.0-rc6

[Ken Wilson]

On 29/07/14 11:53, Andrew Lunn wrote:
> On Tue, Jul 29, 2014 at 11:14:12AM +1000, Ken Wilson wrote:
>> Hi Thomas,
>> We're running 3.16.0-rc6 on our Rev 2 Armada 375 DB, and we've found
>> that the second CPU is not coming up.
>> Are there any known issues here?
>>
>> I've also tried starting the 2nd CPU after boot using the sysfs
>> interface, but I get the same error.
>> We're tftpbooting the kernel, using an in-memory ramdisk
>>
>> Snip from dmesg:
>>
>> Uncompressing Linux... done, booting the kernel.
>> Booting Linux on physical CPU 0x0
>> Linux version 3.16.0-rc6-dirty (kenw at build-ken) (gcc version 4.8.1
>> (GCC) ) #7 SMP Tue Jul 29 09:47:30 EST 2014
>> CPU: ARMv7 Processor [414fc091] revision 1 (ARMv7), cr=10c5387d
>> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>> Machine model: Marvell Armada 375 Development Board
>> bootconsole [earlycon0] enabled
>> Memory policy: Data cache writeback
>> BUG: mapping for 0xf1012000 at 0xfff12000 out of vmalloc space
> Humm, is that the serial port? Do you get a working serial port?
Good catch, I had an incorrect virtual address in the Kconfig - that is 
fixed as per default now, and I no-longer get the "BUG" statement
The serial port was working before, and this has not had any effect on CPU1.
>
>> CPU: All CPU(s) started in SVC mode.
>> PERCPU: Embedded 7 pages/cpu @ee7d5000 s7680 r8192 d12800 u32768
>> Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 522768
>> Kernel command line: console=ttyS0,115200 earlyprintk root=/dev/ram
>> PID hash table entries: 4096 (order: 2, 16384 bytes)
>> Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
>> Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
>> Memory: 2063736K/2097152K available (4932K kernel code, 259K rwdata,
> Do you have 2G RAM? The DTS file indicates DB has 1G RAM. But if
> u-boot is passing the right stuff to the kernel, that should not
> matter.
>
> 	Andrew
The Rev 2 dev board comes with 2G of RAM.

Thanks,
Ken

CPU1 fails to boot on Armada 375 DB with 3.16.0-rc6

[Andrew Lunn]

> The Rev 2 dev board comes with 2G of RAM.

Hi Ken

Bit of a long short, but try changing the amount of memory in the DTS
file.

	Andrew

CPU1 fails to boot on Armada 375 DB with 3.16.0-rc6

[Ken Wilson]

On 29/07/14 12:24, Andrew Lunn wrote:
>> The Rev 2 dev board comes with 2G of RAM.
> Hi Ken
>
> Bit of a long short, but try changing the amount of memory in the DTS
> file.
>
> 	Andrew
Hi Andrew,
No joy unfortunately :(

Thanks,
Ken

CPU1 fails to boot on Armada 375 DB with 3.16.0-rc6

[Thomas Petazzoni]

Dear Ken Wilson,

On Tue, 29 Jul 2014 11:14:12 +1000, Ken Wilson wrote:
> Hi Thomas,

Hello. Please Cc: me next time if you want to reply.

> We're running 3.16.0-rc6 on our Rev 2 Armada 375 DB, and we've found 
> that the second CPU is not coming up.
> Are there any known issues here?

Yes, issue known.

> Booting CPU 1
> CPU1: failed to come online
> Brought up 1 CPUs
> SMP: Total of 1 processors activated.
> CPU: All CPU(s) started in SVC mode.

This is caused by a bug in Marvell's bootloader, which has been fixed
by them since then, but I'm not sure the fix is already part of a
released version of their U-Boot. If you're interested, I can provide
you with the U-Boot patches, or if you want a kernel-only hack to fix
the problem, apply this patch:

diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
index 2c35f0f..87f6c2e 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -506,6 +506,7 @@ __fixup_smp:
 	@ below address check will need to be #ifdef'd or equivalent
 	@ for the Aegis platform.
 	mrc	p15, 4, r0, c15, c0	@ get SCU base address
+	ldr	r0, =0xf100c000
 	teq	r0, #0x0		@ '0' on actual UP A9 hardware
 	beq	__fixup_smp_on_up	@ So its an A9 UP
 	ldr	r0, [r0, #4]		@ read SCU Config

It basically overrides the SCU address read from the CP15 register,
which the Marvell U-Boot fails to update after changing the internal
register base address.

Let me know if that fix the problem for you. Of course, the above hack
is not upstreamable, and not meant to be upstreamed in any way.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

CPU1 fails to boot on Armada 375 DB with 3.16.0-rc6

[Thomas Petazzoni]

Hello,

On Tue, 29 Jul 2014 11:48:16 +0200, Thomas Petazzoni wrote:

> On Tue, 29 Jul 2014 11:14:12 +1000, Ken Wilson wrote:
> > Hi Thomas,
> 
> Hello. Please Cc: me next time if you want to reply.

Sorry, was a bit too harsh. I wanted to say: "Next time, try to Cc me
if you want to raise my attention and get a timely reply."

> Let me know if that fix the problem for you. Of course, the above hack
> is not upstreamable, and not meant to be upstreamed in any way.

And of course, I forgot to thank you for testing mainline on Armada
375. We're definitely interested in hearing more about the results of
your tests, and maybe some code contributions!

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

CPU1 fails to boot on Armada 375 DB with 3.16.0-rc6

[Ken Wilson]

No worries, sorry I forgot.
This counts as a very timely reply from my perspective.

I?ll apply the patch tomorrow and let you know how I go.

Thanks,
Ken

On 29 Jul 2014, at 8:00 pm, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:

> Hello,
> 
> On Tue, 29 Jul 2014 11:48:16 +0200, Thomas Petazzoni wrote:
> 
>> On Tue, 29 Jul 2014 11:14:12 +1000, Ken Wilson wrote:
>>> Hi Thomas,
>> 
>> Hello. Please Cc: me next time if you want to reply.
> 
> Sorry, was a bit too harsh. I wanted to say: "Next time, try to Cc me
> if you want to raise my attention and get a timely reply."
> 
>> Let me know if that fix the problem for you. Of course, the above hack
>> is not upstreamable, and not meant to be upstreamed in any way.
> 
> And of course, I forgot to thank you for testing mainline on Armada
> 375. We're definitely interested in hearing more about the results of
> your tests, and maybe some code contributions!
> 
> Thanks!
> 
> Thomas
> -- 
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

CPU1 fails to boot on Armada 375 DB with 3.16.0-rc6

[Ken Wilson]

Hi Thomas,
The patch solved the issue

Thanks!
Ken


On 29/07/14 20:48, Ken Wilson wrote:
> No worries, sorry I forgot.
> This counts as a very timely reply from my perspective.
>
> I?ll apply the patch tomorrow and let you know how I go.
>
> Thanks,
> Ken
>
> On 29 Jul 2014, at 8:00 pm, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
>
>> Hello,
>>
>> On Tue, 29 Jul 2014 11:48:16 +0200, Thomas Petazzoni wrote:
>>
>>> On Tue, 29 Jul 2014 11:14:12 +1000, Ken Wilson wrote:
>>>> Hi Thomas,
>>> Hello. Please Cc: me next time if you want to reply.
>> Sorry, was a bit too harsh. I wanted to say: "Next time, try to Cc me
>> if you want to raise my attention and get a timely reply."
>>
>>> Let me know if that fix the problem for you. Of course, the above hack
>>> is not upstreamable, and not meant to be upstreamed in any way.
>> And of course, I forgot to thank you for testing mainline on Armada
>> 375. We're definitely interested in hearing more about the results of
>> your tests, and maybe some code contributions!
>>
>> Thanks!
>>
>> Thomas
>> -- 
>> Thomas Petazzoni, CTO, Free Electrons
>> Embedded Linux, Kernel and Android engineering
>> http://free-electrons.com
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

CPU1 fails to boot on Armada 375 DB with 3.16.0-rc6

[Thomas Petazzoni]

Dear Ken Wilson,

On Wed, 30 Jul 2014 07:15:37 +1000, Ken Wilson wrote:

> Hi Thomas,
> The patch solved the issue

Cool. Let us know if you encounter any issue while testing/using
mainline on 375, or if there are some features of the SoC not supported
in mainline that you are interested in.

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com