fx2lib-devel

[Fx2lib-devel] Using FXLOAD with udev on SUSE

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

Hi,

I'm trying to write a udev rule but I get the following error when I 
test it:
linux-b1xe:~ # udevadm test /sys/bus/usb/2-1

parse_file: reading '/etc/udev/rules.d/10-evw.rules' as rules file
add_to_rules: invalid rule '/etc/udev/rules.d/10-evw.rules:4'

The fist three lines of 10-evw.rules are comments, the fourth line is my 
rule and is (in one line):

RUN+="/sbin/fxload/ -t fx2 -D /proc/bus/usb/002/033 -I 
/usr/share/RCU_02.hex"
DRIVER==”usb”, RUN+="/sbin/fxload/ -t fx2 -D /proc/bus/usb/002/033 -I 
/usr/share/RCU_02.hex"

Querying the device to get my attributes gives me:

linux-b1xe:~ # udevinfo -a -p /sys/bus/usb/devices/2-1

Udevinfo starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

looking at device '/devices/pci0000:00/0000:00:11.0/0000:02:02.0/usb2/2-1':
KERNEL=="2-1"
SUBSYSTEM=="usb"
DRIVER=="usb"
ATTR{dev}=="189:129"
ATTR{configuration}==""
ATTR{bNumInterfaces}==" 1"
ATTR{bConfigurationValue}=="1"
ATTR{bmAttributes}=="80"
ATTR{bMaxPower}=="100mA"
ATTR{urbnum}=="6"
ATTR{idVendor}=="04b4"
ATTR{idProduct}=="0082"
ATTR{bcdDevice}=="0000"
ATTR{bDeviceClass}=="ff"
ATTR{bDeviceSubClass}=="ff"
ATTR{bDeviceProtocol}=="ff"
ATTR{bNumConfigurations}=="1"
ATTR{bMaxPacketSize0}=="64"
ATTR{speed}=="480"
ATTR{busnum}=="2"
ATTR{devnum}=="2"
ATTR{version}==" 2.00"
ATTR{maxchild}=="0"
ATTR{quirks}=="0x0"
ATTR{authorized}=="1"

looking at parent device 
'/devices/pci0000:00/0000:00:11.0/0000:02:02.0/usb2':
KERNELS=="usb2"
SUBSYSTEMS=="usb"
DRIVERS=="usb"
ATTRS{dev}=="189:128"
ATTRS{configuration}==""
ATTRS{bNumInterfaces}==" 1"
ATTRS{bConfigurationValue}=="1"
ATTRS{bmAttributes}=="e0"
ATTRS{bMaxPower}==" 0mA"
ATTRS{urbnum}=="49"
ATTRS{idVendor}=="1d6b"
ATTRS{idProduct}=="0002"
ATTRS{bcdDevice}=="0206"
ATTRS{bDeviceClass}=="09"
ATTRS{bDeviceSubClass}=="00"
ATTRS{bDeviceProtocol}=="01"
ATTRS{bNumConfigurations}=="1"
ATTRS{bMaxPacketSize0}=="64"
ATTRS{speed}=="480"
ATTRS{busnum}=="2"
ATTRS{devnum}=="1"
ATTRS{version}==" 2.00"
ATTRS{maxchild}=="6"
ATTRS{quirks}=="0x0"
ATTRS{authorized}=="1"
ATTRS{manufacturer}=="Linux 2.6.25.18-0.2-pae ehci_hcd"
ATTRS{product}=="EHCI Host Controller"
ATTRS{serial}=="0000:02:02.0"
ATTRS{authorized_default}=="1"

looking at parent device '/devices/pci0000:00/0000:00:11.0/0000:02:02.0':
KERNELS=="0000:02:02.0"
SUBSYSTEMS=="pci"
DRIVERS=="ehci_hcd"
ATTRS{vendor}=="0x15ad"
ATTRS{device}=="0x0770"
ATTRS{subsystem_vendor}=="0x15ad"
ATTRS{subsystem_device}=="0x0770"
ATTRS{class}=="0x0c0320"
ATTRS{irq}=="16"
ATTRS{local_cpus}=="ffffffff,ffffffff,ffffffff,ffffffff"
ATTRS{modalias}=="pci:v000015ADd00000770sv000015ADsd00000770bc0Csc03i20"
ATTRS{enable}=="1"
ATTRS{broken_parity_status}=="0"
ATTRS{msi_bus}==""

looking at parent device '/devices/pci0000:00/0000:00:11.0':
KERNELS=="0000:00:11.0"
SUBSYSTEMS=="pci"
DRIVERS==""
ATTRS{vendor}=="0x15ad"
ATTRS{device}=="0x0790"
ATTRS{subsystem_vendor}=="0x0000"
ATTRS{subsystem_device}=="0x0000"
ATTRS{class}=="0x060401"
ATTRS{irq}=="0"
ATTRS{local_cpus}=="ffffffff,ffffffff,ffffffff,ffffffff"
ATTRS{modalias}=="pci:v000015ADd00000790sv00000000sd00000000bc06sc04i01"
ATTRS{enable}=="1"
ATTRS{broken_parity_status}=="0"
ATTRS{msi_bus}=="1"

looking at parent device '/devices/pci0000:00':
KERNELS=="pci0000:00"
SUBSYSTEMS==""
DRIVERS==""


Can anyone see what I'm doing wrong in my rule or missing that I may 
need to do elsewhere?

Thanks,

Eric Winsor

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

[Dennis M. <de...@ub...>]

Eric Winsor wrote:
> Hi,
>
> I'm trying to write a udev rule but I get the following error when I 
> test it:
> linux-b1xe:~ # udevadm test /sys/bus/usb/2-1
>
> parse_file: reading '/etc/udev/rules.d/10-evw.rules' as rules file
> add_to_rules: invalid rule '/etc/udev/rules.d/10-evw.rules:4'
>
> The fist three lines of 10-evw.rules are comments, the fourth line is my 
> rule and is (in one line):
>
> RUN+="/sbin/fxload/ -t fx2 -D /proc/bus/usb/002/033 -I 
> /usr/share/RCU_02.hex"
> DRIVER==”usb”, RUN+="/sbin/fxload/ -t fx2 -D /proc/bus/usb/002/033 -I 
> /usr/share/RCU_02.hex"
>   
I don't use the RUN command in my udev rule.  I just use ATTRS and MODE 
to allow all users to use the device. 
SUBSYSTEM=="usb", ATTRS{idVendor}=="<my vendor id>", MODE="0666"
So Assuming your RUN command is not the problem, perhaps you need 
SUBSYSTEM instead of DRIVER.

As for the RUN command, is it /sbin/fxload/ with a trailing slash?

I'm working in Fedora though, I don't know if the UDEV rules have 
differences from platform to platform.

-Dennis

> Querying the device to get my attributes gives me:
>
> linux-b1xe:~ # udevinfo -a -p /sys/bus/usb/devices/2-1
>
> Udevinfo starts with the device specified by the devpath and then
> walks up the chain of parent devices. It prints for every device
> found, all possible attributes in the udev rules key format.
> A rule to match, can be composed by the attributes of the device
> and the attributes from one single parent device.
>
> looking at device '/devices/pci0000:00/0000:00:11.0/0000:02:02.0/usb2/2-1':
> KERNEL=="2-1"
> SUBSYSTEM=="usb"
> DRIVER=="usb"
> ATTR{dev}=="189:129"
> ATTR{configuration}==""
> ATTR{bNumInterfaces}==" 1"
> ATTR{bConfigurationValue}=="1"
> ATTR{bmAttributes}=="80"
> ATTR{bMaxPower}=="100mA"
> ATTR{urbnum}=="6"
> ATTR{idVendor}=="04b4"
> ATTR{idProduct}=="0082"
> ATTR{bcdDevice}=="0000"
> ATTR{bDeviceClass}=="ff"
> ATTR{bDeviceSubClass}=="ff"
> ATTR{bDeviceProtocol}=="ff"
> ATTR{bNumConfigurations}=="1"
> ATTR{bMaxPacketSize0}=="64"
> ATTR{speed}=="480"
> ATTR{busnum}=="2"
> ATTR{devnum}=="2"
> ATTR{version}==" 2.00"
> ATTR{maxchild}=="0"
> ATTR{quirks}=="0x0"
> ATTR{authorized}=="1"
>
> looking at parent device 
> '/devices/pci0000:00/0000:00:11.0/0000:02:02.0/usb2':
> KERNELS=="usb2"
> SUBSYSTEMS=="usb"
> DRIVERS=="usb"
> ATTRS{dev}=="189:128"
> ATTRS{configuration}==""
> ATTRS{bNumInterfaces}==" 1"
> ATTRS{bConfigurationValue}=="1"
> ATTRS{bmAttributes}=="e0"
> ATTRS{bMaxPower}==" 0mA"
> ATTRS{urbnum}=="49"
> ATTRS{idVendor}=="1d6b"
> ATTRS{idProduct}=="0002"
> ATTRS{bcdDevice}=="0206"
> ATTRS{bDeviceClass}=="09"
> ATTRS{bDeviceSubClass}=="00"
> ATTRS{bDeviceProtocol}=="01"
> ATTRS{bNumConfigurations}=="1"
> ATTRS{bMaxPacketSize0}=="64"
> ATTRS{speed}=="480"
> ATTRS{busnum}=="2"
> ATTRS{devnum}=="1"
> ATTRS{version}==" 2.00"
> ATTRS{maxchild}=="6"
> ATTRS{quirks}=="0x0"
> ATTRS{authorized}=="1"
> ATTRS{manufacturer}=="Linux 2.6.25.18-0.2-pae ehci_hcd"
> ATTRS{product}=="EHCI Host Controller"
> ATTRS{serial}=="0000:02:02.0"
> ATTRS{authorized_default}=="1"
>
> looking at parent device '/devices/pci0000:00/0000:00:11.0/0000:02:02.0':
> KERNELS=="0000:02:02.0"
> SUBSYSTEMS=="pci"
> DRIVERS=="ehci_hcd"
> ATTRS{vendor}=="0x15ad"
> ATTRS{device}=="0x0770"
> ATTRS{subsystem_vendor}=="0x15ad"
> ATTRS{subsystem_device}=="0x0770"
> ATTRS{class}=="0x0c0320"
> ATTRS{irq}=="16"
> ATTRS{local_cpus}=="ffffffff,ffffffff,ffffffff,ffffffff"
> ATTRS{modalias}=="pci:v000015ADd00000770sv000015ADsd00000770bc0Csc03i20"
> ATTRS{enable}=="1"
> ATTRS{broken_parity_status}=="0"
> ATTRS{msi_bus}==""
>
> looking at parent device '/devices/pci0000:00/0000:00:11.0':
> KERNELS=="0000:00:11.0"
> SUBSYSTEMS=="pci"
> DRIVERS==""
> ATTRS{vendor}=="0x15ad"
> ATTRS{device}=="0x0790"
> ATTRS{subsystem_vendor}=="0x0000"
> ATTRS{subsystem_device}=="0x0000"
> ATTRS{class}=="0x060401"
> ATTRS{irq}=="0"
> ATTRS{local_cpus}=="ffffffff,ffffffff,ffffffff,ffffffff"
> ATTRS{modalias}=="pci:v000015ADd00000790sv00000000sd00000000bc06sc04i01"
> ATTRS{enable}=="1"
> ATTRS{broken_parity_status}=="0"
> ATTRS{msi_bus}=="1"
>
> looking at parent device '/devices/pci0000:00':
> KERNELS=="pci0000:00"
> SUBSYSTEMS==""
> DRIVERS==""
>
>
> Can anyone see what I'm doing wrong in my rule or missing that I may 
> need to do elsewhere?
>
> Thanks,
>
> Eric Winsor
>
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Fx2lib-devel mailing list
> Fx2...@li...
> https://lists.sourceforge.net/lists/listinfo/fx2lib-devel
>   

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

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

Dennis Muhlestein wrote:
> Eric Winsor wrote:
>   
>> Hi,
>>
>> I'm trying to write a udev rule but I get the following error when I 
>> test it:
>> linux-b1xe:~ # udevadm test /sys/bus/usb/2-1
>>
>> parse_file: reading '/etc/udev/rules.d/10-evw.rules' as rules file
>> add_to_rules: invalid rule '/etc/udev/rules.d/10-evw.rules:4'
>>
>> The fist three lines of 10-evw.rules are comments, the fourth line is my 
>> rule and is (in one line):
>>
>> RUN+="/sbin/fxload/ -t fx2 -D /proc/bus/usb/002/033 -I 
>> /usr/share/RCU_02.hex"
>> DRIVER==”usb”, RUN+="/sbin/fxload/ -t fx2 -D /proc/bus/usb/002/033 -I 
>> /usr/share/RCU_02.hex"
>>   
>>     
> I don't use the RUN command in my udev rule.  I just use ATTRS and MODE 
> to allow all users to use the device. 
> SUBSYSTEM=="usb", ATTRS{idVendor}=="<my vendor id>", MODE="0666"
> So Assuming your RUN command is not the problem, perhaps you need 
> SUBSYSTEM instead of DRIVER.
>
> As for the RUN command, is it /sbin/fxload/ with a trailing slash?
>
> I'm working in Fedora though, I don't know if the UDEV rules have 
> differences from platform to platform.
>
> -Dennis
>   
I hadn't noticed the trailing slash, thanks, that would have been a 
problem later, but not the source of my problem currently.  Here is my 
rule at the moment:

SUBSYSTEM==”usb”, ATTRS{idVendor}==”04b4”, ATTRS{idProduct}==”0082", 
RUN+="/sbin/fxload -t fx2 -D /proc/bus/usb/002/004 -I /usr/share/RCU_02.hex"

Changing to SUBSYSTEM did not have an effect.  I also tried the ATTRS as 
ATTR to match the udevinfo query.  I'm trying to get fxload to load my 
firmware to my development board.  Hence I want udev to catch the VID 
and PID then run fxload.  I have read a few complaints through google 
searches that the SUSE udev act different, but no one explains how it is 
different.  The SUSE documentation points to the kernel.org udev 
documentation, so things should not be different.

For grins I also tried:

SUBSYSTEM==”usb”, ATTRS{idVendor}==”04b4”, ATTRS{idProduct}==”0082", 
MODE="0666"

Which lends be to believe the RUN command is not the issue.

Eric
>> Querying the device to get my attributes gives me:
>>
>> linux-b1xe:~ # udevinfo -a -p /sys/bus/usb/devices/2-1
>>
>> Udevinfo starts with the device specified by the devpath and then
>> walks up the chain of parent devices. It prints for every device
>> found, all possible attributes in the udev rules key format.
>> A rule to match, can be composed by the attributes of the device
>> and the attributes from one single parent device.
>>
>> looking at device '/devices/pci0000:00/0000:00:11.0/0000:02:02.0/usb2/2-1':
>> KERNEL=="2-1"
>> SUBSYSTEM=="usb"
>> DRIVER=="usb"
>> ATTR{dev}=="189:129"
>> ATTR{configuration}==""
>> ATTR{bNumInterfaces}==" 1"
>> ATTR{bConfigurationValue}=="1"
>> ATTR{bmAttributes}=="80"
>> ATTR{bMaxPower}=="100mA"
>> ATTR{urbnum}=="6"
>> ATTR{idVendor}=="04b4"
>> ATTR{idProduct}=="0082"
>> ATTR{bcdDevice}=="0000"
>> ATTR{bDeviceClass}=="ff"
>> ATTR{bDeviceSubClass}=="ff"
>> ATTR{bDeviceProtocol}=="ff"
>> ATTR{bNumConfigurations}=="1"
>> ATTR{bMaxPacketSize0}=="64"
>> ATTR{speed}=="480"
>> ATTR{busnum}=="2"
>> ATTR{devnum}=="2"
>> ATTR{version}==" 2.00"
>> ATTR{maxchild}=="0"
>> ATTR{quirks}=="0x0"
>> ATTR{authorized}=="1"
>>
>> looking at parent device 
>> '/devices/pci0000:00/0000:00:11.0/0000:02:02.0/usb2':
>> KERNELS=="usb2"
>> SUBSYSTEMS=="usb"
>> DRIVERS=="usb"
>> ATTRS{dev}=="189:128"
>> ATTRS{configuration}==""
>> ATTRS{bNumInterfaces}==" 1"
>> ATTRS{bConfigurationValue}=="1"
>> ATTRS{bmAttributes}=="e0"
>> ATTRS{bMaxPower}==" 0mA"
>> ATTRS{urbnum}=="49"
>> ATTRS{idVendor}=="1d6b"
>> ATTRS{idProduct}=="0002"
>> ATTRS{bcdDevice}=="0206"
>> ATTRS{bDeviceClass}=="09"
>> ATTRS{bDeviceSubClass}=="00"
>> ATTRS{bDeviceProtocol}=="01"
>> ATTRS{bNumConfigurations}=="1"
>> ATTRS{bMaxPacketSize0}=="64"
>> ATTRS{speed}=="480"
>> ATTRS{busnum}=="2"
>> ATTRS{devnum}=="1"
>> ATTRS{version}==" 2.00"
>> ATTRS{maxchild}=="6"
>> ATTRS{quirks}=="0x0"
>> ATTRS{authorized}=="1"
>> ATTRS{manufacturer}=="Linux 2.6.25.18-0.2-pae ehci_hcd"
>> ATTRS{product}=="EHCI Host Controller"
>> ATTRS{serial}=="0000:02:02.0"
>> ATTRS{authorized_default}=="1"
>>
>> looking at parent device '/devices/pci0000:00/0000:00:11.0/0000:02:02.0':
>> KERNELS=="0000:02:02.0"
>> SUBSYSTEMS=="pci"
>> DRIVERS=="ehci_hcd"
>> ATTRS{vendor}=="0x15ad"
>> ATTRS{device}=="0x0770"
>> ATTRS{subsystem_vendor}=="0x15ad"
>> ATTRS{subsystem_device}=="0x0770"
>> ATTRS{class}=="0x0c0320"
>> ATTRS{irq}=="16"
>> ATTRS{local_cpus}=="ffffffff,ffffffff,ffffffff,ffffffff"
>> ATTRS{modalias}=="pci:v000015ADd00000770sv000015ADsd00000770bc0Csc03i20"
>> ATTRS{enable}=="1"
>> ATTRS{broken_parity_status}=="0"
>> ATTRS{msi_bus}==""
>>
>> looking at parent device '/devices/pci0000:00/0000:00:11.0':
>> KERNELS=="0000:00:11.0"
>> SUBSYSTEMS=="pci"
>> DRIVERS==""
>> ATTRS{vendor}=="0x15ad"
>> ATTRS{device}=="0x0790"
>> ATTRS{subsystem_vendor}=="0x0000"
>> ATTRS{subsystem_device}=="0x0000"
>> ATTRS{class}=="0x060401"
>> ATTRS{irq}=="0"
>> ATTRS{local_cpus}=="ffffffff,ffffffff,ffffffff,ffffffff"
>> ATTRS{modalias}=="pci:v000015ADd00000790sv00000000sd00000000bc06sc04i01"
>> ATTRS{enable}=="1"
>> ATTRS{broken_parity_status}=="0"
>> ATTRS{msi_bus}=="1"
>>
>> looking at parent device '/devices/pci0000:00':
>> KERNELS=="pci0000:00"
>> SUBSYSTEMS==""
>> DRIVERS==""
>>
>>
>> Can anyone see what I'm doing wrong in my rule or missing that I may 
>> need to do elsewhere?
>>
>> Thanks,
>>
>> Eric Winsor
>>
>>
>> ------------------------------------------------------------------------------
>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
>> -Strategies to boost innovation and cut costs with open source participation
>> -Receive a $600 discount off the registration fee with the source code: SFAD
>> http://p.sf.net/sfu/XcvMzF8H
>> _______________________________________________
>> Fx2lib-devel mailing list
>> Fx2...@li...
>> https://lists.sourceforge.net/lists/listinfo/fx2lib-devel
>>   
>>     
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Fx2lib-devel mailing list
> Fx2...@li...
> https://lists.sourceforge.net/lists/listinfo/fx2lib-devel
>   

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

[Dennis M. <de...@ub...>]

>
> 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

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

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

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

> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Fx2lib-devel mailing list
> Fx2...@li...
> https://lists.sourceforge.net/lists/listinfo/fx2lib-devel
>   

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

[Fx2lib-devel] bulkloop example crashing FX2?

[Aric M. <as...@pu...>]

Hi everyone,

I'm trying out the "bulkloop" example in fx2lib and it seems that the 
FX2 is dying(in some manner) when EA is set to 1 to enable interrupts.  
Has anyone tried this example recently?  I'm using a CY3681 demo board, 
fwiw...  No additional hw attached(atm).  Device becomes unresponsive 
once EA is set to 1.

BTW, thanks a lot for making this lib! :)

Regards,
ASM

Re: [Fx2lib-devel] bulkloop example crashing FX2?

[Dennis M. <de...@ub...>]

Aric Marheine wrote:
> Hi everyone,
>
> I'm trying out the "bulkloop" example in fx2lib and it seems that the 
> FX2 is dying(in some manner) when EA is set to 1 to enable interrupts.  
> Has anyone tried this example recently?  I'm using a CY3681 demo board, 
> fwiw...  No additional hw attached(atm).  Device becomes unresponsive 
> once EA is set to 1.
>
> BTW, thanks a lot for making this lib! :)
>   

I just tested it out again on my CY3684/CY3674 board.  Is there a 
different chip on the Cy3681 board?

If you have the serial console set up, you can see what is going on by 
following the printf statements.

The example certainly won't work with EA=0 though because you have to 
have interrupts enabled to
handle the vendor commands.

-Dennis

Re: [Fx2lib-devel] bulkloop example crashing FX2?

[Aric M. <as...@pu...>]

Dennis Muhlestein wrote:
> I just tested it out again on my CY3684/CY3674 board.  Is there a 
> different chip on the Cy3681 board?
>
> If you have the serial console set up, you can see what is going on by 
> following the printf statements.
>
> The example certainly won't work with EA=0 though because you have to 
> have interrupts enabled to
> handle the vendor commands.
>
> -Dennis
>   
Hi Dennis,

The FX2 on this board is a CY7C68013-128AC, not sure what chip you have 
on your boards.  I do indeed have SIO set up.  As mentioned earlier, as 
soon as the interrupts are enabled, nothing more appears to happen.  I 
can printf() all the way up to that point then nothing more.  I've tried 
adding simple printfs() to each of the ISRs that are in the example to 
see if one was being called continuously or something but none of them 
do seem to be.

My compiler setup seems ok as I can compile and test programs like 
"lights" and my own app which does some port I/O.  Could it be that some 
interrupt vector is being called which doesn't have an ISR in the 
example?  I don't understand why it would work for you(and others, I 
guess) but not me.  I think I'll go over all the interrupts and be sure 
that no others are being enabled which shouldn't be.

Anyway, I appreciate your help and any further suggestions you may have!

Regards,
ASM

Re: [Fx2lib-devel] bulkloop example crashing FX2?

[Aric M. <as...@pu...>]

One odd thing I just noticed was that the behavior of the LEDs seems to 
be inverted on my board.  dXon()/dXoff() do the opposite, yet they do 
function just fine.

Aric Marheine wrote:
> Dennis Muhlestein wrote:
>   
>> I just tested it out again on my CY3684/CY3674 board.  Is there a 
>> different chip on the Cy3681 board?
>>
>> If you have the serial console set up, you can see what is going on by 
>> following the printf statements.
>>
>> The example certainly won't work with EA=0 though because you have to 
>> have interrupts enabled to
>> handle the vendor commands.
>>
>> -Dennis
>>   
>>     
> Hi Dennis,
>
> The FX2 on this board is a CY7C68013-128AC, not sure what chip you have 
> on your boards.  I do indeed have SIO set up.  As mentioned earlier, as 
> soon as the interrupts are enabled, nothing more appears to happen.  I 
> can printf() all the way up to that point then nothing more.  I've tried 
> adding simple printfs() to each of the ISRs that are in the example to 
> see if one was being called continuously or something but none of them 
> do seem to be.
>
> My compiler setup seems ok as I can compile and test programs like 
> "lights" and my own app which does some port I/O.  Could it be that some 
> interrupt vector is being called which doesn't have an ISR in the 
> example?  I don't understand why it would work for you(and others, I 
> guess) but not me.  I think I'll go over all the interrupts and be sure 
> that no others are being enabled which shouldn't be.
>
> Anyway, I appreciate your help and any further suggestions you may have!
>
> Regards,
> ASM
>
>
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Fx2lib-devel mailing list
> Fx2...@li...
> https://lists.sourceforge.net/lists/listinfo/fx2lib-devel
>
>
>   

Re: [Fx2lib-devel] bulkloop example crashing FX2?

[Dennis M. <de...@ub...>]

Aric Marheine wrote:
> One odd thing I just noticed was that the behavior of the LEDs seems to 
> be inverted on my board.  dXon()/dXoff() do the opposite, yet they do 
> function just fine.
>   

Well, the board number you provided is indeed different than mine so 
that doesn't surprise me.  Interesting that the memory addresses Cypress 
used for the lights are still the same, even if they tied them to the 
different lights in a different order.

Does the i2c example work?

-Dennis

[Fx2lib-devel] "lights" fix for CY3681

[Aric M. <as...@pu...>]

These are the addresses for the lights on the CY3681 board:

volatile xdata at 0x8000 BYTE D2ON;
volatile xdata at 0x8100 BYTE D2OFF;
volatile xdata at 0x9000 BYTE D3ON;
volatile xdata at 0x9100 BYTE D3OFF;
volatile xdata at 0xA000 BYTE D4ON;
volatile xdata at 0xA100 BYTE D4OFF;
volatile xdata at 0xB000 BYTE D5ON;
volatile xdata at 0xB100 BYTE D5OFF;

Re: [Fx2lib-devel] "lights" fix for CY3681

[Dennis M. <de...@ub...>]

Resurrecting old thread.  I added these memory addresses to lights.h.  
You can enable them by defining FX1 before you include this header.

example: SDCCFLAGS=-DFX1 make
(assuming your make file adds the SDCCFLAGS to sdcc options).

Anyway, there are a few other fx1/fx2 differences but this is a start to 
making the library work for both versions.

Aric Marheine wrote:
> These are the addresses for the lights on the CY3681 board:
>
> volatile xdata at 0x8000 BYTE D2ON;
> volatile xdata at 0x8100 BYTE D2OFF;
> volatile xdata at 0x9000 BYTE D3ON;
> volatile xdata at 0x9100 BYTE D3OFF;
> volatile xdata at 0xA000 BYTE D4ON;
> volatile xdata at 0xA100 BYTE D4OFF;
> volatile xdata at 0xB000 BYTE D5ON;
> volatile xdata at 0xB100 BYTE D5OFF;
>   

[Fx2lib-devel] fx1lib - cypress license issues

[Steve C. <nos...@ya...>]

Hi,

I would like to extend fx2lib to work with the original, full speed ezusb system. I have some cheap keyspan serial adapters to play with.

My question is has Cypress allowed the use of its header files? I don't know why they would not, but who can guess with lawyers? I found the cypress headers fixed by some kid in Spain, to work with the SDCC syntax instead of Keil. They still have the cypress copyright, but is that ok for using in fx2lib?

This fx.h file has been maybe manually converted like the fx2regs.h file in fx2lib. Is search and replace sufficient to establish a new copyright like claimed at the head of fx2regs.h? This whole licensing of basically names and a (fixed by hardware) address, is really stretching the definition of copyright. However, IANAL, so how has Ubixum decided on this?

The only questionable licensing issues are the few Cypress headers defining register names and possibly a header defining structures that match USB defined fields.

Regards, Steve


      

Re: [Fx2lib-devel] fx1lib - cypress license issues

[Dennis M. <de...@ub...>]

Steve Calfee wrote:
> Hi,
>
> I would like to extend fx2lib to work with the original, full speed ezusb system. I have some cheap keyspan serial adapters to play with.
>   
fx2lib should already work with full speed USB systems.  If you know of 
any area that doesn't work, please let us know.  If you #define FX2 
before including headers, then FX1 code is enabled.  So far, the only 
thing that is changes is the address of the debug LEDs on the dev 
boards.  I don't know of any other changes that need to be made at this 
point though but I don't have an FX1 development board.

> My question is has Cypress allowed the use of its header files? I don't know why they would not, but who can guess with lawyers? I found the cypress headers fixed by some kid in Spain, to work with the SDCC syntax instead of Keil. They still have the cypress copyright, but is that ok for using in fx2lib?
>   
You can use any header file you want as long as it is compatible with 
SDCC.  The fx2 library does internally depend on the supplied fx2regs.h 
though.

> This fx.h file has been maybe manually converted like the fx2regs.h file in fx2lib. Is search and replace sufficient to establish a new copyright like claimed at the head of fx2regs.h? This whole licensing of basically names and a (fixed by hardware) address, is really stretching the definition of copyright. However, IANAL, so how has Ubixum decided on this?
>   
The register names are publicly available information available in the 
EZ-USB TRM.  Whether we searched/replaced or recoded the entire file by 
hand, we would have come up with the same header file for SDCC.  The 
Cypress license allows modification of their files for use with their 
chips and fx2lib is only useful for their products.
> The only questionable licensing issues are the few Cypress headers defining register names and possibly a header defining structures that match USB defined fields.
>   
USB defined fields are open standards that anyone can implement.  You 
can get the spec right from www.usb.org.

-Dennis

Re: [Fx2lib-devel] fx1lib - cypress license issues

[Dennis M. <de...@ub...>]

> fx2lib should already work with full speed USB systems.  If you know of 
> any area that doesn't work, please let us know.  If you #define FX2 
>
I typod that:

#define FX1 before including the header files to enable FX1 differences.

-Dennis

Re: [Fx2lib-devel] fx1lib - cypress license issues

[Steve C. <nos...@ya...>]

 On Mon, 11/23/09, Dennis Muhlestein <de...@ub...> wrote:

> From: Dennis Muhlestein <de...@ub...>
> Subject: Re: [Fx2lib-devel] fx1lib - cypress license issues
> To: "fx2lib developer mailing list" <fx2...@li...>
> Date: Monday, November 23, 2009, 8:30 AM
> 
> > fx2lib should already work with full speed USB
> systems.  If you know of 
> > any area that doesn't work, please let us know. 
> If you #define FX2 
> >
> I typod that:
> 
> #define FX1 before including the header files to enable FX1
> differences.
> 
> -Dennis
> 
> 
Hi Dennis, I wondered about why FX2. I guess I assumed that all the fx1 registers were in different places than the fx2, certainly the endpoints are, so I assumed we would need different headers. 

Anyway, I will try this and report back in a few days.

Regards, Steve


      

Re: [Fx2lib-devel] fx1lib - cypress license issues

[Dennis M. <de...@ub...>]

> Hi Dennis, I wondered about why FX2. I guess I assumed that all the fx1 registers were in different places than the fx2, certainly the endpoints are, so I assumed we would need different headers. 
>
> Anyway, I will try this and report back in a few days.
>
>   
Feel free to send any contributions/patches. 

-Dennis

Re: [Fx2lib-devel] fx1lib - cypress license issues

[Steve C. <nos...@ya...>]

--- On Mon, 11/23/09, Dennis Muhlestein <de...@ub...> wrote:

> From: Dennis Muhlestein <de...@ub...>
> Subject: Re: [Fx2lib-devel] fx1lib - cypress license issues
> To: "fx2lib developer mailing list" <fx2...@li...>
> Date: Monday, November 23, 2009, 8:27 AM
> 
> 
> Steve Calfee wrote:
> > Hi,
> >
> > I would like to extend fx2lib to work with the
> original, full speed ezusb system. I have some cheap keyspan
> serial adapters to play with.
> >   
> fx2lib should already work with full speed USB
> systems.  If you know of 
> any area that doesn't work, please let us know.  If
> you #define FX2 
> before including headers, then FX1 code is enabled. 
> So far, the only 
> thing that is changes is the address of the debug LEDs on
> the dev 
> boards.  I don't know of any other changes that need
> to be made at this 
> point though but I don't have an FX1 development board.
>

Ok, after looking at the code, the only thing that changes with fx1 being defined is the few debug LEDs, on a board I don't have.

There are many more changes in the registers etc. I will build the header files from the Spanish files and you can include them in fx2lib. I will not ask any more legal questions, and will only add essential definitions that must match the actual hardware for the fx1.

I really recommend either finding on the net or going to Fry's and finding a keyspan serial adapter that uses a fx1/ezusb. It is the lowest cost hardware to really test or work a full speed usb.




      

Re: [Fx2lib-devel] bulkloop example crashing FX2?

[Aric M. <as...@pu...>]

The problem comes down to the fact that the FX2 only has 8KByte RAM, and 
the FX2LP(which you have) has 16KByte RAM.  So I've got it working as 
long as I tweek the settings in the Makefile and keep things small.

A bit of a noob question: How can I make use of the external RAM to 
overcome this shortage?  I'm kind of at a loss as to the command line 
options to use with SDCC in order to describe my hardware.  My board 
currently has 0x0000-0x1FFF mapped to internal RAM and 0x2000-0xFFFF 
mapped to external RAM.
If I have:
CC = sdcc -mmcs51 --code-size 0x1800 --xram-loc 0x2000 \
     -Wl"-b DSCR_AREA = 0x1800" \
     -Wl"-b INT2JT = 0x1A00"

Then everything works fine, but that gives me little space for code.  
How do I change this to put my code/data into the external RAM and 
execute it from there?

Many thanks,
ASM

Re: [Fx2lib-devel] bulkloop example crashing FX2?

[Dennis M. <de...@ub...>]

Aric Marheine wrote:
> The problem comes down to the fact that the FX2 only has 8KByte RAM, and 
> the FX2LP(which you have) has 16KByte RAM.  So I've got it working as 
> long as I tweek the settings in the Makefile and keep things small.
>
> A bit of a noob question: How can I make use of the external RAM to 
> overcome this shortage?  I'm kind of at a loss as to the command line 
> options to use with SDCC in order to describe my hardware.  My board 
> currently has 0x0000-0x1FFF mapped to internal RAM and 0x2000-0xFFFF 
> mapped to external RAM.
> If I have:
> CC = sdcc -mmcs51 --code-size 0x1800 --xram-loc 0x2000 \
>      -Wl"-b DSCR_AREA = 0x1800" \
>      -Wl"-b INT2JT = 0x1A00"
>
> Then everything works fine, but that gives me little space for code.  
> How do I change this to put my code/data into the external RAM and 
> execute it from there?
>   
I try to create a firmware small enough to fit in the ram on the chip.
The development board has the nice 0x2000-0xffff area memory that you 
can stick a lot of stuff in, but you can then never run your firmware on 
the same chip on a real PCB. (Because it likely won't have the same 
external memory.)  Your approach so far is exactly the way I do it: 
--xram-loc --xram-size, --code-size etc.

Back to your question though, you might try the --codeseg option or the 
codeseg #pragma and then use the linker to place that segment at a 
certain memory location (same as you do with INT2JT).

Glad you found the issue.

-Dennis

Re: [Fx2lib-devel] bulkloop example crashing FX2?

[Dennis M. <de...@ub...>]

Aric Marheine wrote:
> Dennis Muhlestein wrote:
>   
>> I just tested it out again on my CY3684/CY3674 board.  Is there a 
>> different chip on the Cy3681 board?
>>
>> If you have the serial console set up, you can see what is going on by 
>> following the printf statements.
>>
>> The example certainly won't work with EA=0 though because you have to 
>> have interrupts enabled to
>> handle the vendor commands.
>>
>> -Dennis
>>   
>>     
> Hi Dennis,
>
> The FX2 on this board is a CY7C68013-128AC, not sure what chip you have 
> on your boards.  I do indeed have SIO set up.  As mentioned earlier, as 
> soon as the interrupts are enabled, nothing more appears to happen.  I 
> can printf() all the way up to that point then nothing more.  I've tried 
> adding simple printfs() to each of the ISRs that are in the example to 
> see if one was being called continuously or something but none of them 
> do seem to be.
>   
I have the CYC68013A-128AXC.  You might want to check the Cypress site 
and see if there are any subtle differences.  There could for instance 
be a slight register name or location mismatch between different chip 
versions.  I know there are some differences between the FX and FX2 
chips but I don't know which model numbers fall under which category.

> My compiler setup seems ok as I can compile and test programs like 
> "lights" and my own app which does some port I/O.  Could it be that some 
> interrupt vector is being called which doesn't have an ISR in the 
> example?  I don't understand why it would work for you(and others, I 
> guess) but not me.  I think I'll go over all the interrupts and be sure 
> that no others are being enabled which shouldn't be.
>   
That will indeed cause problems if you have an interrupt firing but 
don't clear it (it'll go in a loop and pretty much nothing else will 
execute.)
printf is a bad thing to put in the interrupt routines though.  I prefer 
to test each one with a light instead.

If you narrow it down to something that causes your program to break, 
you could send a test case that I can check on my board.  It would be 
nice to
have the library be smart enough to work across more than my variant of 
the Cypress chip if that is the problem.

-Dennis