Re: [Openocd-development] udev rules for openocd

2009-01-21 Thread John McCarthy
Hmm, guess I should have read the whole thread before I posted. ;-) I see the openocd.udev patch is worrying about permissions for the USB devices. For my FT2232 based OpenOCD USB device the tty devices are also important. This becomes a real headache when you have multiple ttyUSB devices (OpenOC

Re: [Openocd-development] udev rules for openocd

2009-01-21 Thread John McCarthy
how about this one for the OpenOCD USB from Embedded-Projects.net: SUBSYSTEMS=="usb", ATTRS{product}=="Dual RS232", ATTRS{idProduct}=="6010", ATTRS{idVendor}=="0403", KERNEL=="ttyUSB*", SYMLINK+="openocd$attr{bInterfaceNumber}" creates /dev/openocd00 and /dev/openocd01 for the two serial i

Re: [Openocd-development] udev rules for openocd

2009-01-20 Thread Rick Altherr
On Jan 20, 2009, at 11:51 AM, Uwe Hermann wrote: On Tue, Jan 20, 2009 at 08:39:14PM +0100, Uwe Hermann wrote: On Tue, Jan 20, 2009 at 09:07:42AM -0800, Rick Altherr wrote: I await an updated file that includes all the additional device lines that have flown by on this list. Sure, attached

Re: [Openocd-development] udev rules for openocd

2009-01-20 Thread Michel Catudal
Rick Altherr a écrit : > > In terms of including this as part of OpenOCD, we suffer from > supporting multiple platforms and distrubtions. The preferred install > location for the udev script is likely to vary by distribution and it > only applies to the Linux platform. Many other projects han

Re: [Openocd-development] udev rules for openocd

2009-01-20 Thread Uwe Hermann
On Tue, Jan 20, 2009 at 10:15:42AM -0600, lou.openocd...@fixit.nospammail.net wrote: > Of course. Why not 0, then? Does it make sense to give everybody read > access to the node? Ah, I see. I don't know which one should be used, I don't mind either way. As far as I've seen in /etc/udev/ on my s

Re: [Openocd-development] udev rules for openocd

2009-01-20 Thread Uwe Hermann
On Tue, Jan 20, 2009 at 08:39:14PM +0100, Uwe Hermann wrote: > On Tue, Jan 20, 2009 at 09:07:42AM -0800, Rick Altherr wrote: > > I await an updated file that includes all the additional device lines > > that have flown by on this list. > > Sure, attached. Oops, forgot one. Updated patch attache

Re: [Openocd-development] udev rules for openocd

2009-01-20 Thread Uwe Hermann
On Tue, Jan 20, 2009 at 09:07:42AM -0800, Rick Altherr wrote: > I await an updated file that includes all the additional device lines > that have flown by on this list. Sure, attached. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.u

Re: [Openocd-development] udev rules for openocd

2009-01-20 Thread Rick Altherr
On Jan 20, 2009, at 7:41 AM, Uwe Hermann wrote: On Mon, Jan 19, 2009 at 07:21:39PM -0800, Rick Altherr wrote: As a platform-neutral project, I'd rather not call out any distribution by name and leave it up to the packager to figure out how best to include the contrib files. Yep, contrib/

Re: [Openocd-development] udev rules for openocd

2009-01-20 Thread lou . openocd012
On Tue, Jan 20, 2009 at 04:39:52PM +0100, Uwe Hermann wrote: > On Tue, Jan 20, 2009 at 07:53:14AM -0600, lou.openocd...@fixit.nospammail.net > wrote: > > And another part for rlink: > > > > # Raisonance RLink > > SYSFS{idVendor}=="138e", SYSFS{idProduct}=="9000", MODE="664", > > GROUP="plugdev"

Re: [Openocd-development] udev rules for openocd

2009-01-20 Thread Uwe Hermann
On Mon, Jan 19, 2009 at 07:21:39PM -0800, Rick Altherr wrote: > As a platform-neutral project, I'd rather not call out any distribution by > name and leave it up to the packager to figure out how best to include > the contrib files. Yep, contrib/ sounds good. Uwe. -- http://www.hermann-uwe.de

Re: [Openocd-development] udev rules for openocd

2009-01-20 Thread Uwe Hermann
On Tue, Jan 20, 2009 at 07:53:14AM -0600, lou.openocd...@fixit.nospammail.net wrote: > And another part for rlink: > > # Raisonance RLink > SYSFS{idVendor}=="138e", SYSFS{idProduct}=="9000", MODE="664", GROUP="plugdev" > > Does the 4 in 664 make sense? Yes, you don't want _all_ users to have wr

[Openocd-development] udev rules for openocd

2009-01-20 Thread Laurent Gauch
Please already add Amontec JTAGkey-HiSpeed VID:0x0FBB PID:0x1000 # Amontec JTAGkey-HiSpeed SYSFS{idVendor}=="0x0FBB", SYSFS{idProduct}=="0x1000", MODE="664", GROUP="plugdev" Thanks, Laurent ___ Openocd-development mailing list Openocd-development@li

Re: [Openocd-development] udev rules for openocd

2009-01-20 Thread lou . openocd012
And another part for rlink: # Raisonance RLink SYSFS{idVendor}=="138e", SYSFS{idProduct}=="9000", MODE="664", GROUP="plugdev" Does the 4 in 664 make sense? On Mon, Jan 19, 2009 at 07:03:02PM -0800, Zach Welch wrote: > On Tue, 2009-01-20 at 03:43 +0100, Uwe Hermann wrote: > > here's a short udev

Re: [Openocd-development] udev rules for openocd

2009-01-19 Thread Rick Altherr
On Jan 19, 2009, at 6:43 PM, Uwe Hermann wrote: Hi, here's a short udev rules file for OpenOCD which I'm using in the Debian package. It should probably be added to svn, together with some autotools hooking so that it gets installed somewhere upon 'make install' (or not, and leave that s

Re: [Openocd-development] udev rules for openocd

2009-01-19 Thread Dean Glazeski
Let's not forget the little Olimex OpenOCD JTAG TINY. # Olimex ARM-USB-OCD-TINY SYSFS{idVendor}=="15ba", SYSFS{idProduct}=="0004", MODE="664", GROUP="plugdev" // Dean Zach Welch wrote: On Tue, 2009-01-20 at 03:43 +0100, Uwe Hermann wrote: here's a short udev rules file for OpenOCD which

Re: [Openocd-development] udev rules for openocd

2009-01-19 Thread Zach Welch
On Tue, 2009-01-20 at 03:43 +0100, Uwe Hermann wrote: > here's a short udev rules file for OpenOCD which I'm using in the Debian > package. It should probably be added to svn, together with some > autotools hooking so that it gets installed somewhere upon 'make install' > (or not, and leave that st

[Openocd-development] udev rules for openocd

2009-01-19 Thread Uwe Hermann
Hi, here's a short udev rules file for OpenOCD which I'm using in the Debian package. It should probably be added to svn, together with some autotools hooking so that it gets installed somewhere upon 'make install' (or not, and leave that step to the user). In the Debian package it ends up as /et