[U-Boot-Users] Debugging U-Boot on 440GP

[Brian Padalino]

Wolfgang,

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()
yet.

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
well.

Thanks,
Brian Padalino

-----Original Message-----
From: u-boot-users-admin at lists.sourceforge.net
[mailto:u-boot-users-admin at lists.sourceforge.net]On Behalf Of Wolfgang
Denk
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


Dear brian,

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
is
> 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
says
> 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
more difficult.

> 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.


Best regards,

Wolfgang Denk

--
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
https://lists.sourceforge.net/lists/listinfo/u-boot-users