Loading firmware

Loading firmware

[Jasem Mutlaq]

Hello,

I need to load firmware to a USB camera via fxload. The problem is that
fxload requires a path such as /dev/bus/usb/001/002 in order to load the
firmware. So I wrote a udev rules file to do just that, however, the only
useful variable I can obtain now is %k, and I get something in the form of
usbdev1.2_ep00 which I then need to parse in some regexp magic in order to
extract the bus and dev num in order to construct the full path. I used to
be able to pull devnum and busnum ($env{BUSNUM}) but not anymore (using
openSUSE 11). Now I have a loader script that parses %k and constructs the
path. But this is only a hack and not a real solution, is there a way to get
the full path so I can pass it to fxload without resorting to these
desperate measures? Appreciate your help.

-------------
Best Regards,
Jasem Mutlaq
Kuwait National Radio Observatory
Kuwait Science Club
http://www.astronomy.ksclub.org

Re: Loading firmware

[Dan Nicholson]

On Mon, Oct 13, 2008 at 3:17 PM, Jasem Mutlaq <mutlaqja@ikarustech.com> wrote:
> Hello,
>
> I need to load firmware to a USB camera via fxload. The problem is that
> fxload requires a path such as /dev/bus/usb/001/002 in order to load the
> firmware. So I wrote a udev rules file to do just that, however, the only
> useful variable I can obtain now is %k, and I get something in the form of
> usbdev1.2_ep00 which I then need to parse in some regexp magic in order to
> extract the bus and dev num in order to construct the full path. I used to
> be able to pull devnum and busnum ($env{BUSNUM}) but not anymore (using
> openSUSE 11). Now I have a loader script that parses %k and constructs the
> path. But this is only a hack and not a real solution, is there a way to get
> the full path so I can pass it to fxload without resorting to these
> desperate measures? Appreciate your help.

Does something like this help:

<some test to determine your device>, ACTION="add", RUN+="/sbin/fxload
 -D /dev/$name"

Where $name points to the device name and will be set earlier by the
default rules.

--
Dan

RE: Loading firmware

[Jasem Mutlaq]

> Does something like this help:
> 
> <some test to determine your device>, ACTION="add", RUN+="/sbin/fxload
>  -D /dev/$name"
> 
> Where $name points to the device name and will be set earlier by the
> default rules.

It didn't work. The $name that I get is in the form of usbdev1.8_ep00 still. However, I tried the following

BUS="usb", ACTION="add", <...etc...> , ENV{devpath}="$attr{busnum}/$attr{devnum}"
RUN+="/sbin/fxload -I /lib/firmware/foo.hex -D /dev/bus/usb/$env{devpath}"

Only that $devpath evaluates to 1/8 or 10/7, but the number must always be 3 digits with zeros filling the leading digits, e.g.

/dev/bus/usb/001/008 or /dev/bus/usb/010/007

I have no idea how to do this in the rules files without calling an external script.

Regards,
Jasem

Re: Loading firmware

[Kay Sievers]

On Tue, Oct 14, 2008 at 12:17 AM, Jasem Mutlaq <mutlaqja@ikarustech.com> wrote:
> I need to load firmware to a USB camera via fxload. The problem is that
> fxload requires a path such as /dev/bus/usb/001/002 in order to load the
> firmware. So I wrote a udev rules file to do just that, however, the only
> useful variable I can obtain now is %k, and I get something in the form of
> usbdev1.2_ep00

That's not a USB _device_, it's a (not interesting) USB endpoint.

> which I then need to parse in some regexp magic in order to
> extract the bus and dev num in order to construct the full path. I used to
> be able to pull devnum and busnum ($env{BUSNUM}) but not anymore (using
> openSUSE 11).

That still works.

> Now I have a loader script that parses %k and constructs the
> path. But this is only a hack and not a real solution, is there a way to get
> the full path so I can pass it to fxload without resorting to these
> desperate measures? Appreciate your help.

Why not just use $DEVNAME?
  RUN+="/sbin/fxload <firmware file option> -D $env{DEVNAME}"

Kay

RE: Loading firmware

[Jasem Mutlaq]

> That's not a USB _device_, it's a (not interesting) USB endpoint.
> 
> > which I then need to parse in some regexp magic in order to
> > extract the bus and dev num in order to construct the full path. I
> used to
> > be able to pull devnum and busnum ($env{BUSNUM}) but not anymore
> (using
> > openSUSE 11).
> 
> That still works.

I tried it on OpenSUSE 11 and it doesn't, $env{BUSNUM} and $env{DEVNUM} are empty strings, $env{DEVNAME} returns the USB endpoint which I can't pass to fxload.

> Why not just use $DEVNAME?
>   RUN+="/sbin/fxload <firmware file option> -D $env{DEVNAME}"

This is what I get:

run_program: '/sbin/fxload' (stderr) '/dev/usbdev1.24_ep82: No such device or address'
run_program: '/sbin/fxload' returned with status 255

Thus far, fxload only works if it is passed something in the form of /dev/bus/usb/XXX/YYY

Cheers,
Jasem

Re: Loading firmware

[Kay Sievers]

On Tue, Oct 14, 2008 at 7:24 PM, Jasem Mutlaq <mutlaqja@ikarustech.com> wrote:
>> That's not a USB _device_, it's a (not interesting) USB endpoint.
>>
>> > which I then need to parse in some regexp magic in order to
>> > extract the bus and dev num in order to construct the full path. I
>> used to
>> > be able to pull devnum and busnum ($env{BUSNUM}) but not anymore
>> (using
>> > openSUSE 11).
>>
>> That still works.
>
> I tried it on OpenSUSE 11 and it doesn't, $env{BUSNUM} and $env{DEVNUM} are empty strings, $env{DEVNAME} returns the USB endpoint which I can't pass to fxload.

Sure you can't. As said, you need a device, not an endpoint, these
values _do_ exist at the device event.

>> Why not just use $DEVNAME?
>>   RUN+="/sbin/fxload <firmware file option> -D $env{DEVNAME}"
>
> This is what I get:
>
> run_program: '/sbin/fxload' (stderr) '/dev/usbdev1.24_ep82: No such device or address'
> run_program: '/sbin/fxload' returned with status 255

That's expected behavior for endpoints.

> Thus far, fxload only works if it is passed something in the form of /dev/bus/usb/XXX/YYY

It should work with any usb device device node, forget the endpoints,
match on a usb device. You look at the wrong events, you get a bunch
of them on plugin, only one of them will be the one that works with
fxload, and definitely not the one with the *_ep*. The right one
should have: DEVTYPE=usb_device set.

Kay

Re: Loading firmware

[Dan Nicholson]

On Tue, Oct 14, 2008 at 10:46 AM, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Tue, Oct 14, 2008 at 7:24 PM, Jasem Mutlaq <mutlaqja@ikarustech.com> wrote:
>
>> Thus far, fxload only works if it is passed something in the form of /dev/bus/usb/XXX/YYY
>
> It should work with any usb device device node, forget the endpoints,
> match on a usb device. You look at the wrong events, you get a bunch
> of them on plugin, only one of them will be the one that works with
> fxload, and definitely not the one with the *_ep*. The right one
> should have: DEVTYPE=usb_device set.

For reference, look at the rule that actually creates the /dev/bus/usb links:

SUBSYSTEM="usb", ACTION="add", ENV{DEVTYPE}="usb_device",
NAME="bus/usb/$env{BUSNUM}/$env{DEVNUM}", MODE="0644"

To get some information about what's going on:

path=`udevadm info --query=path --name=/dev/bus/usb/$your/$node`
udevadm test $path
udevadm info --attribute-walk --path=$path

I suspect you'll end up with something like this (make sure it runs
somewhere after the above rule that sets the name):

SUBSYSTEM="usb", ACTION="add", ENV{DEVTYPE}="usb_device",
ATTR{idVendor}="xxxx", ATTR{idProduct}="yyyy", RUN+="/sbin/fxload -I
/lib/firmware/foo.hex -D $env{DEVNAME}"

--
Dan

RE: Loading firmware

[Jasem Mutlaq]

> SUBSYSTEM="usb", ACTION="add", ENV{DEVTYPE}="usb_device",
> NAME="bus/usb/$env{BUSNUM}/$env{DEVNUM}", MODE="0644"

Yes, this is exactly what I have in 50-udev-default.rules.

> I suspect you'll end up with something like this (make sure it runs
> somewhere after the above rule that sets the name):
> 
> SUBSYSTEM="usb", ACTION="add", ENV{DEVTYPE}="usb_device",
> ATTR{idVendor}="xxxx", ATTR{idProduct}="yyyy", RUN+="/sbin/fxload -I
> /lib/firmware/foo.hex -D $env{DEVNAME}"

I tried that, and now the rule wouldn't even apply. It seems that DEVTYPE="usb_device" is not handled correctly. If I remove this condition, the rule is applied. I have one file 99-sbig.rules which has the following:

SUBSYSTEM="usb", ACTION="add", SYSFS{idVendor}="0d97", SYSFS{idProduct}="0001", ENV{DEVTYPE}="usb_device", \
RUN+="/sbin/fxload -I /lib/firmware/sbigucam.hex -D $env{DEVNAME}"

I don't understand why DEVTYPE is not caught, I ran udev monitor and got the following when I plugged my USB cam:

---------------------------------
EVENT[1224070564.432382] add      /devices/pci0000:00/0000:00:07.2/usb1/1-1 (usb)
ACTION­d                                                                        
DEVPATH=/devices/pci0000:00/0000:00:07.2/usb1/1-1                                 
SUBSYSTEM=usb                                                                     
MAJOR\x189                                                                         
MINOR$                                                                          
DEVTYPE=usb_device                                                                
DEVICE=/proc/bus/usb/001/025                                                      
PRODUCTÙ7/1/1                                                                   
TYPE%5/255/255                                                                  
BUSNUM\01                                                                        
DEVNUM\x025                                                                        
SEQNUM\x1460                                                                       

UEVENT[1224070564.434702] add      /devices/pci0000:00/0000:00:07.2/usb1/1-1/usb_endpoint/usbdev1.25_ep00 (usb_endpoint)
ACTION­d                                                                                                              
DEVPATH=/devices/pci0000:00/0000:00:07.2/usb1/1-1/usb_endpoint/usbdev1.25_ep00                                          
SUBSYSTEM=usb_endpoint                                                                                                  
MAJOR%3                                                                                                               
MINOR=4                                                                                                                 
SEQNUM\x1461                                                                                                             

UEVENT[1224070564.435629] add      /devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0 (usb)
ACTION­d
DEVPATH=/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0
SUBSYSTEM=usb
DEVTYPE=usb_interface
DEVICE=/proc/bus/usb/001/025
PRODUCTÙ7/1/1
TYPE%5/255/255
INTERFACE%5/255/255
MODALIAS=usb:v0D97p0001d0001dcFFdscFFdpFFicFFiscFFipFF
SEQNUM\x1462

UDEV  [1224070564.443609] add      /devices/pci0000:00/0000:00:07.2/usb1/1-1/usb_endpoint/usbdev1.25_ep00 (
UDEV_LOG=7
ACTION­d
DEVPATH=/devices/pci0000:00/0000:00:07.2/usb1/1-1/usb_endpoint/usbdev1.25_ep00
SUBSYSTEM=usb_endpoint
MAJOR%3
MINOR=4
SEQNUM\x1461
UDEVD_EVENT=1
DEVNAME=/dev/usbdev1.25_ep00

UDEV  [1224070564.462839] add      /devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0 (usb)
UDEV_LOG=7
ACTION­d
DEVPATH=/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0
SUBSYSTEM=usb
DEVTYPE=usb_interface
DEVICE=/proc/bus/usb/001/025
PRODUCTÙ7/1/1
TYPE%5/255/255
INTERFACE%5/255/255
MODALIAS=usb:v0D97p0001d0001dcFFdscFFdpFFicFFiscFFipFF
SEQNUM\x1462
UDEVD_EVENT=1
---------------------------------------------------------------------

If I remove the ENV{DEVTYPE}="usb_device" from the rule, I can use $env{DEVICE} since it's the closest thing to what I need, albeit it's under /proc and that doesn't work, I need /dev/bus/usb/XXX/YYY. Of course, DEVNAME evaluates to /dev/usbdev1.25_ep00 which is useless.

At any rate, here is what I get in /var/log/messages

----------------------------------------------------------------------
Oct 15 14:36:04 linux-j3lx kernel: usb 1-1: new full speed USB device using uhci_hcd and address 25        
Oct 15 14:36:04 linux-j3lx kernel: usb 1-1: configuration #1 chosen from 1 choice                          
Oct 15 14:36:04 linux-j3lx kernel: usb 1-1: New USB device found, idVendor
97, idProduct\001            
Oct 15 14:36:04 linux-j3lx kernel: usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0       
Oct 15 14:36:04 linux-j3lx udevd[552]: msg_queue_insert: seq 1460 queued, 'add' 'usb'                      
Oct 15 14:36:04 linux-j3lx udevd[552]: udev_event_run: seq 1460 forked, pid [4658], 'add' 'usb', 0 seconds old                                                                                                        
Oct 15 14:36:04 linux-j3lx udevd[552]: msg_queue_insert: seq 1461 queued, 'add' 'usb_endpoint'             
Oct 15 14:36:04 linux-j3lx udevd[552]: msg_queue_insert: seq 1462 queued, 'add' 'usb'                      
Oct 15 14:36:04 linux-j3lx udevd-event[4658]: udev_rules_get_name: rule applied, '1-1' becomes 'bus/usb/001/025'                                                                                                      
Oct 15 14:36:04 linux-j3lx udevd-event[4658]: udev_db_get_device: no db file to read /dev/.udev/db/\x2fdevices\x2fpci0000:00\x2f0000:00:07.2\x2fusb1\x2f1-1: No such file or directory                                
Oct 15 14:36:04 linux-j3lx udevd-event[4658]: udev_node_add: creating device node '/dev/bus/usb/001/025', major\x189, minor$, mode\x0660, uid=0, gid=0                                                                
Oct 15 14:36:04 linux-j3lx udevd-event[4658]: udev_node_mknod: atomically replace '/dev/bus/usb/001/025'   
Oct 15 14:36:04 linux-j3lx udevd-event[4658]: udev_node_mknod: mknod(/dev/bus/usb/001/025.udev-tmp, 020660, 189, 24) failed: Operation not permitted                                                                  
Oct 15 14:36:04 linux-j3lx udevd-event[4658]: udev_event_run: seq 1460 finished with -1                    
Oct 15 14:36:04 linux-j3lx udevd[552]: udev_done: seq 1460, pid [4658] exit with 1, 0 seconds old          
Oct 15 14:36:04 linux-j3lx udevd[552]: udev_event_run: seq 1461 forked, pid [4659], 'add' 'usb_endpoint', 0 seconds old                                                                                               
Oct 15 14:36:04 linux-j3lx udevd-event[4659]: udev_rules_get_name: no node name set, will use kernel name 'usbdev1.25_ep00'                                                                                           
Oct 15 14:36:04 linux-j3lx udevd-event[4659]: udev_db_get_device: no db file to read /dev/.udev/db/\x2fdevices\x2fpci0000:00\x2f0000:00:07.2\x2fusb1\x2f1-1\x2fusb_endpoint\x2fusbdev1.25_ep00: No such file or directory                                                                                                        
Oct 15 14:36:04 linux-j3lx udevd-event[4659]: udev_node_add: creating device node '/dev/usbdev1.25_ep00', major%3, minor=4, mode\x0660, uid=0, gid=0                                                                 
Oct 15 14:36:04 linux-j3lx udevd-event[4659]: name_index: creating index: '/dev/.udev/names/usbdev1.25_ep00/\x2fdevices\x2fpci0000:00\x2f0000:00:07..2\x2fusb1\x2f1-1\x2fusb_endpoint\x2fusbdev1.25_ep00'              
Oct 15 14:36:04 linux-j3lx udevd-event[4660]: run_program: '/sbin/modprobe usb:v0D97p0001d0001dcFFdscFFdpFFicFFiscFFipFF'                                                                                             
Oct 15 14:36:04 linux-j3lx udevd-event[4659]: pass_env_to_socket: passed 272 bytes to socket '/org/freedesktop/hal/udev_event',                                                                                       
Oct 15 14:36:04 linux-j3lx udevd-event[4659]: pass_env_to_socket: passed 272 bytes to socket '@/org/kernel/udev/monitor',                                                                                             
Oct 15 14:36:04 linux-j3lx udevd-event[4659]: udev_event_run: seq 1461 finished with 0                     
Oct 15 14:36:04 linux-j3lx udevd[552]: udev_event_run: seq 1462 forked, pid [4660], 'add' 'usb', 0 seconds old                                                                                                        
Oct 15 14:36:04 linux-j3lx udevd[552]: udev_done: seq 1461, pid [4659] exit with 0, 0 seconds old          
Oct 15 14:36:04 linux-j3lx udevd-event[4660]: run_program: '/sbin/modprobe' (stderr) 'FATAL: Module usb:v0D97p0001d0001dcFFdscFFdpFFicFFiscFFipFF not found.'                                                         
Oct 15 14:36:04 linux-j3lx udevd-event[4660]: run_program: '/sbin/modprobe' returned with status 1         
Oct 15 14:36:04 linux-j3lx udevd-event[4660]: pass_env_to_socket: passed 335 bytes to socket '/org/freedesktop/hal/udev_event',                                                                                       
Oct 15 14:36:04 linux-j3lx udevd-event[4660]: pass_env_to_socket: passed 335 bytes to socket '@/org/kernel/udev/monitor',                                                                                             
Oct 15 14:36:04 linux-j3lx udevd-event[4660]: udev_event_run: seq 1462 finished with 0                     
Oct 15 14:36:04 linux-j3lx udevd[552]: udev_done: seq 1462, pid [4660] exit with 0, 0 seconds old   

---------------------------------------------------------------------------------------------------------

Notice that despite the default rule in 50-udev-default.rules (NAME="bus/usb/$env{BUSNUM}/$env{DEVNUM}"), the log says:

udev_rules_get_name: no node name set, will use kernel name 'usbdev1.25_ep00'

Btw, I get the same results in Fedora 9 and openSUSE 11, so it doesn't appear to be distro-specific.

Any insights appreciated!

Cheers,
Jasem

Re: Loading firmware

[Kay Sievers]

On Wed, Oct 15, 2008 at 2:05 PM, Jasem Mutlaq <mutlaqja@ikarustech.com> wrote:
>> SUBSYSTEM="usb", ACTION="add", ENV{DEVTYPE}="usb_device",
>> NAME="bus/usb/$env{BUSNUM}/$env{DEVNUM}", MODE="0644"
>
> Yes, this is exactly what I have in 50-udev-default.rules.
>
>> I suspect you'll end up with something like this (make sure it runs
>> somewhere after the above rule that sets the name):
>>
>> SUBSYSTEM="usb", ACTION="add", ENV{DEVTYPE}="usb_device",
>> ATTR{idVendor}="xxxx", ATTR{idProduct}="yyyy", RUN+="/sbin/fxload -I
>> /lib/firmware/foo.hex -D $env{DEVNAME}"
>
> I tried that, and now the rule wouldn't even apply. It seems that DEVTYPE="usb_device" is not handled correctly. If I remove this condition, the rule is applied. I have one file 99-sbig.rules which has the following:
>
> SUBSYSTEM="usb", ACTION="add", SYSFS{idVendor}="0d97", SYSFS{idProduct}="0001", ENV{DEVTYPE}="usb_device", \
> RUN+="/sbin/fxload -I /lib/firmware/sbigucam.hex -D $env{DEVNAME}"
>
> I don't understand why DEVTYPE is not caught, I ran udev monitor and got the following when I plugged my USB cam:
>
> ---------------------------------
> EVENT[1224070564.432382] add      /devices/pci0000:00/0000:00:07.2/usb1/1-1 (usb)

That reads "UDEV    [...] ..." since a long time, what old version of
udev you are running? It does not look like Fedora9 or openSUSE11.
Such old udev versions might not work with device nodes created by a
kernel bus-device.

Kay

RE: Loading firmware

[Jasem Mutlaq]

> That reads "UDEV    [...] ..." since a long time, what old version of
> udev you are running? It does not look like Fedora9 or openSUSE11.
> Such old udev versions might not work with device nodes created by a
> kernel bus-device.

linux-j3lx:/etc/udev/rules.d # uname -a
Linux linux-j3lx 2.6.25.5-1.1-default #1 SMP 2008-06-07 01:55:22 +0200 i686 i686 i386 GNU/Linux

linux-j3lx:/etc/udev/rules.d # udevd --version
120

linux-j3lx:/etc/udev/rules.d # rpm -qa udev
udev-120-13.1

linux-j3lx:/etc/udev/rules.d # cat /etc/SuSE-release
openSUSE 11.0 (i586)
VERSION = 11.0

Any more suggestions?

Cheers,
Jasem

Re: Loading firmware

[Kay Sievers]

On Wed, Oct 15, 2008 at 2:44 PM, Jasem Mutlaq <mutlaqja@ikarustech.com> wrote:
>> That reads "UDEV    [...] ..." since a long time, what old version of
>> udev you are running? It does not look like Fedora9 or openSUSE11.
>> Such old udev versions might not work with device nodes created by a
>> kernel bus-device.
>
> linux-j3lx:/etc/udev/rules.d # uname -a
> Linux linux-j3lx 2.6.25.5-1.1-default #1 SMP 2008-06-07 01:55:22 +0200 i686 i686 i386 GNU/Linux
>
> linux-j3lx:/etc/udev/rules.d # udevd --version
> 120
>
> linux-j3lx:/etc/udev/rules.d # rpm -qa udev
> udev-120-13.1
>
> linux-j3lx:/etc/udev/rules.d # cat /etc/SuSE-release
> openSUSE 11.0 (i586)
> VERSION = 11.0
>
> Any more suggestions?

I have no idea what's going wrong your box, but unless you find an
explanation for the following, I guess we can't really help from
remote.

On openSUSE 11 there is no output like you have, it's from a pretty
old version of udevmonitor
  EVENT[1224070564.432382] add
/devices/pci0000:00/0000:00:07.2/usb1/1-1 (usb)

On openSUSE 11 it always reads:
  UDEV  [1224076272.737777] add
/devices/pci0000:00/0000:00:1d.3/usb4/4-2 (usb)

And the usb device events looks like this, and always contain DEVNAME:
  UDEV  [1224076312.193348] add
/devices/pci0000:00/0000:00:1d.3/usb4/4-2 (usb)
  UDEV_LOG=3
  ACTION­d
  DEVPATH=/devices/pci0000:00/0000:00:1d.3/usb4/4-2
  SUBSYSTEM=usb
  MAJOR\x189
  MINOR87
  DEVTYPE=usb_device
  DRIVER=usb
  PRODUCTH3/2016/1
  TYPE=0/0/0
  BUSNUM\04
  DEVNUM\04
  SEQNUM\x1364
  UDEVD_EVENT=1
  DEVNAME=/dev/bus/usb/004/004

You could do:
  killall udevd
  /sbin/udevd --debug
and plug in your camera, and see if that tells something.

Here is says:
  [15889] udev_rules_get_name: rule applied, '4-2' becomes 'bus/usb/004/004'

Kay

RE: Loading firmware

[Jasem Mutlaq]

> I have no idea what's going wrong your box, but unless you find an
> explanation for the following, I guess we can't really help from
> remote.
> 
> On openSUSE 11 there is no output like you have, it's from a pretty
> old version of udevmonitor
>   EVENT[1224070564.432382] add
> /devices/pci0000:00/0000:00:07.2/usb1/1-1 (usb)
> 
> On openSUSE 11 it always reads:
>   UDEV  [1224076272.737777] add
> /devices/pci0000:00/0000:00:1d.3/usb4/4-2 (usb)

The problem has been resolved. I was running a few instances of major distributions (openSUSE, Fedora, Ubuntu..etc) under VMWare to insure that the camera installs and works correctly under all. So it seems that udev behaves differently under VMware? I'm not sure. But when I applied the rule in my laptop which runs a vanilla openSUSE 11, everything worked as expected. I was relying on virtualization to make my testing easier, and it backfired :-)

At any rate, thank you for the help and support!

Cheers,
Jasem