How does the GDB link work?

Hosted forum for UMDK related questions

Moderators: BigEvilCorporation, prophet36

Post Reply
legacy
Interested
Posts: 13
Joined: Wed Jan 21, 2015 10:46 am

How does the GDB link work?

Post by legacy » Wed Jan 28, 2015 12:11 am

hi
great project, i like it :D

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
Very interested
Posts: 234
Joined: Sat Dec 13, 2008 6:58 pm
Location: London, UK
Contact:

Post by prophet36 » Wed Jan 28, 2015 9:05 am

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
Interested
Posts: 13
Joined: Wed Jan 21, 2015 10:46 am

Post by legacy » Wed Jan 28, 2015 11:29 am

understood, it's a different working scheme, in my case i will implement a minimal-gdb-stub
Last edited by legacy on Fri Jul 19, 2019 1:12 pm, edited 1 time in total.

prophet36
Very interested
Posts: 234
Joined: Sat Dec 13, 2008 6:58 pm
Location: London, UK
Contact:

Post by prophet36 » Wed Jan 28, 2015 12:20 pm

legacy wrote: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
Very interested
Posts: 234
Joined: Sat Dec 13, 2008 6:58 pm
Location: London, UK
Contact:

Post by prophet36 » Wed Jan 28, 2015 12:51 pm

Incidentally...
legacy wrote: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
Interested
Posts: 13
Joined: Wed Jan 21, 2015 10:46 am

Post by legacy » Wed Jan 28, 2015 2:24 pm

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
Interested
Posts: 13
Joined: Wed Jan 21, 2015 10:46 am

Post by legacy » Thu Jan 29, 2015 12:22 am

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
Very interested
Posts: 2842
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Thu Jan 29, 2015 5:31 am

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

legacy
Interested
Posts: 13
Joined: Wed Jan 21, 2015 10:46 am

Post by legacy » Thu Jan 29, 2015 2:36 pm

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

MintyTheCat
Very interested
Posts: 484
Joined: Sat Mar 05, 2011 11:11 pm
Location: Berlin, Germany

Post by MintyTheCat » Thu Jan 29, 2015 7:11 pm

prophet36 wrote: 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.
UMDK Fanboy

Chilly Willy
Very interested
Posts: 2842
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Thu Jan 29, 2015 7:19 pm

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
Interested
Posts: 13
Joined: Wed Jan 21, 2015 10:46 am

Post by legacy » Fri Jan 30, 2015 3:24 pm

time ago I started my own "swi_dbg" debugger
Last edited by legacy on Fri Jul 19, 2019 4:27 am, edited 1 time in total.

legacy
Interested
Posts: 13
Joined: Wed Jan 21, 2015 10:46 am

Post by legacy » Fri Feb 06, 2015 11:29 am

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)
Last edited by legacy on Fri Jul 19, 2019 1:21 pm, edited 2 times in total.

MintyTheCat
Very interested
Posts: 484
Joined: Sat Mar 05, 2011 11:11 pm
Location: Berlin, Germany

Post by MintyTheCat » Fri Feb 06, 2015 4:23 pm

Very nice indeed :)
UMDK Fanboy

Post Reply