Re: [Fx2lib-devel] Using FXLOAD with udev on SUSE

[Eric W. <er...@wi...>]

Eric Winsor wrote:
> Dennis Muhlestein wrote:
>   
>>> SUBSYSTEM==”usb”, ATTRS{idVendor}==”04b4”, ATTRS{idProduct}==”0082", 
>>> MODE="0666"
>>>
>>> Which lends be to believe the RUN command is not the issue.
>>>   
>>>
>>>     
>>>       
>> What does the kernel documentation say about udev rules format?  Perhaps 
>> there is a way to get a more verbose error message on exactly what the 
>> problem with your file is.
>>
>> -Dennis
>>
>>   
>>     
> I got it!  Notice above in the rule that the quotes are different in 
> MODE= from the previous quotes.  I got the original idea to use a udev 
> rule to call fxload from a blog found by googling fxload.  I copied and 
> pasted the rule from firefox in Windows XP to my running VMware SUSE.  
> The first quotes copied from the web browser are not the ASCII quote on 
> the keyboard.  Hence the rule was failing.  My later edits in VI are 
> ASCII quotes.  In an xtem and VI I can not tell the difference between 
> the quotes.  Only by seeing them in Thunderbird mail did I notice the 
> difference.  I fixed the quotes and the rule works fine.  Now to remove 
> the static reference to /proc/bus/usb/002/033 and put back in variable 
> references to the current usb device and all should be great.  I'll post 
> the full solution when done.
>
> Eric
>   
OK, here is a working udev rule for invoking fxload when a device is 
plugged in.

Rule:
SUBSYSTEM=="usb", ATTR{idVendor}=="04b4", ATTR{idProduct}=="0082", 
ACTION=="add", RUN+="/sbin/fxload -t fx2 -D $TEMPNODE -I 
/usr/share/RCU_02.hex"

The rule resides in the file /etc/udev/rules.d/10-evw.rules on by SUSE 
11 system.  The rule may have any name, but the rules.d directory is 
searched in sort order.  Hence I started the name with 10 to cause the 
rule to be invoked before the later default rules.

Initially I looked at /sys/bus/usb/devices then plugged my USB device in 
and looked again to see where my device connected.  My device was 
connected as 2-1 in the devices directory, so I issued udevinfo -a -p 
/sys/bus/usb/devices/2-1 to get the udev attributes that I could write 
my udev rule from.
The first three attribute matches in the rule come from the top of the 
udevinfo output.  Our device has just been added to the system, hence 
the ACTION=="add" attribute check.  Then the rule instructs udev to run 
fxload if the four attribute matches are true.  The $TEMPNODE variable 
references the new usb device.  This is cool because by using $TEMPNODE 
I do not need to have usbfs mounted as I do if I directly reference 
/proc/bus/usb/<bus number>/<device number>.  I was also having trouble 
dynamically determining the bus number and device number to reference in 
/proc/bus/usb.  These numbers will change depending on which usb port 
you plug into and how many time you plug and unplug the device. Device 
number increment every time a plug event occurs.

The device when plugged in will enumerate as VID, PID, then fxload will 
detach the device, program the device, and reattach / renumerate as new 
VID, new PID.  Hence the logical next rule in my udev rule file will be 
a rule matching the new VID, new PID and associate it to the device 
file(s) my host driver will interface through.

While developing the rule I used:
# udevadm control reload_rules
To reload the udev rule set between modifications to the rule file.
and
# udevadm test /sys/bus/usb/2-1 | head
To test the rule for errors.

Eric