From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail19l.g19.rapidsite.net (mail19l.g19.rapidsite.net [204.202.242.137]) by ozlabs.org (Postfix) with SMTP id DA8A9DDEEA for ; Wed, 24 Jan 2007 09:34:10 +1100 (EST) Received: from mx87.stngva01.us.mxservers.net (198.173.112.4) by mail19l.g19.rapidsite.net (RS ver 1.0.95vs) with SMTP id 0-0988751645 for ; Tue, 23 Jan 2007 17:34:06 -0500 (EST) From: "Russell McGuire" To: References: Subject: Re: MPC8360E Linux and 2.6.19.2 Date: Tue, 23 Jan 2007 14:33:51 -0800 Message-ID: <000301c73f3e$8fceb780$6405a8c0@absolut> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" In-Reply-To: List-Id: Linux on Embedded PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 -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 , I have walked through the DTS/blob file, after U-boot modifies it, , and can clearly see that the /chosen node, etc.. is getting entered. My original DTS file already has all of the clock speeds entered . 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 , 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