Re: [Openocd-development] Dynamic library loading

2009-06-26 Thread Pavel Chromy
Hello David,

David Brownell napsal(a):
> And that's why GPL restricts distribution of GPL 
> software with non-Free libraries.  If it didn't,
> then the users relying on the non-Free code would
> not have the full set of Freedoms intended by GPL.

however, here we speak about distributing binary WITHOUT non-free 
library. A binary which does not depend on a non-free library. If there 
is a free option compiled in, such binary may be used without non-free 
driver and thus user has CHOICE to use free or non-free driver.

There is nothing wrong in distributing binary compiled for a non-free 
CPU (a core not released under GPL) so with all the respect to GPL, I do 
not understand why is it wrong to distribute binary having (beside 
others) just SUPPORT for a non-free hw?

Another matter is a binary dependent on a non-free library, but this is 
not the case.

Best regards,
   Pavel
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


Re: [Openocd-development] Dynamic library loading

2009-06-26 Thread Pavel Chromy
Harald Kipp napsal(a):
>>> AFAIK, adding support for a non-compliant DLL in GPL code is not
>>> circumventing any GPL clause that I know of, neither directly not
>>> indirectly.
>> so is your belief that it is GPL compliant to also distribute
>> GPLed binary that includes support for a closed DLL which is actually
>> not required to use the binary, as there is a free alternative compiled
>> in? (e.g. bitbang parallel port driver or libtfdi support)
> 
> Exactly.
 >
> At my current state of knowledge I'd have no problem to distribute such
> a binary, _without_ FTD2XX libraries, of course.

Thank you, Harald,
this is what I was pointing at in my previous posts:
find the real meaning, the original idea of GPL and defend that,
not some disputable literal interpretation.

Best regards,
   Pavel
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


Re: [Openocd-development] [windows + openocd] GPL implementation of libd2xx.dll ?

2009-06-26 Thread Pavel Chromy

Hello Zach,

Zach Welch napsal(a):
> On Fri, 2009-06-26 at 00:21 +0159, Maciej Grela wrote:
>> A friend of mine pointed me to the threads concerning
>> GPL/windows/building/libftdi/libusb/libd2xx. After reading all this an
>> idea came to my head - what if we implement our own GPL/LGPL version
>> of libd2xx.dll ?
> [snip]
> 
> My concern would be that you would be using a proprietary ABI.
> The same idea was suggested, but using the libftdi ABI instead. 
> So, I am against the first (it's gray!) but can accept the second.

What is wrong about adopting existing ABI, especially when it is 
designed to talk to a proprietary hw anyway? Whether we use former or 
latter, OpenOCD would still talk to a proprietary solution and that 
piece of code cannot be used for anything else.
No offense but isn't this sort of GPL madness?

It seems to me there is no significant difference which interface we 
use, but using fd2xx bring one benefit - no necessity to maintain 
"ftd2xx shim" in addition to its free libftdi reimplementation.

Best regards,
   Pavel

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


Re: [Openocd-development] ftd2xx -> libftdi

2009-06-26 Thread Pavel Chromy
Hello Zach and the list,

Zach Welch napsal(a):
> If we are pursuing all of these at one time, our collective resources
> are not being used efficiently.  It's nice to see all the activity, but
> I think we could make more productive use of our collective time.  Now,
> I am *not* asking anyone to change what they are doing, but "what if"
> _everyone_ just buckles down and focuses on fixing libusb and libftdi? 
> 
> As I said at the start of all of this, this option seems like the best
> use of the community's resources:

This path is IMHO very far from best solution, remember that FTDI chips 
evolve, there are several variants on the market today.
Is it really a good idea to maintain compatibility with future chips?
Is this not exactly the task for a device driver?
Be the answer yes or no (I assume yes) this is definitely not a task for 
OpenOCD itself.

FTDI delivers a solution which is so popular _mainly_ for the fact that 
it is easy to use without necessity to implement low level USB stuff. 
Maintaining a driver for hw solution which is still _closed_ and noone 
knows for how long it will be produced is _totally_pointless_ - 
especially when speaking about long term solution.
Moreover FTDI is not the only USB chip in the world.
And finally libusb is a hack which moves driver to userspace,
and it may be necessary to digitally sign it (Windows).
Who is going to pay for a signing certificate?

If we want OpenOCD to support various JTAG interfaces, even commercial 
ones (I see no problem in that, it is the same as buying computer 
hardware) the _only_ option is to create a _single_standard_ interface 
between OpenOCD and JTAG hw driver.
I see support for commercially sold JTAG interfaces as very good thing, 
it brings to the community those people who prefer having professional 
JTAG interface over soldering together some free circuitry.

So if this has to happen I vote for vendor neutral solution:
a) adding "controlled interface"
http://www.gnu.org/licenses/gpl-faq.html#LinkingOverControlledInterface
which is probably legally complitated
b) use suitable communication method like sockets, may be easily built 
on top of bitq.c

> (a) It will be the best contribution to the free software community.

And even better contribution to FTDI - why shall we prefer any single 
manufacturer?

> Developers: are there others that want to follow this same path?

For myself - no.

1> Distributors: do you want to deliver this solution to your users, if not
> today then someday?  

Again, not all JTAG interafaces which may be potentially used woth 
OpenOCD have to be built using FTDI.

Best regards,
   Pavel
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


Re: [Openocd-development] Dynamic library loading

2009-06-26 Thread Pavel Chromy
Hello Harald and the list,

Harald Kipp napsal(a):
> It's perfectly legitimate to _distribute_ a *GPL compliant* DLL with
> GPL'ed executables.
> 
> It's perfectly legitimate to _run_ a *non GPL compliant* DLL with GPL'ed
> executables. The intention of GPL is to explicitly give users the
> freedom to use GPL software in any way they see fit.
> 
>> Transparent attempts at circumventing GPL lie down this
>> same path, so keep your eyes peeled :-)
> 
> AFAIK, adding support for a non-compliant DLL in GPL code is not
> circumventing any GPL clause that I know of, neither directly not
> indirectly.

so is your belief that it is GPL compliant to also distribute
GPLed binary that includes support for a closed DLL which is actually 
not required to use the binary, as there is a free alternative compiled 
in? (e.g. bitbang parallel port driver or libtfdi support)

Thank you for your opinion.

Best regards,
   Pavel
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


Re: [Openocd-development] [windows + openocd] GPL implementation of libd2xx.dll ?

2009-06-26 Thread Pavel Chromy
Hello Maciej,

Maciej Grela napsal(a):
> A friend of mine pointed me to the threads concerning
> GPL/windows/building/libftdi/libusb/libd2xx. After reading all this an
> idea came to my head - what if we implement our own GPL/LGPL version
> of libd2xx.dll ?

This is also an option, but there are problems mainly in maintainance of 
compatibility - these days there is more than just a single version of 
the chip while FTDI keeps compatible API - I am not sure whether the 
compatibility is maintained in the driver or the DLL but I experienced
a situation after driver update that different versions of driver and 
DLL are not necessarily compatible.


> From my investigation it seems, that the driver does all the hard
> work, the DLL itself just calls some ioctls.

However, this is completely undocumented.


> Also, the driver is the
> only thing, that needs to be signed if I understand correctly.

Yes, you are right.


> Obviously, GPL code can communicate with drivers using system calls so
> I don't suspect any traps.

Correct, despite (as stated in my previous post) I really do not like 
the qualification of communication to "GPL allowed" and "GPL 
prohibited", GPL speaks so.


> Also, Freddie, can I ask for more details about your performance
> comparisons ? You've said, that libd2xx performs better than libftdi
> but is this only under windows ? What is the speed difference between
> libftdi + libusb under linux, libftdi + libusb under windows and
> libd2xx + native windows driver ? I'm trying to figure out if the
> windows driver does some magic to speed up the transfers or does
> libusb suckiness on win32 cause it's inferior performance.

The problem with libftdi used to be that it was not able to do async I/O
operations, which meant that data was not read from the chip during 
writing larger block to it - this might cause buffer overflow. Because 
of that there had to be quick write/read turnarounds with small block 
sizes - what fits into the on-chip buffer. However when I looked into 
recent libftdi sources I assume this is no longer true, so the 
performance difference shall not be that significant these days - in theory.


Best regards,
   Pavel
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


[Openocd-development] FT2232 & Windows - license consideration

2009-06-26 Thread Pavel Chromy
Hello Øyvind and the list,

Øyvind Harboe napsal(a):
> welcome back it's been a while! I hope that you'll stick around
> to submit some more good patches. You've contributed lots of nice
> stuff in the past!

I am still here, monitoring the forum and I surely also do have future
plans to contribute to OpenOCD in the future.


> GPL stops closed source target & interface for OpenOCD.

Sure, I understand that and I have to say I am not arguing about this.
I like open source, it is just I really do not like if suddenly appears
someone literally interpreting a legal document making a problem from 
something which has not been problem for years
- I believed that ftd2xx.dll is linked "per design" by the will of the
original author, giving me an impression that in such case it is not a
license infringement.

Anyway, as I noted in my post, it is better to (technically) solve this
for good rather than argue forever, I suppose you see it the same way.
But we shall not become GPL slaves, solving how to pass literal
interpretation of the license instead of pushing OpenOCD further.


> That's one of the *main* reasons I got involved with OpenOCD in the first 
> place.

Actually me to, I am not for closed interfaces, and PRESTO is also open.

The only closed thing is ftd2xx, a hw driver wrapper with rather trivial
API which is mostly the same as OS file I/O API so the discussion about
this seems to me a bit ridiculous.
Open interface to FTDI chips does not make much sense without the chip
itself, noone is going to implement a compatible silicon, that is why I
consider ftd2xx as part of the hw and why I see the discussion
pointless, bringing no real benefit to the project itself


> I also knew that since the project was GPL to start with, it wouldn't
> switch to another license once a sufficient # of contributors had signed
> up. At least not without *everybody* agreeing to a license change. This
> ensures that any license change won't be full of holes.

Agreed. Too late, too complicated these days.


> I *know* there are hardware vendors out there that
> are aching to use OpenOCD together with closed source target support,
> and they *would* find any tiny loophole and throw money at lawyers to
> exploit it.

Actually, this is not what I want. But I also do not like the silly
madness about ftd2xx.
BTW I like Linux, but what I really hate on it is lack of binary driver
interface making many problems with hw compatibility - this is simply
not the right way to do it, single word: interoperability.
GPL does not mean the project shall not be able to communicate with
non-free world and the attempt GPL made to classify "allowed" and
"forbidden" ways of communication is far from ideal solution, neither
does it guarantee freedom: binary communication over socket may be
non-transparent in such a fashion that the code actually is not free
(liberty) despite it is open.

So this is what I was pointing at in my post: it is necessary to see the
the principles of the license, its real meaning, so that we choose the
right way, not just a technical workaround which passes the rules.


> Now, I *know* you can fix these USB problems with both hands tied
> behind your back in your sleep with a modest effort. The acceptable
> solutions have been outlined. For sure it's a million times easier for
> you to solve this technically than legally.

You are right.


> You stand out amongst the hardware vendors because you have made
> *very* significant contributions in the past.

Thank you very much. Personally I do no think it was such a big
contribution. Without having the OpenOCD sources I would not have
courage to start working on ARM JTAG debug solution, neither I have had
time to program it from scratch. That is what I like on open source.

Hopefully there will be more contribution from me (or us as company).


> How about using the bitq stuff forl a generic JTAG over TCP/IP solution? ;-)

Surely possible, but not much convenient, another process running on
users computer, however, speed shall not be a big deal, probably a way
to go. What I really would like is to separate all the JTAG logic from
all low level drivers (if all drivers make use of bitbang or bitq).
I am not sure about current status, I have not looked into recent source
for an extensive period.

On contrary, creating socket bitq interface would make it easier for
vendors selling proprietary JTAG interfaces without giving any 
contribution, they would just implement the other side of the pipe.
As you see every coin has two sides - implementing socket bitq would
comply with literally interpreted GPL but at the same time, it would
undermine its principles.


Binary compatible libftdi->ftd2xx is also fine but opposite solution
might be even more interesting: reimplement ftd2xx.dll using libftdi,
giving a free solution also for other projects which use ftd2xx. In
other words to take ftd2xx ABI as a standard and reimplement it to get
fully free solution to fully comply with the licens

Re: [Openocd-development] FT2232 & Windows - summary of options

2009-06-25 Thread Pavel Chromy

Hello list!

Wookey napsal(a):
> +++ Freddie Chopin [2009-06-24 16:56 +0200]:
>> Important Qestion - Is OpenOCD meant for users to use, or just to be 
>> "100%-GPL-at-any-cost"?

Good question!
GPL is to bring free software to users, to support evolution of
software, this is what was meant when the license was created.
There may be many examples found when literal interpretation of legal
documents does not end up with the aim of its author, some examples may
be found in law. That is why there are courts and juries -
otherwise a case could be decided by some robot or artificial intelligence.

What I state here is not lack of respect to the license but what I ask
for is to interpret GPL as it was meant, not in some kind of tendentious
way. We have to understand the real sense and meaning of the license,
its PURPOSE, not just read it as sequence of words - legal document is
NOT a computer program so just don't read it like a compiler.

> We need to just fix the problem for users (by getting a
> licence-compatible USB driver for windows people who currently don't
> have one).

Here we go... ftd2xx is part of the driver, thus we may think about it
as part of the hardware. OpenOCD, compared to other projects, is a bit
specific in that it requires hw connectivity solution and there has to
be a way to communicate with hw.
If OpenOCD communicates with some driver backend over TCP, it would be
100% OK with literal interpretation of GPL. The question is: Would it
make the code better in any sense? Would it make the code more free?
(Remember GPL is about liberty.) I say no, this would not make any
difference.
This problem touches virtually any software using closed hw connectivity 
solution.

An example: if I program an extension or connector (wrapper) for some
closed library, which enables it to be conveniently used and I would
like release the source to the public am I forbidden to use GPL license
for my work just because it (by definition - as it is aim of the
project) links to a closed library? Yes or no?
Application for tweaking graphics card chip of certain manufacturer 
might be another example.
No doubt that using LGPL would be a better choice, but again, am I
forbidden to use GPL?

In the light if the examples above:
the project was started by Dominic Rath, and he included support
ftd2xx. This is very important, because this was his choice - the choice
of the only one author that day. Isn't it similar? OpenOCD links with
ftd2xx "by definition" from the days the project was started.
So ftd2xx was originally meant to be linked to OpenOCD, it was not added 
later. Dominic, please correct me, if I am wrong.

Nevertheless it would be fine if this issue is finally fixed so that no
more nitpickers could bother the community by reopening it.

Please do not take the above as call for ignoring licensing issues, it
is not meant like that, the point is: overinterpretting legal documents
may lead to really absurd situations, this is what we have to bear in mind.

Best regards,
   Pavel

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


Re: [Openocd-development] first ftd2xx fix: documentation!

2009-06-25 Thread Pavel Chromy
Hello Zach and the list,

Zach Welch napsal(a):
> It remains somewhat unclear to me exactly how badly distributors need to
> see a solution today, when users (who are all developers, right?) should
> be able to compile the code themselves and use the FTD2XX driver.  

I would like draw attention to this many times repeated misconception 
that all OpenOCD users are developers, which is definitely not true.

Company I work for sells development tools including MCU/FLASH 
programmers. The praxis shows that significant part of the users ouf 
such products are amateurs, who just build a circuitry published on the 
Internet or in a magazine and all the are willing to do is to feed 
binary image of firmware into the device. They just download it
and use a tool to flash it.
And with no offense, some of these people are "dummies" when speaking 
about programming/development - there are many of them.

OpenOCD is a solution which (with proper script) may be used for
programming firmware into a device by a non-developer.
I may also be used for production purposes this way.

 From this point of view the assupmtion that OpenOCD user == developer
is simply wrong, this would exclude certain hobbists.

Best regards,

Pavel
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


Re: [Openocd-development] LPC2148 JTAG Issues

2009-01-06 Thread Pavel Chromy
Hello Peter and list,

I might be looking into completely wrong direction in this case, but it is 
worth noting
that when I was experimenting with LPC2148 with OpenOCD,
If found out, that LPC needs reset pulled while RTCK is low.
At least from what I've seen, it seemed to me that power-on
reset is not sufficient for this. It might be that RTCK is latched upon reset,
not sure about what is going on inside.

Please have a look into the lpc2148.cfg, there is still note about this,
but the following lines I have added
jtag_reset 1 1
jtag_reset 0 0
are gone, I assume that it did not work for someone that way or influenced
reset configuration etc. This was before JIM TCL integration, so I am not sure 
whether
these to lines would still do the desired job.
Please see following links:
http://www.mail-archive.com/openocd-development@lists.berlios.de/msg00604.html
http://www.embeddedrelated.com/groups/lpc2000/show/36295.php

You may also try pulling reset by a jumper by hand before running OpenOCD,
just experiment with this and let the list know about the results, please.

Best regards,
Pavel

Peter LaDow napsal(a):
> openocd-ftd2xx -d 3 -f interface/arm-usb-ocd.cfg -f target/lpc2148.cfg
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


Re: [Openocd-development] LPC2k calc_checksum and mismatch during verify_image

2008-08-26 Thread Pavel Chromy
Hello,

> I'm not familiar with the calc_checksum option. Sounds strange to have
> that built into the driver.

I agree on this, but let's just leave the feature there - for users convenience.
However, the preferred method shall be to externally calculate the checksum and 
embed it into the image.
Despite it is surely possible to make some nasty workaround in OpneOCD, I do 
not see it as the right direction to go.

Pavel
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


Re: [Openocd-development] "reset run" is by default

2008-07-18 Thread Pavel Chromy
Hello Spen,

Spen napsal(a):
>> Let's retire daemon_startup. It is completely equivalent to 
>> -c init -c "reset xxx"
>> it only sows confusion.
>>
>> It is definitely not worth the backwards compatibility 
>> factor, especially for the grief that it will cause for new users.
>>
> My point is we discussed this a while back and not everybody wants to
> remember a commandline - all they want todo is run openocd with a config.

the same behavior can be achieved by adding init and reset commands as last two 
lines in the config script.

I thought that concept of config files and commands given by parameters was 
clear:
all that OpenOCD effectively does is a concatenation of all commands from -f 
and -c
options and executes them one by one. I hope this is still true after Tcl 
integration.

So there is no real inconvenience to the user caused by making daemon_startup 
deprecated.
(There is no necessity to remember any command line.)

Concerning backwards compatibility... despite I think compatibility is good if 
it is possible
to keep it at reasonable cost, but we cannot keep odd and cofusing commands 
when we want to move
forward - keeping 100% compatibility just because some legacy scritpts would be 
a painful way to hell.

Regards,
   Pavel

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


Re: [Openocd-development] Retire reset_mode option to target

2008-07-18 Thread Pavel Chromy
Øyvind Harboe wrote:
> We should of course take into account the current users, but my thinking
> is that OpenOCD's *future* users (who are MUCH more numerous :-)
> will thank us for making the right choice.

Right. I vote for "reset" doing simple reset, that is "reset run" and either 
keep "reset run" as is,
or retire it (which may be controversial, so rather keep it).

Pavel
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


Re: [Openocd-development] Retire reset_mode option to target

2008-07-18 Thread Pavel Chromy

Hello,

Øyvind Harboe wrote:
>> A "reset" will be the same as "reset run". If I want to reset and halt the 
>> target,
>>  then I have to use "reset run_and_init" explicitly. I agree that this is 
>> more intuitive.
> 
> Dominic suggested that perhaps removing the default argument altogether would
> be a good idea since expectations differ.

I think the expectations differ because of historical reasons - some people are 
used to
current behavior with target reset_mode parameter, otherwise I would say that
it shall be pretty clear to most people that simple "reset" command just does 
reset.
(But maybe I am mistaken.)

If there is wider acceptance of removing default behavior, I can live with that 
however,
this would meet a, but not b:
Commands should
a) look logically and resemble the thing they really do
b) are convenient for the user

Regards,
   Pavel
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


Re: [Openocd-development] Retire reset_mode option to target

2008-07-18 Thread Pavel Chromy
Hello Pieter,

Pieter Conradie wrote:
> Hi Øyvind,
> Please explain/specify what is being retired.
> When the target reset configuration is specified, there are options: 
> "reset_halt", "reset_init", "reset_run", "run_and_halt", "run_and_init" For 
> example:
> 
> target arm7tdmi little run_and_init 0
> The reset command has the following options:
> reset ['run'|'halt'|'init'|'run_and_halt' |'run_and_init']
> 
> It is said in the documentation that the "optional parameter overrides the 
> setting specified in the configuration file".
> Do you propose that the target reset configuration is *always* overridden 
> with "reset init"? Why?

Target reset mode specifies what is to be done when plain reset command 
(without parameters) is issued by script/user.
Is a parameter is given to reset command, it always does what the parameter 
says, no matter what was stated in the
target reset configuration.

What is to be retired (if I understood right) is the target reset mode option,
making the behavior of plain reset command fixed (and well defined).

Best regards,
   Pavel
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


Re: [Openocd-development] Retire reset_mode option to target

2008-07-18 Thread Pavel Chromy

Hi Øyvind, Michael and others,

Øyvind Harboe wrote:
> You can choose the type of reset by the argument to reset
> 
> "reset init" *always* executes the init script
> "reset halt" *always* executes a reset halt.
> 
> What we are discussing is the case without any arguments "reset".
> I'd like it to always do a "reset init".

Well, it is really a matter of discussion and also matter of point of view, 
whether
this would be an expected behavior (expected by the user). I would say rather 
not.

Reset is reset, it literally means to reset the target, nothing more.
So if reset_mode is retired, I believe that the default behavior of reset 
command
should be as plain as pressing a button which pulls the reset line - that is, 
"reset run",
just a plain reset. If user needs to init the target, (s)he shall issue "reset 
init" command.

My belief is that commands shall be constructed so that they:
a) look logically and resemble the thing they really do
b) are convenient for the user
Fist a, then b, not otherwise.

And remember - we have Tcl now, so if anyone is not fine with typing "reset 
init",
there is always a possibility to define Tcl proc for this (or even override it 
- this shall be possible in Tcl).

In general, I agree that the default behavior of reset command (unless 
overridden by custom Tcl proc)
shall be fixed, as reset_mode adds unnecessary confusion.

Note: Other logical possibility for reset command without parameters would be 
to do either "reset run"
or "reset [run_and_]halt" depending on current state of the target - i.e. leave 
it running or halted after the reset,
this might also be an expected behavior, probably more expected than "reset 
init", IMHO.

Best regards,

   Pavel

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


Re: [Openocd-development] Is tcl now a must have?

2008-07-10 Thread Pavel Chromy
Hello,

Øyvind Harboe wrote:
> 2. commands.tcl requires (1), but we *could* embed it into the
> executable instead but that addresses the symptom and not
> the disease, it will only help us short-term.

I consider this a goo idea if OOCD functions are changed to be scripting 
friendly
with a TCL frontend like in flash banks example, so that basic commands
are kept completely inside OOCD to reduce hassle for end users, especially those
not much familiar with OOCD yet.

Best ragards,

   Pavel
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


Re: [Openocd-development] Making commands more scripting friendly

2008-07-09 Thread Pavel Chromy

Hello,

Øyvind Harboe napsal(a):
> Consider "flash banks 0".
> 
> The output it produces is pretty hellish to parse from Tcl
> (or any language really) + if we make that output of that
> command part of the API, then changing it becomes
> very awkward.
> 
> Here is a thought on how to address this problem:
> 
> 1. implement a low level fn that returns the information
> above in tcl-speak. This is the OpenOCD API.
> 
> 2. write a small tcl proc that formats the low level fn
> info into a human readable form. This proc is part
> of the "Telnet GUI" and not the API.

So this is like moving OpenOCD in the direction of becoming more a library
and transforming some code which is now internal to OpenOCD (in C) to TCL, 
right?

Pavel
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


Re: [Openocd-development] External scripting of OpenOCD

2008-07-09 Thread Pavel Chromy
Øyvind Harboe napsal(a):
>> I think we can come up with ONE simple reply format that *ALL* host apps
>> can parse.
> 
> I don't see the need for *any* format.
> 
> My thinking is that the API is the tcl you send in, not the return format.
> The return format is according to the convention in the frontend language.tcl
> you use. language.tcl itself should be considered part of the application,
> not the API.

Hello,

If I understood correctly, the external scripting is to be done by submitting 
commands
to TCL server. So at least result of the TCL command processing itself
shall be returned in defined format, or have I missed something?

Best regards,
Pavel

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


Re: [Openocd-development] PATCH - Jim/TCL patch - far more complete.

2008-07-07 Thread Pavel Chromy
Hello,

Duane Ellis napsal(a):
> Øyvind> The GDB "mon" is just the channel/transport.
> That however is an exclusive and private to GDB and GDB alone. That is 
> problematic.
> Stated more generally - it is exclusive to the active debugger on the 
> GDB connection.
> Nothing else can access the target via MON.

I am using GDB protocol to communicate with OpenOCD from flash programming GUI
- not a perfect solution, but it works.

> All that I am suggesting is a more 'programmatic defined protocol' 
> specific to the tcl_server interface - nothing more.

It is absolutely true that using GDB mon is not
much suitable for real scripting from external application, e.g. it lacks
passing a machine readable error code to the caller.

Personally I am not against such extension, but it shall be a simple
submit/result protocol, nothing complicated.

Regards,
   Pavel
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


Re: [Openocd-development] reset config SRST_ONLY

2008-07-01 Thread Pavel Chromy
Hello Steve and all,

Steve Franks wrote:
>> I'd say this is just one more argument for scriptable reset. There is no way
>> we'll be able to come up with an algorithm & config parameters something
>> that can cover all the weird reset schemes out there
>>
>> I'm trying to summarize a consensus + plan here
> 
> Before the ARM, I'd never met a device that used/had a TRST
> signal/pin.  I have alot of cabling without it.  Also, none of the
> logic devices have an SRST either.  Usually just use a 6 pin (4 jtag +
> Vcc & Gnd) cable, seems to work on all my current FPGA & AVR
> designs...

well, you are right. The reset_config basically does make sense for ARMs only.
I do not think that scripting is really needed for doing reset properly,
however, OpenOCD has to take care about keeping state of the whole JTAG chain 
in sync,
that is, when TRST is pulled (or even SRST, if it pulls TRST), the state 
machine has to be
brought to TLR state by means of TMS to ensure that the parts not connected to 
TRST/SRST
are in sync.

I do not know for sure whether OpenOCD does that in current revision (anyone?)

Pavel
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


Re: [Openocd-development] openocd scripting challenge

2008-06-30 Thread Pavel Chromy

Øyvind Harboe wrote:
>> Øyvind Harboe wrote:
>>> Can anyone come up with a good example of how scripting
>>> could be useful in configuration scripts?
>> just as was mentioned already - mass production flash programming ant 
>> testing,
>> but this is pretty important task in my point of view.
> 
> Please explain "ant testing". (I use ant everyday, but I'm not sure it's
> the same ant as you are referring to :-)

...and... of course, just a typo ;-) I do not know how it got there, despite I 
type with all 10 fingers
but I should be more careful and read it back what. Spell checker certainly did 
not complain, as it is a valid word :-)

> Could you explain the mass production scenario a bit more?

Briefly a script which does steps like:

1) upload a routine doing basic hw tests and run it
2) check for result when the testing routine finishes
3) STOP if something went wrong - CONDITIONAL STEP, cannot be done with current 
batch command processing!
4) programming of flash memory
5) verification, STOP on error
6) generate serial number, program it to EEPROM and append it along with date 
and time to a file
7) return OK to calling process so that we can go on with next part

I am sure that more complex examples may be found for hw containing more than 
one target or an FPGA etc...

Pavel
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


Re: [Openocd-development] openocd scripting challenge

2008-06-29 Thread Pavel Chromy
Hello,

Øyvind Harboe wrote:
> Can anyone come up with a good example of how scripting
> could be useful in configuration scripts?

just as was mentioned already - mass production flash programming ant testing,
but this is pretty important task in my point of view.

Pavel
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


Re: [Openocd-development] reset config SRST_ONLY

2008-06-28 Thread Pavel Chromy
Hello ?yvind,

?yvind Harboe napsal(a):
> Basically a TMS reset happens while srst is asserted. This is
> probably to drive the state machine into TAP_TLR as srst
> pulls trst to sync up things.
> 
> A cleaner way would be to simply set the tracked state
> to TAP_TLR.

This is not sufficient in all cases. If there is a part which does not feature 
TRST hooked
up in the JTAG chain (e.g. FPGA) transition to TLR by means of TMS is
a necessity to keep all parts in sync.

I am going to test this soon, we have a board with this configuration in the 
manufacturing
(AT91SAM9260 with SRST pulling TRST + an FPGA without TRST)

Best regards,

   Pavel
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


Re: [Openocd-development] Scripting language experiments

2008-06-27 Thread Pavel Chromy

Hello Michael and Øyvind,

Michael Schwingen wrote:
>> messing around with this. Ideally they should just specify the
>> target via the target library and then live happily ever after without
>> worrying about OpenOCD again :-) If end users never mess
>> around with the scripting language
> 
> I don't really see this happening. At work, I use a BDI2000 on different 
> targets, and I usually have to write a config file that matches my hardware.

I agree on this... modification of a script is often necessary to make it work 
with given hw.

>> - write a flash driver in tcl. A flash driver consists of "a few peeks
>> and pokes". Could a tcl script handle this for non-standard parts?

I think this would perform really bad. Flash drivers without semi-hosting are 
slow
on high latency JTAG interfaces even if written in C.

>> The eCos + ocl flash drivers have had zero visible success.

Sad but true, however, I am planning to do some more work on this.

>> - write variant target support in tcl. The slight arm7/9 variants
>> could perhaps be written in tcl?

I have to say, that I do not like such idea at all, I doubt that end users 
would cope with TCL (or anything else)
to create target variant support. This is rather unlikely. And for developers - 
mixture of two languages does not bring 
benefits, it would just make things more complicated.

> I do not really see the benefit of splitting the source code for developers 
> into two languages. Having a full-fledged scripting language for 
> configuration is great,
> however, if I need to learn another language to add/modify/patch openocd code 
> (like the CFI flash driver), I will be reluctant to do so.
> Another problem: how do you debug a mixture of C and script code? Currently, 
> I can start up gdb on openocd and see everything that happens.

My words, I do not see a benefit.
However, scripting for configuration is fine (but not a necessity from my point 
of view).

Regards,
   Pavel
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


[Openocd-development] patch: jtag.c TLR rather than tms

2008-06-18 Thread Pavel Chromy

Hello list,

A cosmetic patch changing several remainder strings and comments
- TAP reset without TRST shall be called TLR (stands for test-logic-reset, 
named after the TAP state it ends is) rather than tms (test-mode-select)
- some comments changed to /* C coding style */

Please commit
  Pavel
Index: src/jtag/jtag.c
===
--- src/jtag/jtag.c (revision 714)
+++ src/jtag/jtag.c (working copy)
@@ -106,7 +106,7 @@
 
 char* jtag_event_strings[] =
 {
-   "JTAG controller reset(tms or TRST)"
+   "JTAG controller reset (TLR or TRST)"
 };
 
 /* kludge these are just global variables that the
@@ -927,7 +927,7 @@

/* FIX!!! there are *many* different cases here. A better
 * approach is needed for legal combinations of transitions...
-   */
+*/
if ((jtag_reset_config & RESET_HAS_SRST)&&
(jtag_reset_config & RESET_HAS_TRST)&& 
((jtag_reset_config & RESET_SRST_PULLS_TRST)==0))
@@ -937,7 +937,7 @@
((req_srst&&!jtag_srst)||
(!req_srst&&jtag_srst)))
{
-   // FIX!!! srst_pulls_trst allows 1,1 => 0,0 
transition
+   /* FIX!!! srst_pulls_trst allows 1,1 => 0,0 
transition */
//LOG_ERROR("BUG: transition of req_tlr_or_trst and 
req_srst in the same jtag_add_reset() call is undefined");
}
}
@@ -1000,7 +1000,7 @@

if (trst_with_tlr)
{
-   LOG_DEBUG("JTAG reset with tms instead of TRST");
+   LOG_DEBUG("JTAG reset with TLR instead of TRST");
jtag_add_end_state(TAP_TLR);
jtag_add_tlr();
jtag_call_event_callbacks(JTAG_TRST_ASSERTED);
@@ -1578,11 +1578,11 @@
if ((retval=jtag_interface_init(cmd_ctx)) != ERROR_OK)
return retval;
 
-   LOG_DEBUG("Trying to bring the JTAG controller to life by asserting 
TRST / tms");
+   LOG_DEBUG("Trying to bring the JTAG controller to life by asserting 
TRST / TLR");
 
/* Reset can happen after a power cycle.
 * 
-* Ideally we would only assert TRST or run tms before the target reset.
+* Ideally we would only assert TRST or run TLR before the target reset.
 * 
 * However w/srst_pulls_trst, trst is asserted together with the target
 * reset whether we want it or not.
@@ -1595,7 +1595,7 @@
 * NB! order matters srst *can* disconnect JTAG circuitry
 * 
 */
-   jtag_add_reset(1, 0); /* TMS or TRST */
+   jtag_add_reset(1, 0); /* TLR or TRST */
if (jtag_reset_config & RESET_HAS_SRST)
{
jtag_add_reset(1, 1);
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


[Openocd-development] patch: several issues with PRESTO

2008-06-18 Thread Pavel Chromy

Hello list,

the attached patch fixes several issues in presto.c
- lower jtag speeds (higher divisor) was used, TDI was not changed on falling 
TCK edge as it should
- reset signal was release upon any TMS transition, making it impossible to use 
reset halt
- added khz() and speed_div() functions

and bitq.c
- TAP state changed to TLR when SRST goes active with srst_pulls_trst, as in 
all other drivers

Please commit
  Pavel
Index: src/jtag/bitq.c
===
--- src/jtag/bitq.c (revision 714)
+++ src/jtag/bitq.c (working copy)
@@ -283,6 +283,10 @@
 #ifdef _DEBUG_JTAG_IO_
LOG_DEBUG("reset trst: %i srst %i", 
cmd->cmd.reset->trst, cmd->cmd.reset->srst);
 #endif
+   if ((cmd->cmd.reset->trst == 1) || 
(cmd->cmd.reset->srst && (jtag_reset_config & RESET_SRST_PULLS_TRST)))
+   {
+   cur_state = TAP_TLR;
+   }
bitq_interface->reset(cmd->cmd.reset->trst, 
cmd->cmd.reset->srst);
if (bitq_interface->in_rdy()) bitq_in_proc();
break;
Index: src/jtag/presto.c
===
--- src/jtag/presto.c   (revision 714)
+++ src/jtag/presto.c   (working copy)
@@ -51,6 +51,8 @@
 
 
 int presto_jtag_speed(int speed);
+int presto_jtag_khz(int khz, int *jtag_speed);
+int presto_jtag_speed_div(int speed, int *khz);
 int presto_jtag_register_commands(struct command_context_s *cmd_ctx);
 int presto_jtag_init(void);
 int presto_jtag_quit(void);
@@ -60,6 +62,8 @@
.name = "presto",
.execute_queue = bitq_execute_queue,
.speed = presto_jtag_speed,
+   .khz = presto_jtag_khz,
+   .speed_div = presto_jtag_speed_div,
.register_commands = presto_jtag_register_commands,
.init = presto_jtag_init,
.quit = presto_jtag_quit,
@@ -121,10 +125,13 @@
 
int jtag_tms; /* last tms state */
int jtag_tck; /* last tck state */
+   int jtag_rst; /* last trst state */
 
int jtag_tdi_data;
int jtag_tdi_count;
 
+   int jtag_speed;
+   
 } presto_t;
 
 presto_t presto_state;
@@ -422,9 +429,12 @@
 
presto->jtag_tms=0;
presto->jtag_tck=0;
+   presto->jtag_rst=0;
presto->jtag_tdi_data=0;
presto->jtag_tdi_count=0;
 
+   presto->jtag_speed=0;
+   
 #if BUILD_PRESTO_FTD2XX == 1
return presto_open_ftd2xx(req_serial);
 #elif BUILD_PRESTO_LIBFTDI == 1
@@ -567,81 +577,95 @@
 /* -- 
*/
 
 
+int presto_tdi_flush(void)
+{
+   if (presto->jtag_tdi_count == 0)
+   return 0;
+
+   if (presto->jtag_tck == 0)
+   {
+   LOG_ERROR("BUG: unexpected TAP condition, TCK low");
+   return -1;
+   }
+
+   presto->jtag_tdi_data |= (presto->jtag_tdi_count - 1) << 4;
+   presto_sendbyte(presto->jtag_tdi_data);
+   presto->jtag_tdi_count = 0;
+   presto->jtag_tdi_data = 0;
+   
+   return 0;
+}
+
+
+int presto_tck_idle(void)
+{
+   if (presto->jtag_tck == 1)
+   {
+   presto_sendbyte(0xCA);
+   presto->jtag_tck = 0;
+   }
+   
+   return 0;
+}
+
+
+/* -- 
*/
+
+
 int presto_bitq_out(int tms, int tdi, int tdo_req)
 {
-   unsigned char cmdparam;
+   int i;
+   unsigned char cmd;
 
if (presto->jtag_tck == 0)
{
-   presto_sendbyte(0xA4); /* jtag activity */
-   presto->jtag_tck = 1; /* clock remains high after the function 
returns */
-   /* do just a single tick first, accelerated shifting needs 
TCK=1 */
+   presto_sendbyte(0xA4); /* LED idicator - JTAG active */
}
-   else if (!tdo_req && tms == presto->jtag_tms)
+   else if (presto->jtag_speed == 0 && !tdo_req && tms == presto->jtag_tms)
{
-   if (presto->jtag_tdi_count == 0)
-   presto->jtag_tdi_data = (tdi != 0);
-   else
-   presto->jtag_tdi_data |= (tdi != 0) << 
presto->jtag_tdi_count;
+   presto->jtag_tdi_data |= (tdi != 0) << presto->jtag_tdi_count;
 
if (++presto->jtag_tdi_count == 4)
-   {
-   presto->jtag_tdi_data |= (presto->jtag_tdi_count - 1) 
<< 4;
-   presto_sendbyte(presto->jtag_tdi_data);
-   presto->jtag_tdi_count = 0;
-   }
+   presto_tdi_flush();
+
return 0;
}
 
-   if (presto->jtag_tdi_count)
-   {
-   presto->jtag_tdi_data |= (presto->jtag_tdi_count - 1) << 4;
-   presto_sendbyte(presto->jtag_tdi_data);
-