GDB --> Ethernet --> RV-ICE

GDB --> Ethernet --> RV-ICE

[Andrew Batchelor]

Hi again,

Okay, things have changed a little since last time.  I now have to use
the Ethernet connection on the RV-ICE (there is no parallel port) to
connect to GDB.

So, I'm now re-evaluating what I need to alter in GDB.

As I understand it, I should be able to use the 'remote target
host:port" command in order to access the RV-ICE (as I can configure it
with any IP address I want).

Now the RV-ICE connects to my target (an Evaluator 7T from ARM) via a
JTAG, but the protocol for speaking to the RV-ICE (RV-MSG) is very
different from the Remote Serial Protocol (RSP) GDB uses.

I understand that GDB uses these stub files that run on the target in
order to implement the RSP on the target, but I think I'm going to need
something different - correct me if I'm wrong.....

Some sort of buffer C file which acts as a streaming protocol converter,
so that, for example, when GDB requests to view a register, this C file
converts that command into an RV-MSG command and then sends that down
the Ethernet connection to the RV-ICE, that then talks to the target.

Sound possible?

At the moment I'm trying to find out where GDB implements the following
procedures to see if they're compatible with this idea - can anyone
help?

I need to find "intercept points" in the GDB C files so I can just jump
off to my other C file (or function header) which handles the RV-ICE
side.  I'm not sure how easy this is going to be.  I'll have to add
another switch to the command line maybe to tell it to use this
converter, but anyway, here are the procedures (they're all very basic
at this stage):

1) Connect/Disconnect to a processor
2) Download a program
3) View/Edit Processor Registers
4) View/Edit Memory Contents
5) Start/Stop Execution (and single step)

If anyone else has any ideas about how to go about this, I'd be grateful
for some feedback on it.

But any help or advice would be much appreciated.

Thanks.


Andy

Re: GDB --> Ethernet --> RV-ICE

[Ramana Radhakrishnan]

Thus spake Andrew Batchelor
Hi,

> Okay, things have changed a little since last time.  I now have to use
> the Ethernet connection on the RV-ICE (there is no parallel port) to
> connect to GDB.
>
> So, I'm now re-evaluating what I need to alter in GDB.
>
> As I understand it, I should be able to use the 'remote target
> host:port" command in order to access the RV-ICE (as I can configure it
> with any IP address I want).
>
> Now the RV-ICE connects to my target (an Evaluator 7T from ARM) via a
> JTAG, but the protocol for speaking to the RV-ICE (RV-MSG) is very
> different from the Remote Serial Protocol (RSP) GDB uses.

You would need to add a new target that would talk to your RVICE in the
format that it understands. Just as you have target remote , you also have
target rdi / target angel etc. in gdb by which you can connect to other
remote boards. So you would need to implement your own target structure.

> I understand that GDB uses these stub files that run on the target in
> order to implement the RSP on the target, but I think I'm going to need
> something different - correct me if I'm wrong.....

The stub files would be used only if  the board does not have any on chip
debug support.In your case I dont see any reason for having any stub files
because the work of the stub in your case would be done by the JTAG
onboard.


> Some sort of buffer C file which acts as a streaming protocol converter,
> so that, for example, when GDB requests to view a register, this C file
> converts that command into an RV-MSG command and then sends that down
> the Ethernet connection to the RV-ICE, that then talks to the target.
>
> Sound possible?

As I see it your implementation is going to be simpler than any of the
jtag implementations.You would essentially have to change the protocol
packets in remote.c to send your protocol packets and I would guess you
would be done.




>
> At the moment I'm trying to find out where GDB implements the following
> procedures to see if they're compatible with this idea - can anyone
> help?
>
> I need to find "intercept points" in the GDB C files so I can just jump
> off to my other C file (or function header) which handles the RV-ICE
> side.  I'm not sure how easy this is going to be.  I'll have to add
> another switch to the command line maybe to tell it to use this
> converter, but anyway, here are the procedures (they're all very basic
> at this stage):
>
> 1) Connect/Disconnect to a processor
> 2) Download a program
> 3) View/Edit Processor Registers
> 4) View/Edit Memory Contents
> 5) Start/Stop Execution (and single step)

You would have to implement each of the functions in the target
structure.There is a provision for this. A reference implementation for
this functionality would be the BDM patch to gdb for the coldfire . That
would have provisions for all the above mentioned stuff.


Hope this helps

cheers
Ramana
----
Ramana Radhakrishnan
Codito Technologies

Re: GDB --> Ethernet --> RV-ICE

[Andrew Batchelor]

Hi Ramana,

Thanks a lot for your reply.

On Mon, 2003-10-27 at 19:57, Ramana Radhakrishnan wrote:
> You would need to add a new target that would talk to your RVICE in the
> format that it understands. Just as you have target remote , you also have
> target rdi / target angel etc. in gdb by which you can connect to other
> remote boards. So you would need to implement your own target structure.
[.....]
> The stub files would be used only if  the board does not have any on chip
> debug support.In your case I dont see any reason for having any stub files
> because the work of the stub in your case would be done by the JTAG
> onboard.
[.....]
> As I see it your implementation is going to be simpler than any of the
> jtag implementations.You would essentially have to change the protocol
> packets in remote.c to send your protocol packets and I would guess you
> would be done.

Yeah, I figured as much.  Seems to be pretty straight-forward then.
(famous last words.....)  :o)

> You would have to implement each of the functions in the target
> structure.There is a provision for this. A reference implementation for
> this functionality would be the BDM patch to gdb for the coldfire . That
> would have provisions for all the above mentioned stuff.

Thanks - I'll go away and have a look at that.


Andy