1/1 
|
Hardware Debug support working
by Unknown on Feb 5, 2004 |
Not available! | ||
|
I have the hardware break- and watchpoints working now. The changes for
or1ksim and gdb are checked in. There were some changes in the eCos gdb stub as well. I will check those in as soon as we have our current eCos updated in CVS. Heiko |
|||
|
Hardware Debug support working
by Unknown on Feb 5, 2004 |
Not available! | ||
|
Heiko Panther wrote:
I have the hardware break- and watchpoints working now. The changes
for or1ksim and gdb are checked in. There were some changes in the eCos gdb stub as well. I will check those in as soon as we have our current eCos updated in CVS. Do you explicitly turn on HW matchpoint support in gdb or is it implicit from the *CFG registers ? In other words, will these stub changes adversely effect those without the debug registers implemented ? -Scott |
|||
|
Hardware Debug support working
by Unknown on Feb 6, 2004 |
Not available! | ||
|
I have the hardware break- and watchpoints working now. The changes
for or1ksim and gdb are checked in. There were some changes in the eCos gdb stub as well. I will check those in as soon as we have our current eCos updated in CVS. Do you explicitly turn on HW matchpoint support in gdb or is it implicit from the *CFG registers ? In other words, will these stub changes adversely effect those without the debug registers implemented ? No. I modified eCos so you can indepently modify the number of soft breakpoints, hard breakpoints and watchpoints. The current eCos can't do hardware breakpoints if your soft breakpoint list is of size 0 - that's something I want to submit to the mainline sometime. GDB stub has no way that I know of finding out how many hard breakpoints are available. You have to hard-code that into gdb. So what I did was entering the max number of matchpoints. GDB will still set soft breakpoints if you do "b main". If you do "hb main", a hard breakpoint will be set. Heiko |
|||
|
Hardware Debug support working
by Unknown on Feb 6, 2004 |
Not available! | ||
|
GDB stub has no way that I know of finding out how many hard breakpoints
are available. You have to hard-code that into gdb. So what I did was entering the max number of matchpoints. What do you mean by "hard breakpoints"? If you mean how many DVR/DCRs pairs are there, you can find out by checking DCRx[DP]. There is also the same information available in DCFGR (Debug Configuration Register) in field NDP. regards, Damjan |
|||
|
Hardware Debug support working
by Unknown on Feb 6, 2004 |
Not available! | ||
|
>> GDB stub has no way that I know of finding out how many hard breakpoints
>> are available. You have to hard-code that into gdb. So what I did was >> entering the max number of matchpoints. >What do you mean by "hard breakpoints"? If you mean how many DVR/DCRs >pairs >are there, you can find out by checking DCRx[DP]. >There is also the same information available in DCFGR (Debug >Configuration >Register) in field NDP. Well, there seems to be no way to read the SPRs through gdb stub. Only the GPRs. Heiko |
|||
|
Hardware Debug support working
by Unknown on Feb 6, 2004 |
Not available! | ||
|
What is exactly is gdb stub? I thought it is a piece of code running as part
of the OS on openrisc. In this case you can read SPRs. Also through JTAG you can read SPRs. regards, Damjan
Well, there seems to be no way to read the SPRs through gdb stub. Only
the GPRs.
Heiko
_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc
|
|||
|
Hardware Debug support working
by Unknown on Feb 9, 2004 |
Not available! | ||
|
What is exactly is gdb stub? I thought it is a piece of code running as part
of the OS on openrisc. In this case you can read SPRs. Correct. I can read the SPRs, gdb just won't read them. GDB stub communicates with gdb through the "gdb remote" protocol. This protocol is only designed for transferring GPRs. The gdb remote host does neither know nor care about SPR's. There is no command to transfer SPRs in the gdb remote protocol. You can do that stuff with JTAG because the or1k JTAG target has its own, target-specific commands for that (info spr, spr). I'm not sure whether it would be possible to implement something like that for the remote target. Heiko |
|||
1/1