On Wed, May 27, 2009 at 3:19 PM, Mark Stodola<[log in to unmask]> wrote:
> Nicola Maggi wrote:
>>
>> Hello to everyone,
>> I have a Scientific Linux CERN 4 installation and I need to control an
>> usb device with it.
>> My device is an Opal Kelly FPGA with an usb interface.
>> I need to access it from some c++ code.
>> In the FPGA user manual they say:
>> __________
>> The Linux installation requires the addition of one file to the directory:
>>
>> 60-opalkelly.rules -----> /etc/udev/rules.d/
>>
>> This file includes a generic udev rule to set the permissions on all
>> attached Opal Kelly USB devices to allow user access. Once this file is
>> in place, you will need to reload the rules by either rebooting or using
>> the following command:
>>
>> /sbin/udevcontrol reload_rules
>> __________
>> I successfully copied the file into rules.d/ but I still have some
>> problem.
>> I don't have the /sbin/udevcontrol application:
>> all the application with udev in their name are:
>> udevinfo
>> udevtest
>> start_udev
>> udev
>> udevd
>> udevstart
>> udevstart.static
>> udev.static
>> udev_colume_id
>>
>> the file 60-opalkelly.rules is pasted at the and of this mail.
>> How do I make the system load this rule manually?
>> If I reboot while the device is connected everything works fine,
>> except that I can only access the FPGA with root priviledges. Any way
>> to allow users to use it?
>> Thank you in advance,
>> Nicola Maggi
>>
>>
>> # udev rules file for all Opal Kelly VID matches.
>> # This file allows udev to change the mode to 666 (all read/write)
>> # for any Opal Kelly VID.
>> #
>>
>> # For FedoraCore 5 and similar:
>> SUBSYSTEM=="usb_device", SYSFS{idVendor}=="151f", MODE="0666"
>>
>> # For FedoraCore 7 and similar:
>> SUBSYSTEM=="usb", ATTRS{idVendor}=="151f", MODE="0666"
>>
>
> Nicola,
>
> Those rules look like they were written for a different version of udev than
> what SL 4 provides.
> In order to reload new rules in SL 4, simply executing 'udevstart' should do
> the trick. It will cause a reload.
> As for the rules, you'll need to rewrite them, which isn't difficult.
> Newer udev (like the one in SL 5) have changed to allow everything in 1
> definition similar to what you have provided.
> The MODE entry isn't supported, you'll need an entry in
> /etc/udev/permissions.d/ to handle that.
> It will help if you know the device node name when writing the rules, or to
> define one that will be consistent.
>
> For example, here is what I use to make sure a serial adapter is always
> detected correctly with the permissions I want:
> # /etc/udev/rules.d/11-edgeport.rules
> BUS="usb" SYSFS{idVendor}="1608" SYSFS{idProduct}="0201" SYSFS{serial}="*-0"
> NAME="%k" SYMLINK="ttyEDGE0%e"
> BUS="usb" SYSFS{idVendor}="1608" SYSFS{idProduct}="0201" SYSFS{serial}="*-1"
> NAME="%k" SYMLINK="ttyEDGE1%e"
>
> This generates /dev/ttyEDGE0, /dev/ttyEDGE01, /dev/ttyEDGE1, /dev/ttyEDGE11
> aliased to the correct /dev/ttyUSB#.
>
> # /etc/udev/permissions.d/10-udev.permissions
> ttyS*:root:uucp:0666
> ttyUSB*:root:uucp:0666
>
> This gives any device node of /dev/ttyS# or /dev/tty/USB# permissions of
> 0666.
>
> I hope that helps.
>
> Cheers,
> Mark
>
> --
> Mr. Mark V. Stodola
> Digital Systems Engineer
>
> National Electrostatics Corp.
> P.O. Box 620310
> Middleton, WI 53562-0310 USA
> Phone: (608) 831-7600
> Fax: (608) 831-9591
>
>
Hi,
thanks for the useful help but I just managed to find some time to
work on this problem.
I modified my 60-opalkelly.rules as follows:
# udev rules file for all Opal Kelly VID matches.
# This file allows udev to change the mode to 666 (all read/write)
# for any Opal Kelly VID.
#
# For FedoraCore 5 and similar:
SUBSYSTEM=="usb_device", SYSFS{idVendor}=="151f", NAME="%k", SYMLINK="usbFP%n"
# For FedoraCore 7 and similar:
SUBSYSTEM=="usb", ATTRS{idVendor}=="151f",NAME="%k", SYMLINK="usbFP%n"
and added this lines in the 50-udev.permissions file:
#opalkelly devices
usbFP*:nick2k3:nick2k3:0666
where nick2k3 is my non-root user.
I notice no change after a reboot or running /sbin/udevstart
Furthermore there is no usbFP device in /dev/ directory.
any hints?
(Anyway nothing I have done seems to prevent root access to the device
- which I think is a lucky thing-)
Thank you in advance,
Nicola
|
