Here are a few technical comments on Simon's patch. I'll start by using the diffstat output as a prop, and may include details later ... possibly in separate threads.
> src/jtag/commands.h | 21 ++- > src/jtag/core.c | 29 ++++ > src/jtag/driver.c | 79 +++++++++++ We might want to have src/interface, with JTAG and SWD as separate layered components. Files like "swd.h" and "swd.c" would likely be worth having, instead of letting that stuff get scattered. Regardless, I think I like the notion of having a struct wrap the SWD operations (command, ack, data} in host byte order. Should they maybe be members of a linked list, to better model queued or pre-computed operations? Needing to convert these to JTAG ops bothers me a bit, though it's probably expedient. > src/jtag/interface.c | 2 > src/jtag/interface.h | 1 > src/jtag/jtag.h | 7 + > src/jtag/minidriver.h | 6 > src/jtag/tcl.c | 46 ++++++ You added an "swj_mode" command, but it doesn't look at the link hardware to see if it's supported. What I'd like to see is a more generic command putting the interface into a given mode ... with initial options including SWD and JTAG. I think we'd want to be able to stress test by switching modes back and forth... That seems like it should be an easily separated chunk, but there'd necessarily be an invasive bit to make sure JTAG operations are cleanly rejected in SWD mode, and vice versa. Related: interface commands to activate SWO. On the Luminary boards, for example, FT2232 port B can be used either as the serial link *or* to collect SWO data. SWO data collection obviously depends on being in SWD mode... > src/jtag/vsllink.c | 276 +++++++++++++++++++++++++++++++++++++--- I think I'd like to be able to start with the interface level and work up ... that'd help makeng sure the approach works well with more than just Versaloon. There's the Raisonance stuff Andrew was using (STM32 Primer2?), and the Luminary boards too. > src/target/arm_adi_v5.c | 221 ++++++++++++++++++++++++-------- > src/target/arm_adi_v5.h | 9 + Yes, SWD has to work fairly closely with the ADIv5 support. That's a fairly significant constraint! Cores that don't use ADIv5 won't care. But I'm suspecting that this part would best be factored as some cleanup patches preceding merge of SWD hooks. Maybe along the lines of factoring out a low level ops vector that can eventually be swapped between JTAG and SWD versions. Obviously, since switching to SWD mode requires reading the ID register, that's one of the first things that would need to become pluggable. :) ... that's it for comments just now. - Dave > 11 files changed, 621 insertions(+), 76 deletions(-) _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
