[U-Boot-Users] Debugging U-Boot on 440GP
bpadalino at perigee.com
Wed Nov 26 14:10:15 CET 2003
I am still doing board_init_f and, I believe, I get stuck somewhere around
or at the display_options() function. I have not reached relocate_code()
I understand your frustration with the serial port -- if it were up to me I
would have added it first, but it was not up to me and I need to solder to
some resistor pads. I also believe that UART0 can work in a 4-pin
configuration? At least I hope so.
Lastly, I was thinking about this last night -- is the BDI too invasive in
trying to figure out if U-Boot will boot properly? It sets up the MMU and
TLB by itself through it's init sequence, and I _think_ I am setting them up
properly in U-Boot, but I am not sure. From what I saw in the code in
U-Boot, I am under the assumption that everything in the TLB gets nullified
during the start up sequence so I know, at least, that my flash is being
read at the proper width and that the stack is able to be placed in memory.
I guess I am just at a loss as to what these exception vectors mean anyway.
I verified the U-Boot image was proper so I don't think it's a bad
instruction -- unless it's trying to access memory somewhere that it can't.
But why would I be able to single step through code and not set breakpoints
and have them work properly? Any insight into this would be helpful as
From: u-boot-users-admin at lists.sourceforge.net
[mailto:u-boot-users-admin at lists.sourceforge.net]On Behalf Of Wolfgang
Sent: Wednesday, November 26, 2003 3:33 AM
To: Brian Padalino
Cc: U-Boot Mailing List
Subject: Re: [U-Boot-Users] Debugging U-Boot on 440GP
in message <AKELKEJDICNMBGAOOBLACEOOCHAA.bpadalino at perigee.com> you wrote:
> - Wolfgang: The address of the PC of the 440GP is 0x00000700 or
> 0x00001400, but that is in my DDR memory. I guess I am just missing what
> really going on here.
Either you are trying to debug code _before_ relocation to RAM, then
the exception vectors should still point to your boot image in flash;
or you are trying to debug code _after_ relocation to RAM, in which
case the exception vectors indeed point to RAM (as they should).
> I can single step my way through the display_options functions, and it
> it's trying to write out the serial port (of which it isnt quite connected
> yet so I can't quite verify that yet), but if i set a break point at
> display_options, and let the CPU continue, it will never return to me.
Argh... you don't have a serial port attached? So do this first. IIRC
some 4xx ports even need HW handshake signals to allow any characters
go out of the console port.
> Am I not being patient enough? Does debugging just take a significantly
> longer time?
It depends on how often you do this. The first time is always a bit
> For a preemptive question, once I get U-Boot up and running, I had a linux
> kernel running on the Ebony dev kit -- do you experts forsee any porting
> that will have to be done with that over to the custom platform?
Yes, of course.
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de
How many NASA managers does it take to screw in a lightbulb? "That's
a known problem... don't worry about it."
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
More information about the U-Boot