There is already a (preview quality) SWD applet! There's no actual gdbserver (or flasher) support right now mostly because I was going to integrate with @azonenberg's jtaghal, and jtaghal isn't evolving quite quickly enough. There will likely be native gdbserver support, the same as for MIPS EJTAG applet.

You might be able to plug it into https://github.com/orbcode/orbuculum

That's mostly pointless, it's just more C code I cannot actually distribute with Glasgow itself... Really, the protocol is not very complex.

Update: I will not even try to rely on jtaghal, Glasgow-native gdbserver is superior in every way.

I have done some work on SWD. Please let me know how I can help realize the SWD support.

There's a prototype of an SWD applet. What's missing is the actual debugger code. Currently the bottleneck is maintainer time / review bandwidth so there is little you can do to make things faster.

I have been picking at SWIM+stm8, programming only so far.

We should probably have a different issue for SWIM, as far as I remember it's a completely different protocol.

Certainly! I have a couple more branches from master for other protocols, but they are pretty gross atm. I'll create merge rqs when that have at least some utility.

Is it worth trying to write a driver for support with openocd? That's something I've done in the past and would be willing to work on.

Does openocd have something like the JTAG bitbang interface but for SWD? Anything that works through a socket rather than through libusb would work.

I believe so - I can start experimenting with this and report back if I find something.

We can quite easily add a swd-openocd applet like the existing jtag-openocd one, yep.

i never realized there was a jtag-openocd bridge, what are the limitations of it? how fast can the clock go? one of the things i wanted from the glasgow was to use it as a debugger programmer

As fast as the native JTAG applet allows, which is currently 6 MHz due to a temporary limitation while we're migrating from Migen to nMigen.

in that case that swd-openocd applet could prove real usefull to me, how far away in the horizon do you see that coming? not asking for a timeline, just a ballpark.

No idea if OpenOCD can even do the equivalent of that. @wrongbaud may be investigating that; you could take a look too if you want things earlier.

I have every intention of helping, especially on matters that are especially useful to me; I will look into it, though i am not very familiar with the inner workings of openocd. Also my glasgow is just a parts bin waiting to be assembled so i can't test anything.

So, i looked around the OpenOCD code.
Apparently, as it is right now, the remote_bitbang driver that is used with the jtag-openocd applet only supports JTAG, though i found two unmerged patches that added SWD support, i have no idea why they were left open, but they were trivial changes and if they actually worked it shouldn't be to hard to convince them to push them upstream, i have already opened a ticket asking about it.
That being said, if the remote_bitbang supported SWD, not much would be needed in the glasgow applet side in order for it to work, am i correct?

That being said, if the remote_bitbang supported SWD, not much would be needed in the glasgow applet side in order for it to work, am i correct?

Correct.

So, after opening the ticket there was some progress, one of the patches was rebased, but it needs to be tested, i cant do it myself, because my glasgow isn't ready, and i don't know how i could do it any other way.

If someone could look into this it would be great, i believe it should work.

Here's the ticket:
https://sourceforge.net/p/openocd/tickets/269/

If someone could look into this it would be great, i believe it should work.

I have a working Glasgow revC1 and would like to help, but I haven't used OpenOCD for some time. So what exactly should I do to test?

Take a recent OpenOCD and apply http://openocd.zylin.com/#/c/4205/
But what would be the next steps to get it running?

I have for example a STM32F072 and would hook up it's SWCLK and SWDIO to the Glasgow.

I think you just need to add the new commands to JTAGOpenOCDSubtarget and then you should be able to get glasgow to open a server, as shown in

Should look something like this:

openocd -c 'interface remote_bitbang; remote_bitbang_port 2222' -f /usr/share/openocd/scripts/target/stm32f0x.cfg

I don't think that would work, JTAGOpenOCDApplet can't electrically do SWD if I remember correctly.

Hum, okay. Then we can just copy it to a new applet and apply the required modifications.

I believe connecting to a target using SWD and that driver should be enough to approve the changes.

I don't think we actually need to change anything in the applet.

Well, you should need to test if the new commands actually work, no?

hm, i don't think i understood quite right how the applet worked, i guess you're right

We now have swd-openocd. I'm going to close this issue since it does enable SWD debugging and it'll likely be quite a while before I have bandwidth to either implement or review support for ADIv5 (including internal architecture changes needed to make it maintainable).