[Openocd-development] [PATCH] update udev rules for new udev version

2010-01-04 Thread Johannes Stezenbach 
Hi,

new versions of udev (148+) emit the following warnings:

Dec  8 17:06:23 worf udevd[425]: BUS= will be removed in a future udev version, 
please use SUBSYSTEM= to match the event device, or SUBSYSTEMS= to match a 
parent device, in /lib/udev/rules.d/60-openocd.rules:1
Dec  8 17:06:23 worf udevd[425]: SYSFS{}= will be removed in a future udev 
version, please use ATTR{}= to match the event device, or ATTRS{}= to match a 
parent device, in /lib/udev/rules.d/60-openocd.rules:4
Dec  8 17:06:23 worf udevd[425]: SYSFS{}= will be removed in a future udev 
version, please use ATTR{}= to match the event device, or ATTRS{}= to match a 
parent device, in /lib/udev/rules.d/60-openocd.rules:7
...

See also
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560141


The patch below fixes it.


Thanks,
Johannes



diff --git a/contrib/openocd.udev b/contrib/openocd.udev
index c878975..be5ab49 100644
--- a/contrib/openocd.udev
+++ b/contrib/openocd.udev
@@ -1,60 +1,62 @@
-BUS!="usb", ACTION!="add", SUBSYSTEM!=="usb_device", GOTO="openocd_rules_end"
+ACTION!="add|change", GOTO="openocd_rules_end"
+SUBSYSTEM!="usb", GOTO="openocd_rules_end"
+ENV{DEVTYPE}!="usb_device", GOTO="openocd_rules_end"
 
 # Olimex ARM-USB-OCD
-SYSFS{idVendor}=="15ba", SYSFS{idProduct}=="0003", MODE="664", GROUP="plugdev"
+ATTRS{idVendor}=="15ba", ATTRS{idProduct}=="0003", MODE="664", GROUP="plugdev"
 
 # Olimex ARM-USB-OCD-TINY
-SYSFS{idVendor}=="15ba", SYSFS{idProduct}=="0004", MODE="664", GROUP="plugdev"
+ATTRS{idVendor}=="15ba", ATTRS{idProduct}=="0004", MODE="664", GROUP="plugdev"
 
 # Olimex ARM-JTAG-EW
-SYSFS{idVendor}=="15ba", SYSFS{idProduct}=="001e", MODE="664", GROUP="plugdev"
+ATTRS{idVendor}=="15ba", ATTRS{idProduct}=="001e", MODE="664", GROUP="plugdev"
 
 # USBprog with OpenOCD firmware
-SYSFS{idVendor}=="1781", SYSFS{idProduct}=="0c63", MODE="664", GROUP="plugdev"
+ATTRS{idVendor}=="1781", ATTRS{idProduct}=="0c63", MODE="664", GROUP="plugdev"
 
 # Amontec JTAGkey and JTAGkey-tiny
-SYSFS{idVendor}=="0403", SYSFS{idProduct}=="cff8", MODE="664", GROUP="plugdev"
+ATTRS{idVendor}=="0403", ATTRS{idProduct}=="cff8", MODE="664", GROUP="plugdev"
 
 # Amontec JTAGkey-HiSpeed
-SYSFS{idVendor}=="0fbb", SYSFS{idProduct}=="1000", MODE="664", GROUP="plugdev"
+ATTRS{idVendor}=="0fbb", ATTRS{idProduct}=="1000", MODE="664", GROUP="plugdev"
 
 # Axiom AXM-0432 Link (Symphony SoundBite?)
 # Calao Systems USB-A9260-C01
 # TinCanTools Flyswatter
 # OOCD-Link
 # Marvell Sheevaplug (early development versions)
-SYSFS{idVendor}=="0403", SYSFS{idProduct}=="6010", MODE="664", GROUP="plugdev"
+ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6010", MODE="664", GROUP="plugdev"
 
 # Calao Systems USB-A9260-C02
-SYSFS{idVendor}=="0403", SYSFS{idProduct}=="6001", MODE="664", GROUP="plugdev"
+ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", MODE="664", GROUP="plugdev"
 
 # IAR J-Link USB
-SYSFS{idVendor}=="1366", SYSFS{idProduct}=="0101", MODE="664", GROUP="plugdev"
+ATTRS{idVendor}=="1366", ATTRS{idProduct}=="0101", MODE="664", GROUP="plugdev"
 
 # Raisonance RLink
-SYSFS{idVendor}=="138e", SYSFS{idProduct}=="9000", MODE="664", GROUP="plugdev"
+ATTRS{idVendor}=="138e", ATTRS{idProduct}=="9000", MODE="664", GROUP="plugdev"
 
 # Hitex STR9-comStick
-SYSFS{idVendor}=="0640", SYSFS{idProduct}=="002c", MODE="664", GROUP="plugdev"
+ATTRS{idVendor}=="0640", ATTRS{idProduct}=="002c", MODE="664", GROUP="plugdev"
 
 # Hitex STM32-PerformanceStick
-SYSFS{idVendor}=="0640", SYSFS{idProduct}=="002d", MODE="664", GROUP="plugdev"
+ATTRS{idVendor}=="0640", ATTRS{idProduct}=="002d", MODE="664", GROUP="plugdev"
 
 # Luminary Micro Stellaris/LM3S811
-SYSFS{idVendor}=="0403", SYSFS{idProduct}=="bcd9", MODE="664", GROUP="plugdev"
+ATTRS{idVendor}=="0403", ATTRS{idProduct}=="bcd9", MODE="664", GROUP="plugdev"
 
 # Xverve Signalyzer Tool (DT-USB-ST)
-SYSFS{idVendor}=="0403", SYSFS{idProduct}=="bca0", MODE="664", GROUP="plugdev"
+ATTRS{idVendor}=="0403", ATTRS{idProduct}=="bca0", MODE="664", GROUP="plugdev"
 
 # egnite Turtelizer 2
-SYSFS{idVendor}=="0403", SYSFS{idProduct}=="bdc8", MODE="664", GROUP="plugdev"
+ATTRS{idVendor}=="0403", ATTRS{idProduct}=="bdc8", MODE="664", GROUP="plugdev"
 
 # Marvell Sheevaplug
-SYSFS{idVendor}=="9e88", SYSFS{idProduct}=="9e8f", MODE="664", GROUP="plugdev"
+ATTRS{idVendor}=="9e88", ATTRS{idProduct}=="9e8f", MODE="664", GROUP="plugdev"
 
 # Section5 ICEbear
-SYSFS{idVendor}=="0403", SYSFS{idProduct}=="c140", MODE="664", GROUP="plugdev"
-SYSFS{idVendor}=="0403", SYSFS{idProduct}=="c141", MODE="664", GROUP="plugdev"
+ATTRS{idVendor}=="0403", ATTRS{idProduct}=="c140", MODE="664", GROUP="plugdev"
+ATTRS{idVendor}=="0403", ATTRS{idProduct}=="c141", MODE="664", GROUP="plugdev"
 
 LABEL="openocd_rules_end"
 
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] What's git's equivalent to svn version #?

2009-10-14 Thread Johannes Stezenbach 
On Wed, Oct 14, 2009 at 04:11:33PM +0200, Øyvind Harboe wrote:
> What's the most reasonable way to refer to a git version
> for human beings?
> 
> In svn it's a small integer("only" in the thousands).
> 
> I was thinking about something like "0.2 + N versions".

How about 'git describe'?

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

Re: [Openocd-development] JTAG controllers disabled while SRST is asserted

2009-09-15 Thread Johannes Stezenbach 
On Tue, Sep 15, 2009 at 09:15:34AM +0200, Øyvind Harboe wrote:
> On Mon, Sep 14, 2009 at 10:08 PM, Johannes Stezenbach  wrote:
> >
> > I thought the desired reset procedure at least on ARM9 is:
> >
> > - pull SRST and TRST (TRST not only resets the TAP but also EmbeddedICE)
> > - release TRST
> > - program EmbeddedICE to break on reset vector
> > - release SRST
> 
> To optionally program arm7/9 if srst does not gate the JTAG clock is
> a possible improvement, but I'm not sure why it would be better to
> program EmbeddedICE to break on reset vector while srst
> is asserted.
> 
> What would that achieve as oposed to first programming the
> break on reset and afterwards asserting/deasserting srst?

I once managed to flash a wrong boot loader, which caused
the system to hang completely (including JTAG) due to
wrong clock programming.  Sometimes you need to prevent the
system from executing any code.


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

Re: [Openocd-development] JTAG controllers disabled while SRST is asserted

2009-09-14 Thread Johannes Stezenbach 
On Mon, Sep 14, 2009 at 08:35:32PM +0200, Øyvind Harboe wrote:
> On Mon, Sep 14, 2009 at 7:42 PM, David Brownell  wrote:
> > On Monday 14 September 2009, Ųyvind Harboe wrote:
> >> I suspect there are JTAG controllers that do not communicate when
> >> SRST is asserted, but do not pull TRST.
> >>
> >> srst_pulls_trst will kinda work on these devices i.MX27(??).
> >>
> >> The first thought that strikes me here is to split out srst_pulls_trst into
> >> two flags: pulls trst and no JTAG communication during srst
> >
> > What code do we have which wants JTAG chitchat during SRST?
> 
> I thought arm7/9 did this, but I was wrong. I'm wondering if
> XScale needs this.
> 
> Turns out after some more testing that i.MX27 does appear to
> pull trst during srst.

I thought the desired reset procedure at least on ARM9 is:

- pull SRST and TRST (TRST not only resets the TAP but also EmbeddedICE)
- release TRST
- program EmbeddedICE to break on reset vector
- release SRST

There are SoCs where SRST gates the ARM core clock, thus you
cannot program EmbeddedICE while SRST is asserted; then you need:

- pull SRST and TRST
- release SRST and TRST
- program EmbeddedICE to break on reset vector
- pull SRST again
- release SRST


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

Re: [Openocd-development] configure with ftd2xxx options Help & Input Needed

2008-12-25 Thread Johannes Stezenbach 
On Thu, Dec 25, 2008 at 09:16:41AM +0100, Dirk Behme wrote:
> Rick Altherr wrote:
> > On Dec 23, 2008, at 7:50 PM, Duane Ellis wrote:
> >>(b) Secondly, I have to add the "-Wl,-rpath," if we choose
> >> to use the .SO file.
> >>Otherwise - well - openocd will not find the file when you run it.
> >>It will link - due to the "-L", but not *FIND* due to missing '- 
> >> rpath'
> > 
> > Personally a find the use of rpath a horrible direction for us to go.   
> > Shared libraries encode their install location as part of the binary.   
> > FTDI has built their library with a perfectly acceptable install  
> > location encoded in the binary.  A user should download the d2xx  binary 
> > and put the files in the proper installed locations.  Hacking  up our 
> > configure scripts so users can be lazy and FTDI doesn't need to  fix 
> > their horribly packaged binary is just wrong.  I realize we want  to 
> > appeal to the masses, but if a user is going to compile from  source, 
> > they should be able to move a few files around.

IIRC libtool uses -rpath so you can run a binary from the build
dir during development. But this means it has to link again
for "make install" to remove the hardcoded path. If you install
using a non-standard --prefix (i.e. not /usr or /usr/local),
you'll usually have to set LD_LIBRARY_PATH to run your app.
I've installed many libs and apps somewhere in my home dir
over the years, and none of them used rpath there, I've
always had to set LD_LIBRARY_PATH. I guess the rationale
is that a binary using rpath breaks when it is moved to
another location, which is usually not acceptable.
So, -rpath has its use but its not necessarily the best tool
to solve the non-standard prefix problem.

BTW, I've never used libftd2xx0 but I just looked at the
libftd2xx0.4.16.tar.gz readme.dat there is a hardcoded
path for the ftd2xx.cfg file. So it needs to be installed
there anyway?

> > If libftdi is built with --prefix, its install path in the binary will  
> > be correct and everything is fine.  No rpath is necessary.

That doesn't sound right, ld.so needs to find the lib, thus
the path to libftdi cannot be built into libftdi...

If libftdi is not installed in /lib, /usr/lib or one of
the directories listed in /etc/ld.so.conf, you need
LD_LIBRARY_PATH when running openocd (or link openocd with -rpath).
If you want to make it convencient to openocd users to use
a non-standard --prefix it's best to supply a small shell script, e.g.:

  #!/bin/sh
  # assume script is in $prefix/bin and libs are in $prefix/lib
  dir=${0%/*}
  LD_LIBRARY_PATH=$dir/../lib
  export LD_LIBRARY_PATH
  exec $dir/openocd

> Short conclusion from my (limited Linux only) point of view. I think 
> for my use cases everything would already be fine
> 
> * if for (open source) libftdi path given by --prefix is used by -I 
> and -L, too.
> 
> * if for (binary) ftd2xx path given by (existing) -with-ftd2xx is 
> additonally used by -L
> 
> Maybe we can start with these two fixes which are improvements 
> already? And then go on with further changes (e.g. introducing 
> --with-ftd2xx-win32-zipdir and --with-ftd2xx-linux-tardir ) later in a 
> second step on top of this?

IMHO it is good practice to hide differences between platforms
and library versions and handle this inside the configure script.

The canonical use for the --with-ftd2xx option would be:

  --with-ftd2xx  or --with-ftd2xx=yes   search default path (/usr)
  --without-ftd2xx or --with-ftd2xx=no  don't use libftd2xx
  --with-ftd2xx=/some/path  search given path

e.g see
http://git.cryp.to/autoconf-archive?a=blob;f=ac_lib_id3.m4;h=baabf6d569b9fbd8b4dfdf7007c40a69be0e549d;hb=HEAD

This could be complemented with --enable-static-ftd2xx if desired.
A few lines of shell script inside configure.in can then detect
the full path for the lib and header file.

The user has the option of installing the lib in a standard place,
or just unpack it and pass the path to --with-ftd2xx=. If the user
wants to install in a non-standard prefix _and_ use the shared
lib then it's the user's responsibility to also intall the shared
library in this prefix and set LD_LIBRARY_PATH.


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

Re: [Openocd-development] warnings patch

2008-08-18 Thread Johannes Stezenbach 
On Wed, Aug 06, 2008, Spen wrote:
> 
> I have committed the attached patch.
> It removes a few more build warnings.
> fixes broken mips build - unsure when this happened.
> 
> fixes non working --enable-gccwarnings configure option.
> added --enable-gccwarnings to docs.

Attached is another warnings patch which fixes

  ../../src/helper/command.h:82: warning: function declaration isn’t a prototype

which repeats throughout the build with --enable-gccwarnings.
Patch is against today's svn r928.


Thanks,
Johannes

PS: IMHO --enable-gccwarnings should be the default.
Index: src/helper/command.c
===
--- src/helper/command.c(revision 926)
+++ src/helper/command.c(working copy)
@@ -709,7 +709,7 @@
return ERROR_OK;
 }
 
-void process_jim_events() 
+void process_jim_events(void) 
 {
 #ifdef JIM_EMBEDDED
static int recursion = 0;
Index: src/helper/command.h
===
--- src/helper/command.h(revision 926)
+++ src/helper/command.h(working copy)
@@ -79,7 +79,7 @@
 extern int command_run_linef(command_context_t *context, char *format, ...);
 extern void command_output_text(command_context_t *context, const char *data);
 
-extern void process_jim_events();
+extern void process_jim_events(void);
 
 #defineERROR_COMMAND_CLOSE_CONNECTION  (-600)
 #defineERROR_COMMAND_SYNTAX_ERROR  (-601)
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Adding Jim Tcl support to OpenOCD

2008-06-25 Thread Johannes Stezenbach 
On Wed, Jun 25, 2008 at 12:33:42PM +0200, Øyvind Harboe wrote:
> The key merit I'm evaluating this on is whether it would take
> a lot of time for me to do. :-)
> 
> I've already used & implemented Lua, but I couldn't get engineers
> to work up the interest in it. Tcl turned out to be easier. Tcl is
> a really sick language btw. :-)
> 
> The fact that Lua is used for games gives it excellent numbers,
> but considering the openocd user demography tcl could well
> be ahead anyway.

My last experience with Tcl was about 10 years ago when I worked
for a company which embedded it in a largish product. It turned
out to be a bad choice for two reasons (IIRC after 10 years):

- Tcl is "a really sick language" :-) (e.g. difficult quoting rules)
- but the Tcl interpreter was not helpful at all in pointing
  out errors to the programmer, especially for missing quotes
  and brackets

Just imagine if gcc wouldn't give you warnings and error
messages but just abort if there is a problem...

We then switched to Python which gave us detailed tracebacks
and error messages, and productivity and developer happyness
increased significantly.


Does Tcl nowadays do better in this respect?
Is Tcl friendly and helpful to developers?


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