How does the GDB link work?

[legacy]

hi
great project, i like it

i have not understood: do you have a gdb-stub running in the m68000 ?
if so, can i see the gdb stub for the m68k ?
it may be useful in my tiny 68k home-made board =)

[prophet36]

This is covered in some detail on the home-page. The implementation relies on some host-side proxy code and a tiny 68000 monitor which implements a request-response control interface, allowing the host to control the 68000 by writing commands and data to a region of the (dual-port) SDRAM, reading responses back from the same region, orchestrated by a single semaphore.

[legacy]

understood, it's a different working scheme, in my case i will implement a minimal-gdb-stub

[prophet36]

i will have to use the uart to get commands

Right, in fact that was the setup that the designers of the GDB remote-serial-protocol envisioned. It was only later that they added the TCP/IP connectivity that my proxy uses.

The advantage of the UART implementation is simplicity (although you do have to write the GDB stub on the 68000 side which is doable but not exactly trivial) and flexibility.

The advantage of the dual-port SDRAM implementation (apart from speed, that you mentioned) is you can interrupt the CPU by writing a breakpoint into SDRAM whilst the CPU is running. But that kind of thing could equally well be done by your UART ISR.

Overall I don't think my approach is significantly better than yours. In fact in many ways your approach makes more sense.

Interestingly, the MegaDrive people who don't want to spend money on a UMDK cart could use your approach (and stub code) with the UART on the MD1 EXT port to get GDB debugging. I'd love to see someone get that working.

[prophet36]

Incidentally...

i will try to use a dual port ram chip in the future

it's not a dual-port RAM chip, it's just a regular $2 SDRAM. But I designed the memory-arbiter in the FPGA to have two request-response pipes, one connected to the 68000 and the other connected to the host via USB and FPGALink.

[legacy]

in my case i have seen a dual port chip, in DIP package, it's something like 8Kbyte with 2 posts, of {8bit data bus, address} each, with an without an hw semaphore.

(8 bit data, address, r/w) port1 -------ram -------- port2 (8 bit data, address, r/w)


it should be useful and easy, and relative cheap. It was a 7 euro chip.

[legacy]

have you seen andy gdb-stub/m68k around ?
i have found something (to be fixed) for mips in the linux kernel
but i haven't found nothing for m68k

in case i will write it for scratches

[Chilly Willy]

The Jaguar Skunkboard software, JServe, has a full m68k gdb stub. In fact, it works nearly identically how prophet36 described.

[legacy]

Jaguar Skunkboard ? never heard before, but it sounds good, does it have any repository of the gdb-stub/68k part ?

[MintyTheCat]

Interestingly, the MegaDrive people who don't want to spend money on a UMDK cart could use your approach (and stub code) with the UART on the MD1 EXT port to get GDB debugging. I'd love to see someone get that working.

I intend to add this to AXLib.

Using one MD Port for debug is essentially how I did it before I used UMDK.

You do not even need a MD1 with the EXT Port as you can use any of the other two Ports if you do not need both ports for joypads that is.

Cheers,

Minty.

[Chilly Willy]

http://www.harmlesslion.com/cgi-bin/sho ... skunkboard

Specifically, this arc: http://www.harmlesslion.com/zips/SkunkBoard.zip

Look in the GDB folder inside that arc (Skunkboard/Source/GDB).

[legacy]

time ago I started my own "swi_dbg" debugger

[legacy]

i have two TAPs now:

• the client TAP, which has a the above text interface and it is able to send and receive uart packet to the target
• the server TAP, which is very similar to the gdb-stub, but in my case it is a finite state machine pretty coded into the fpga, instead of a chunk of code running into the cpu, and "talks" through a protocol uart driven (ad 2Mbps)

[MintyTheCat]

Very nice indeed