Wolfgang,

...

I'm trying to trace into flash_init(). The function is called

after u-boot

...

is relocated to RAM. So the System.map is no longer useful. How

can I know

Of course System.map (or the symbol table in the u-boot ELF file) is still usefiul; you just have to add the relocation offset.

I did read that chapter. I found that gdb even cannot stop at cpu_init_f(). At this time u-boot is still executed from flash. I linked u-boot at 0xffe00000. Isn't it strange, is it?

Thanks, -Shawn.

__________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail

Wolfgang,

My question about BDI2000 should go to Abtron. But their response usually takes one or more days. So I just ask you here. ;)

Yes. You're right. I set breakpoint mode to SOFT. But after I change the breakpoint to HARD, I have the following problem. There is only one hard breakpoint that can be set at a time.

(gdb) target remote rslab129:9124 Remote debugging using rslab129:9124 0xfff07550 in ?? () (gdb) mon ci (gdb) b cpu_init_f Breakpoint 1 at 0xffe093c0: file cpu_init.c, line 93. (gdb) c Continuing. warning: Cannot insert breakpoint 1: Error accessing memory address 0xffe093c0: Unknown error 4294967295. (gdb)

My target setup is as follows. [TARGET] CPUTYPE 8240 ;the CPU type (603EV,750,8240,8260) JTAGCLOCK 0 ;use 16 MHz JTAG clock WORKSPACE 0x00000000 ;workspace in target RAM for fast download BDIMODE AGENT ;the BDI working mode (LOADONLY | AGENT | GATEWAY) BREAKMODE HARD ;SOFT or HARD, HARD uses PPC hardware breakpoint ;VECTOR CATCH ;catch unhandled exceptions DCACHE NOFLUSH ;data cache flushing (FLUSH | NOFLUSH) MMU XLAT ; translate effective to physical address PTBASE 0x000000f0 ; Here is the pointer to the page table pointers

Thanks a lot, -Shawn.

No, it's not. You probably forgot to configure your BDI2000 to use hardware breakpoints; and software breakpoints won't work as GDB cannot write a trap instruction at the breakpoint address. Try:

gdb$ mon break hard

before setting the breakpoint.

__________________________________ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail

...

My question about BDI2000 should go to Abtron. But their response usually takes one or more days. So I just ask you here. ;)

C'me on. Ruedi usually replies the very same day.

Well, I take part of my words back. I kind of exaggerated the situation. Ruedi does usually reply the very same day after he receives the query. However due to the time difference I usually get his reply on the next day. ;)

...

(gdb) target remote rslab129:9124 Remote debugging using rslab129:9124 0xfff07550 in ?? () (gdb) mon ci

That's why here I clear all the breakpoints in the BDI2000.

...

(gdb) b cpu_init_f Breakpoint 1 at 0xffe093c0: file cpu_init.c, line 93.

Try here:

(gdb) d

Hmmm...so it needs to be done in GDB.

Now I'm able to trace functions after relocation. One more point I found out is that the breakpoint mood has to change to SOFT after the relocation to RAM.

Thanks, -Shawn.

__________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail

Futher question on the relocation address.

Ch. 10 of DULG says that the relocation address is usually (RAM_SIZE - MONITOR_LEN). So in my case the relocation address should be 0x7fc0000 (0x8000000 - 0x40000). But from the debugging message I found u-boot is at 0x7fd9000 after relocation. Do they conflict?

Top of RAM usable for U-Boot at: 08000000 Reserving 152k for U-Boot at: 07fd9000 Reserving 192k for malloc() at: 07fa9000 Reserving 56 Bytes for Board Info at: 07fa8fc8 Reserving 48 Bytes for Global Data at: 07fa8f98 Stack Pointer at: 07fa8f78 New Stack Pointer is: 07fa8f78 Now running in RAM - U-Boot at: 07fd9000

Thanks, -Shawn.

__________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail