List Info

Thread: Re: sierra wireless compass 597 aircard (Was: Documentation)




Re: sierra wireless compass 597 aircard (Was: Documentation)
user name
2008-05-02 19:32:40
Steve Clark wrote: >>> Is there any detailed documentation on the FreeBSD usb device driver >>> api? This chapter helped me a lot to understand how this all works: http://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/usb.html > I sort of have it working by hacking ubsa.c to look for the sierra > vendor id and product id of 0xfff in > the usb_match function and return match. Then in the usb_attach code I > look again for the vendor and > product id of 0xfff and then send the control message to put it in modem > mode. > if ( uaa->vendor == USB_VENDOR_SIERRA && uaa->product == 0xfff ) It maybe a good idea to add 0xFFF to the usbdevs. Does the "umass" driver attach to the 0xFFF device? I would recommend adding this as a quirk to umass.c then. There are patches attached (ubsa.c_patch, umass_c.patch, usbdevs.patch) I am using to kill the "zeroconf" CD on the UMTS. They do not always work - i.e. umass_attach does not wait until the device is really detached. But setting USB_DEBUG helps > { > ubsa_request_real( sc, 0x0b, 1, 0x40 ); > ucom->sc_dying = 1; > goto error; > } > This puts in modem mode with product id of 0x0023 which i have plugged > into usbdevs and also put in ubsa.c > so now I get a ucom device and can successfully run ppp. The problem I > am running into now is sometime after > it remove the device I will get a page fault panic in the kernel. What kind of panic is this? > I think it is related to the sending the > control_message - something is not cleaned up when I "goto error" in the > USB_ATTACH function. > http://www.freebsd.org/cgi/query-pr.cgi?pr=121755 There are two patches, one to ohci_pci.c, the other to usb_subr.c. One of them is not correct - after kldunloading the module you may run into problems. But it makes everyday life easier - at least you can remove the card and re-insert. And finally, you will need something to increase your ubsa buffers, I am using the ubsa.c_buffers_patch attached. (Crude, but cleaner than http://www.freebsd.org/cgi/query-pr.cgi?pr=119227) --Marcin
Re: sierra wireless compass 597 aircard (Was: Documentation)
user name
2008-05-03 08:01:49
Marcin Cieslak wrote:
> It maybe a good idea to add 0xFFF to the usbdevs.
> Does the "umass" driver  attach to the 0xFFF
device? I would recommend 
> adding this as a quirk to umass.c then.
> 
> There are patches attached (ubsa.c_patch,
umass_c.patch, usbdevs.patch) 
> I am using to kill the "zeroconf" CD on the
UMTS. They do not always 
> work - i.e. umass_attach does not wait until the device
is really 
> detached. But setting USB_DEBUG helps 
> 

Since your patches deals with Option cards I'll just let you
know that
all(?) Option based devices can be switched perfectly safe
from
user land, without patching ubsa, using camcontrol.
The command to switch Option devices is a SCSI REZERO
command.

This should be enough to switch the device, given that
pass0
is the modem (use camcontrol devlist)

camcontrol cmd pass0 -c “01 00 00 00 00 00″ -i 1 i1

camcontrol might give you an error but the device will be
switched.
Note that this is ONLY for Option based devices, I don't
know about
the Sierra ones but the linux usb_modeswitch tool might be a
good start.

Fredrik

_______________________________________________
freebsd-usbfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to
"freebsd-usb-unsubscribefreebsd.org"

Re: sierra wireless compass 597 aircard (Was: Documentation)
country flaguser name
United States
2008-05-05 13:52:00
Marcin Cieslak wrote:
> Steve Clark wrote:
> 
>>>>Is there any detailed documentation on the
FreeBSD usb device driver 
>>>>api?
> 
> 
> This chapter helped me a lot to understand how this all
works:
> 
> http://www.freebsd.org/doc/en_US.ISO8859-
1/books/arch-handbook/usb.html
> 
> 
>>I sort of have it working by hacking ubsa.c to look
for the sierra 
>>vendor id and product id of 0xfff in
>>the usb_match function and return match. Then in the
usb_attach code I 
>>look again for the vendor and
>>product id of 0xfff and then send the control
message to put it in modem 
>>mode.
>>    if ( uaa->vendor == USB_VENDOR_SIERRA
&& uaa->product == 0xfff )
> 
> 
> It maybe a good idea to add 0xFFF to the usbdevs.
> Does the "umass" driver  attach to the 0xFFF
device? I would recommend 
> adding this as a quirk to umass.c then.

Actually I am not sure. The device when in TRU-Install mode
looks like umass device,
it has a place to insert a microSD card, and also cdrom
drive that when mounted has
the software to install on windows. When it is put in modem
mode the cdrom disappears
but the umass device is still there. One other thing is that
when installed on a linux
system there are 3 serial ports. The first port is used for
the modem, one is used for a
builtin gps receiver and I think the 3rd passes signal
strength information to the windows
software. 
> 
> There are patches attached (ubsa.c_patch,
umass_c.patch, usbdevs.patch) 
> I am using to kill the "zeroconf" CD on the
UMTS. They do not always 
> work - i.e. umass_attach does not wait until the device
is really 
> detached. But setting USB_DEBUG helps 
> 
> 
>>    {
>>        ubsa_request_real( sc, 0x0b, 1, 0x40 );
>>        ucom->sc_dying = 1;
>>                goto error;
>>    }
> 
> 
>>This puts in modem mode with product id of 0x0023
which i have plugged 
>>into usbdevs and also put in ubsa.c
>>so now I get a ucom device and can successfully run
ppp. The problem I 
>>am running into now is sometime after
>>it remove the device I will get a page fault panic
in the kernel. 
> 
> 
> What kind of panic is this?
> 
> 
>>I think it is related to the sending the
>>control_message - something is not cleaned up when I
"goto error" in the 
>>USB_ATTACH function.
>>
> 
> htt
p://www.freebsd.org/cgi/query-pr.cgi?pr=121755

Yeah this looks like the panic I am getting. One of my
fellow workers needed the
usb device - so I am waiting for us to get another to
continue testing.

> 
> There are two patches, one to ohci_pci.c, the other to
usb_subr.c. One 
> of them is not correct - after kldunloading the module
you may run into 
> problems. But it makes everyday life easier - at least
you can remove 
> the card and re-insert.
> 
> And finally, you will need something to increase your
ubsa buffers, I am 
> using the ubsa.c_buffers_patch attached. (Crude, but
cleaner than
> htt
p://www.freebsd.org/cgi/query-pr.cgi?pr=119227)

For the time being I just hard coded larger buffers - like I
see you did below.

Thanks for your input. When I get my replacement modem I'll
let you know
how I make out.
> 
> --Marcin
> 
> 
....<SNIP>
>  

I am attaching an lsusb listing from a linux system FYI.

Thanks,
Steve

_______________________________________________
freebsd-usbfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to
"freebsd-usb-unsubscribefreebsd.org"

  
[1-3]

about | contact  Other archives ( Real Estate discussion Medical topics )