Hello, On Sun, 20 Oct 2013 17:40:15 +0400 Paul Fertser <[email protected]> wrote:
> On Sun, Oct 20, 2013 at 04:25:45PM +0300, Paul Sokolovsky wrote: > > Thanks for pointer, I indeed skipped looking at it, just as most > > people would do - nothing "remote" is needed here. So, what > > requirements say is: simple, simple, simple for people to use, not > > complicated and obfuscated with various socats. > > For me socat is not an obfuscator but a rather useful tool that adds a > great deal of flexibility to many things I use. I certainly would agree, and even can feel ashamed it's not in my swiss-army-knife toolset. But that doesn't help the world - "socat" is not going to be first thing someone would think in response to "I wanted to tackle that JTAG - NOW is time to go!". And I hope you just as well agree that while socat is useful, it's certainly superfluous as a requirement for doing local JTAG. > It's also a tool that > would allow you to test your idea right now without any modifications > to the OpenOCD codebase whatsoever. Thanks, for prototyping I used https://github.com/pfalcon/PySWD which I find more convenient. Actually, that's what I wanted to hack on, but checking out OpenOCD, it's coverage of course much more wide and if does implement things like ARM semihosting, then it doesn't make sense to reimplement that in Python just because it's fun. so, I hope you appreciate that I'm doing my homework and treating OpenOCD as center of gravity instead of fragmenting the area with yet another JTAG hack-a-tool. > > > Regarding just a protocol as used by remote_bitbang, it seems to be > > pretty close to what was posted, chars definitely can be jiggled > > around, it just needs to be extended to handle SWD still. > > OpenOCD doesn't support bit-banging SWD currently but if it did, I Yup, it will be a bit of pity to implement shifting in my driver instead of reusing something like jtag's bitbang.h. > think the protocol could be used as is, as the SWD pin count is less > than the number of JTAG signals. As you remember, you need to read TMS (aka SWDIO), and then when it's in read state, you don't want to "set" it together with TCK (and supposedly don't want to handle checking that in firmware, preferring host to just issue separate command to set TCK/SWCLK). > It would be unusably slow, of course. You know what kind of joy just reading an IDCODE could bring? Then people could either rejoice, make a note of their success, and stash it until they really need it, or continuing to find more optimal solution if they need it. Compare that with wanting to try JTAG for months or years, and not getting to it, because it's all eerie and complicated, there're many adapters and all you know about them is that they're expensive and work only in very narrow area. > BTW, stm32 discovery boards are rather cheap and powerful, and also Well, as I hinted any "board X can do it easily!" brings response "but I don't have board X", I also implied continuation to that, because I'm sure people who do the stuff for some time has the same situation. But let me be explicit: "... but I have dozen of other boards lying around collecting dust. So, telling 'get another magic board X' won't work. I don't believe some "good vendor" will solve all my JTAG needs - *I* need to solve them, I need to feel thru it, and good way to start is right here and right now." Where it says "I" it actually means "and bunch of other people too". Here's just 2 posts stumbled upon during last week: http://rwmj.wordpress.com/2013/08/08/bring-back-the-bios/ (guy complains that on "PC" you can output debug messages via 16550 (gosh, that's not even true for ...teen years!), and ARM can't do anything like that) http://lists.phcomp.co.uk/pipermail/arm-netbook/2013-October/009101.html (guy complains that using adhoc MCU-specific bootloader is buggy, with obvious question "why generic ARM protocol is not used?") > the stlink embedded on those can be easily reflashed to > BlackMagicProbe. And BlackMagicProbe has a passthrough mode for raw > jtag commands. It would be nice to have a driver in OpenOCD for that. I hope it will be added. Too pity it won't work on MSP430 Launchpad I have on my hands right now, but well, I'm doing my homework to get any board bootstrapped easily ;-) -- Best regards, Paul mailto:[email protected] ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
