linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: "Russell McGuire" <rmcguire@uwbt.com>
To: <linuxppc-embedded@ozlabs.org>
Subject: Re: MPC8360E Linux and 2.6.19.2
Date: Tue, 23 Jan 2007 14:33:51 -0800	[thread overview]
Message-ID: <000301c73f3e$8fceb780$6405a8c0@absolut> (raw)
In-Reply-To: <mailman.993.1169563649.9285.linuxppc-embedded@ozlabs.org>


I have tracked my 'lockup' to a specific line in /powerpc/kernel/prom.c

In the function: __init unflatten_device_tree(void)
On line:

mem = lab_alloc(size + 4, __alignof__(struct device_node));
mem = (unsigned long) __va(mem);

((u32 *)mem[size / 4] = 0xdeadbeef;


This is causing a lockup when 0xdeadbeef is written. I have no idea why...

My assumption would be that somehow the memory is not ready? Or BATS are not
setup correctly? Perhaps a LAW register?

Is this line dependent on having the DTS tree setup correctly? If so, how
big can the 'memory' node be in the DTS file? I have mine tried a single
bank of 256MB, and of 512MB <I have a single 512MB DIMM at the moment>

-Russ

----------------------------------------------------------------------
Original Message:

All,

Trying to boot up / debug my board with a Rev 1.2 MPC8360E. 

After the kernel launches from U-boot I receive no serial debug, and the
system hangs. 

I am running U-boot 1.1.6. Dirty <which does contains support for the 8360>,

I have walked through the DTS/blob file, after U-boot modifies it, <I turned
on all the debug info>, and can clearly see that the /chosen node, etc.. is
getting entered. My original DTS file already has all of the clock speeds
entered <modeled after the MPC8360xx.dts file that was already in the
DENX-2.6.19.2 kernel release>.

I have limited debug ability via some GPIO leds on our board, I can see that
the kernel starts to run and at least gets to the point where it clears all
the BATs <powerpc/boot/head_32.S and setup_32.c>, at which point I lose
access to the IO space and can no longer write out to the debug lights.
Unfortunately I do not have access to a COP debugger at this point. It
doesn't seem to get to the platform files, or at least I can get the GPIO
access inside the IMMR space to work correctly.

Does anyone have any suggestion per software only debug method that might be
enabled? Or a way to temporarily hack the early serial output so I can see
what is going on?

-Russ

       reply	other threads:[~2007-01-23 22:34 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.993.1169563649.9285.linuxppc-embedded@ozlabs.org>
2007-01-23 22:33 ` Russell McGuire [this message]
2007-01-23 12:49 MPC8360E Linux and 2.6.19.2 Russell McGuire

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='000301c73f3e$8fceb780$6405a8c0@absolut' \
    --to=rmcguire@uwbt.com \
    --cc=linuxppc-embedded@ozlabs.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).