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

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

Wolfgang,

On Wed, 26 Nov 2003, Wolfgang Denk wrote:

I have often recommended to use just a MINIMAL inti script for the BDI. Don't touch the memory controller. Just configure the absolute necessary minimum (things like disabling a watchdog etc.).

While this may work on many systems, I found it did not work on the DBAu1500 board. I spent more time than I had planned on getting a config file for the BDI to work with this board. I ended up with a config script that did pretty much a complete initialization of the entire board. Without that I couldn't even get u-boot to run from ram.

Ed Okerson

On Wed, 26 Nov 2003, Wolfgang Denk wrote:

...

that did pretty much a complete initialization of the entire board. Without that I couldn't even get u-boot to run from ram.

This just means that your port of U-Boot is still broken.

Yes, it was still broken at that point. But having a config script that initialized the board enabled the "not quite there" u-boot to run and display info on the serial port, where the minimal config script didn't. I found it very helpful to be able to see what was going on. If there was an already working port of u-boot for this board/processor, then I probably wouldn't have needed so complete of a config script. It was painful, but a worthwhile exercise for me. From doing it, I learned what I needed to fix in the u-boot port. Now if I can just figure out this sillyness the Au1500 is doing on the Compact Flash I will be ok. I already fixed another issue with it's little-endian use of the ethernet port.

Ed Okerson

Hi Brian,

• 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?

...

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.

If you can single step to get to display_options but not set a brkpt there and hit it, then one possibility is that the debug regs are still being modified in such a way that either a) HW brkpts are being disabled or b) the HW brkpts are being changed. The best logical way I would approach this is to start at the beginning, and take smaller "leaps" (say 10 or 20 lines of code) with HW brkpts. As you approach display_options, if what you say is correct, at some point the brkpt will not occur correctly. The area of code covered by that last "leap" you should look at. Don't leap over function calls, go into them. Finally, keep in mind that your architecture limits the number of HW brkpts in force at any time. Come to think of it, that could be your problem right there.

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?

Definitely. You can take this part of the discussion over to the linuxppc list. But plan on changing the .config, adding to the arch/ppc/platforms/ dir, potentially writing/modifying driver code (e.g. you may need to enter an MTD map, etc.), among many other possible changes.

Chuck Meade The PTR Group, Inc. www.ThePTRGroup.com