linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: ken.wilson@opengear.com (Ken Wilson)
To: linux-arm-kernel@lists.infradead.org
Subject: CPU1 fails to boot on Armada 375 DB with 3.16.0-rc6
Date: Tue, 29 Jul 2014 12:13:51 +1000	[thread overview]
Message-ID: <53D7035F.40803@opengear.com> (raw)
In-Reply-To: <20140729015352.GC12303@lunn.ch>

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

  reply	other threads:[~2014-07-29  2:13 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-29  1:14 CPU1 fails to boot on Armada 375 DB with 3.16.0-rc6 Ken Wilson
2014-07-29  1:53 ` Andrew Lunn
2014-07-29  2:13   ` Ken Wilson [this message]
2014-07-29  2:24     ` Andrew Lunn
2014-07-29  2:37       ` Ken Wilson
2014-07-29  9:48 ` Thomas Petazzoni
2014-07-29 10:00   ` Thomas Petazzoni
2014-07-29 10:48     ` Ken Wilson
2014-07-29 21:15       ` Ken Wilson
2014-07-29 22:09         ` Thomas Petazzoni

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53D7035F.40803@opengear.com \
    --to=ken.wilson@opengear.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).