Thanks everyone for the replies. I took a look at those pages and they were a little helpful.
Some things I am not quite clear about yet: - Scott: What you told me was excellent. I can now debug later functions, but it doesn't always catch them. - Chuck: I didn't realize you read this mailing list. But either way, are you telling me to comment out the disabling of the debug registers so the BDI retains control? - 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.
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.
Am I not being patient enough? Does debugging just take a significantly longer time?
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?
Like I said, any input I can get I would love. I am very appreciative of it -- this is the hardest CPU I have had to deal with by far and my first completely memory managed CPU.
Thank you.
Brian Padalino
-----Original Message----- From: u-boot-users-admin@lists.sourceforge.net [mailto:u-boot-users-admin@lists.sourceforge.net]On Behalf Of Wolfgang Denk Sent: Tuesday, November 25, 2003 11:39 AM To: Brian Padalino Cc: U-Boot Mailing List Subject: Re: [U-Boot-Users] Debugging U-Boot on 440GP
Dear Brian,
in message DGEEIPOFGGPOACEFBGGCAECICBAA.bpadalino@perigee.com you wrote:
I have a BDI2000 and a custom target board. I am can successfully connect to it and step through single instructions. I can also set a breakpoint
at
_start_440, but any breakpoints after that do not get noticed. I have the BDI setup for HARD breakpoints. Should I have it setup for SOFT instead?
No.
Did you read http://www.denx.de/twiki/bin/view/DULG/DebuggingUBoot and http://www.denx.de/twiki/bin/view/DULG/DebuggingTricks ?
What I am seeing is that when I stop the CPU, it's either at 0x700 or 0x1400 -- both of which are defined in the kgdb.c file, but I don't know
No. These exception vectors are not defined in the kgdb.c, but in start.S; if you look up the addresses in the System.map file you will find:
????0700 t ProgramCheck ... ????1400 t DataTLBError
Does that ring a bell?
what they mean. Can anyone shed any light on the situation for me? I am very new to both the BDI and using gdb (but I learn quickly).
There is probably more interesting information for you in the DULG - see URL above.
Best regards,
Wolfgang Denk
-- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de In an infinite universe all things are possible, including the possi- bility that the universe does not exist. - Terry Pratchett, _The Dark Side of the Sun_
------------------------------------------------------- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users