On Sun, Jan 27, 2013 at 10:04 AM, CeDeROM <[email protected]> wrote:
> On Sun, Jan 27, 2013 at 3:54 AM, Andreas Fritiofson
> <[email protected]> wrote:
> > I didn't really want to get into this discussion as I have lots to say on
> > the matter, but not very much time to put it into words. There are so
> many
> > mails with bits I'd like to reply to so it's hard to get a consistent
> point
> > through. I'll just reply to a random mail, because I feel I have to say
> > something.
>
> Hello Andreas :-) Your voice is very important as you are the author
> of new MPSSE driver, so you can also propose a better API for the
> interface :-)
>
Actually I threw out some ideas a while back and got some feedback although
I've lacked the time and energy to respond.
>
> > I'm not fond of the idea of cramming an external library into the
> internal
> > interfaces of OpenOCD. I simply don't see what business LibSWD has in the
> > path from target to adapter. Sure a library such as LibSWD may be useful
> as
> > a helper library *inside* an adapter driver, to convert high level
> > operations to bitstreams. That is, for the few adapter types that are
> able
> > to use it (ftdi adapters and parport/bitbang, any else?). Your current
> > patches add LibSWD as a middle layer in OpenOCD, something I've ranted on
> > before that we should *get rid of* in OpenOCD, not add more.
>
> Then get rid of JimTCL as well, libusb, libftdi, etc ;-)
>
Well neither of those are middle-layers. And only Jim is entangled into the
inner workings of OpenOCD, the rest are used in peripheral code, i.e.
inside the adapter drivers, which is completely fine.
>
> >> Current jtag_interface was only using flush() to flush jtag commands
> >> into the hardware. This made all interfaces jtag-only. Adding
> >> bitbang/transfer methods makes it possible to implement virtually any
> >> protocol on the interface.
> >
> >
> > That's a bit narrow-minded. I can think of a bunch of imaginary
> "protocols"
> > that cannot be reasonably implemented over that API (any asynchronous
> > protocol for example, say the ubiquitous UART). And even if SWD happens
> to
> > be a match, doesn't make it a suitable API for a SWD adapter (as I've
> said
> > before). In other words, just because it's *possible* to implement
> something
> > over a certain API doesn't mean that it's a *good* API for that
> something.
> > The number of debug protocols in use today are very few, and even fewer
> of
> > them are likely to be usable by a open source tool. In that light, it
> makes
> > no sense to make the adapter API protocol-agnostic. The pathetic
> performance
> > numbers I've seen mentioned *may* be indicative of the unsuitability of
> the
> > "lowest-common-denominator" transfer/bitbang API (why design in a
> > bottleneck?).
>
> And here I got disappointed by your way of thinking. I want to create
> something generic and versatile. You say I am narrow minded and give
> bad example of what cannot be implemented with transfer (i.e. UART
> that can be perfectly implemented that way). You only give "thats bad"
> with no real alternative, I was expecting something a bit more
> constructive from you...
>
>
But we don't *need* generic and versatile. We need an API that is strict
and to the point and a perfect match for the protocol it's modelling.
Resorting to a lowest-common-denominator between SWD and some other
imaginary protocol that no-one can yet foresee the use of in a debug
environment, completely hides the high level operations emitted from the
target, from the code which is talking to hardware to execute them: the
adapter driver. This is what I mean by a middle-layer. LibSWD acts as a
funnel or filter that converts useful information to a form that is
gibberish to all but a certain class of adapters. I want the target code to
talk essentially directly to the adapter driver.
The current JTAG queue (of which the struct jtag_interface is the API) is
also a middle layer that, while retaining protocol information, discards
temporal information by queuing up commands and shipping them to the driver
in big chunks (for performance reasons). This is bad, because nothing but
the driver can know if it's actually any faster to execute many commands in
a chunk compared to executing them right away, or what level the queuing
should be done at. It also complicates debugging. Adapter drivers that do
benefit from queuing can share a queuing helper library. Similarly,
low-level "bit-banging" SWD adapter drivers may share a
SWD-ops-to-bitstream-conversion-library (well, what do you know... that's
exactly what you've written!).
Adding the transfer/bitbang as an interface API doesn't help with SWD for
adapter that doesn't provide access to raw GPIO. So we still need a
separate API for those. Two separate API's instead of one? No thanks.
Perhaps that's why you needed to add the "features" stuff (which may be a
good idea for other reasons).
>
> >> I have looked at the new MPSSE driver and it has already everything
> >> required to work with LibSWD Transport - transport and bitbang. Still
> >> I dont know how this relates to the jtag_interface. Did you change
> >> Interface desing? Is there any consistent Interface API in OpenOCD? Is
> >> it jtag_interface?
> >
> > Yes, jtag_interface is the high level interface (adapter) API. But it
> sucks,
> > and I'm trying hard to replace it with a better one. Unfortunately, your
> SWD
> > work makes it even worse, despite your saying that your changes are
> > non-invasive. They simply aren't. They may not change the operation of
> > OpenOCD, but they certainly change (or set precedent for further
> development
> > of) the architecture. And I'm not sure I like (or know) the direction
> it's
> > heading.
>
> What is the change? What is the new design?
The stuff you added to struct jtag_interface and which I NAKed, for
example. I haven't gone through all patches so I can't say more yet.
> Where is the specification
> for a new Interface for OpenOCD?
There is none. That's why I don't like the order you do things. Negotiate
an API first, then code.
> You have cloned some MPSSE commands
> and made interface for them in OpenOCD, this increases performance and
> will increase performance for LibSWD as well, but how does that relate
> to new Interface or Adapter API??
>
It doesn't. I don't know where you got that impression. mpsse.c has nothing
at all to do with the adapter API. It doesn't use it, it doesn't implement
it, they're not even at the same level.
Btw. your approach with flush() given for a specific protocol is the
> biggest pain of the current OpenOCD design. Interfaces can only
> flush() jtag. I don't think this is a good solution, its a blocker.
>
*My* approach?? I'm trying to get rid of that junk, goddammit! :P
I'm totally with you that it's bad, even if we currently have different
views on what would be better.
>
> > All in all, I think it's crazy to develop yet another SWD solution in the
> > current architecture (which I've also said before). If the goal is to get
> > SWD support at any cost you could have used (or built on) any of the
> other
> > three (3!) existing implementations: my own (from 2008!) for ft2232,
> Simon
> > Qian's for versaloon and finally the ST-Link.
>
> Show me "your" implementation from 2008, tell me why its not working
> yet, why its not in the OpenOCD, why I could not use it back then?
> Simon's solution needs dedicated interface, ST-Link solution requires
> dedicated interface. My solution is working, its free, open, and works
> with any interface.
>
Just google "SWD experiment" and my name. Or search the archives from
november 2008. I *think* it's working, using a JTAGkey with an external
tristate buffer. But I'm guessing not very robustly. This was two or three
days of hacking so naturally it's not complete. There may be protocol
violations and lousy error handling and whatnot. Back in the days OpenOCD
was even worse organized so if I remember right, reset was hard to get
right. But I did flash and verify an STM32F103 and the performance what as
good or better than with JTAG.
The reason it's not in OpenOCD is that I had no interest to maintain the
patch as it was pure proof-of-concept I did for fun and to learn SWD. The
only reason I posted it to the list was because I was requested to do so by
someone on the ST forum. It was clear that OpenOCD was not prepared to add
SWD cleanly. Myself I haven't really *needed* SWD yet since all chips I've
used has had JTAG also, so there hasn't been much reason for me to
prioritize such work.
Why you couldn't use it then? Yeah, why not? It's for you to answer.
> ..and it looks like my time is wasted again Andreas - you did not give
> even one example on how things could be done better, show how they can
> work better, give an example of new organization, just complain... :-(
>
I have, but even so I have no obligation to provide you with opinions even
if I'd like to have been able to. When I started to look at your work it
was more or less designed already. I only remember you showing complete
code, not asking for feedback on the design. But I may have missed some
mails.
Also as I said, some measure of redesign or reorganization after feedback
would be expected and that doesn't mean that everything is wasted.
/Andreas
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
_______________________________________________
OpenOCD-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openocd-devel
