On Thu, Jan 24, 2019 at 7:54 PM Paul Fertser <[email protected]> wrote: > > On Thu, Jan 24, 2019 at 06:58:20PM +0100, Antonio Borneo wrote: > > Here the error is that the script uses the direct command "jtag newtap > > ..." that is specific of transport "jtag" > > To be general, the script should instead use the command "swj_newdap > > ...", as done few lines above. > > Sorry, but that sounds wrong to me. A "tap" is a JTAG-level entity, it > is something that any JTAG transport should be aware of. In contrast > to that, "swj" here stands for ARM-specific debug port SWJ-DP[1], and > "dap" is an ARM-specific thing too[2].
Fully agree on arm specific naming for the concepts dap, tap and swj-dp. I was just considering the helper swj_newdap as a comfortable wrapper to hide the command diversity across JTAG, SWD and HLA. By the way this misuse is already in place for the boundary scan TAP in: - tcl/target/em357.cfg - tcl/target/psoc6.cfg - tcl/target/stm32h7x.cfg - tcl/target/stm32w108xx.cfg My change proposal http://openocd.zylin.com/4873 was following this trend. Should these scripts and my change be revised? > So it just doesn't sound right. I would guess the proper solution > would be to extend hla_jtag transport to accept "jtag newtap" command > directly. Maybe it's the proper solution, but today no HLA implementation accepts a pure JTAG TAP. I would left the exercise of extending the HLA commands to a future HLA adapter that handles JTAG TAPs in OpenOCD. In mean time, I think the straightforward fix would be to enforce the condition around the boundary scan TAP - if {[using_jtag]} { + if {[using_jtag] && ![using_hla]} { jtag newtap ... Does it sounds reasonable to you? > Regarding stlink, I can't understand why it would ever need to talk > JTAG if it can only talk to the very first target anyway, in this case > SWD would work with exactly the same board with same capabilites, or > am I missing something? I believe is more for historical reasons. The first ST-Link was JTAG only, then updated to support SWD. All the boards embedding ST-Link that I have seen recently use SWD only; there is an obvious gain in pin usage. This could also explain why the STM32 config files have kept this issue hidden for so long. Antonio _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
