Re: USB serial device naming
On Thursday 06 May 2010 11:07:00 Alexandr Rybalko wrote: On Wed, 5 May 2010 21:57:20 +0200 Hans Petter Selasky hsela...@c2i.net wrote: Hi, Thanks for all good ideas. Can you give some feedback on the following solution: http://p4web.freebsd.org/@@19?ac=10 Looks interest, can You send to me patch to svn head. (So more difference in p4, without access to p4 difficult to test it) Me too... I have no experience with p4, now I even could not access it for some reason... Think uhub_child_location_string output must be added to attach event, so devd can make unique link for device. Milan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB serial device naming
On Wednesday 05 May 2010 09:52:15 Hans Petter Selasky wrote: Hi, Maybe you can make PR on the issue and assign it to USB. Currently there is no way of knowing which /dev/cuaUXXX belongs to which USB device. Probably we can add the USB bus and address number as a part of the device coordinates. So that /dev/ugen1.1 only creates /dev/cuaU1.1.xxx entries. And then we can also remove the current unit number allocation structure I guess, if we use: /dev/cuaU1.1.iface_number.optional_sub_modem_unit The only problem is: Will we break any existing applications? Well, yes, to some extent :) Problem with this naming convention is name changes with every port change - that is, if you pull USB cable out and plug it in another port. There was already some older thread about naming on freebsd-usb list (end of April 2009). But if devd receives all necessary informations in attach event, then it is possible to rewrite config files or create symlink in /dev directory or something like this to handle this situation. The second problem was that the USB attach event was generated before the modem was probed and the umodem and other modem drivers do not provide any information about their USB address in the pnpinfo. This can be fixed. Old pnpinfo: dev.ums.0.%pnpinfo: vendor=0x0 product=0x0 devclass=0x00 devsubclass=0x00 sernum= release=0x0200 intclass=0x03 intsubclass=0x01 Suggested new pnpinfo (which is available from devd.conf I guess) dev.ums.0.%pnpinfo: vendor=0x0 product=0x0 devclass=0x00 devsubclass=0x00 sernum= release=0x0200 intclass=0x03 intsubclass=0x01 bus=1 addr=2 ifaceidx=0 This would be good thing to do I think. Just a typo spot here - ums means USB mouse driver, I think, but this idea is worth evaluating. My sole concern is use somehow stable names for situations when more than one serial port (serial USB cable, u3g modem etc) is attached so each device is properly used in correct program. Regards, Milan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Huawei E1752 under FreeBSD
On Friday 12 February 2010 11:40:56 Milan Obuch wrote:
On Friday 12 February 2010 09:48:14 Hans Petter Selasky wrote:
On Wednesday 10 February 2010 10:50:08 Milan Obuch wrote:
Hi,
I got this 3G modem, it is not recognised under FreeBSD (tested with
fresh 9-CURRENT).
I found no relevant information googling for huawei e1752 freebsd,
but huawei e1752 linux got me
http://www.blogcatalog.com/blog/iwrite-2/dbbfb38ae5ef9ccef8540aad7f9edb
d6
and there is part about usb modeswitch, part of config reproduced here:
# Huawei E1752
#
# Contributor:
DefaultVendor= 0x12d1
DefaultProduct= 0x1446
TargetVendor= 0x12d1
TargetProdct= 0x1001
MessageEndpoint=0x01
MessageContent=
55534243001106
It looks like this is the message necessary for switching this device
into modem mode, but I have no idea how to issue such comm and. Also,
for my use I need to get this working under 8.0-RELEASE/STABLE.
The last 16-hex bytes of the message is a SCSI command. Please make a new
one in:
usb/usb_msctest.c
Then test and make a patch for usb/usbdevs and usb/serial/u3g.c .
--HPS
I finally managed to compile and test new kernel/modules and it works. Could
you please check my patches, review and eventually commit?
Thanks for hint, it did my day a bit better now... I am going to test
net/e169-stats port, it looks like there is status interface available for
it.
Milan
Hmm, just to be sure I understand what you mean, I made following patches:
diff -u usb_msctest.h.orig usb_msctest.h.patched
--- usb_msctest.h.orig 2010-01-16 14:17:58.0 +0100
+++ usb_msctest.h.patched 2010-02-12 11:30:36.0 +0100
@@ -31,7 +31,8 @@
MSC_EJECT_STOPUNIT,
MSC_EJECT_REZERO,
MSC_EJECT_ZTESTOR,
- MSC_EJECT_CMOTECH
+ MSC_EJECT_CMOTECH,
+ MSC_EJECT_E1752
};
int usb_iface_is_cdrom(struct usb_device *udev,
diff -u usb_msctest.c.orig usb_msctest.c.patched
--- usb_msctest.c.orig 2010-02-12 11:15:40.0 +0100
+++ usb_msctest.c.patched 2010-02-12 11:30:00.0 +0100
@@ -94,6 +94,9 @@
0x01, 0x01, 0x01, 0x01, 0x00,
0x00 };
static uint8_t scsi_cmotech_eject[] = { 0xff, 0x52, 0x44, 0x45, 0x56,
0x43, 0x48, 0x47 };
+static uint8_t scsi_huawei1752_eject[] = { 0x11, 0x06, 0x00, 0x00, 0x00,
0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, + 0x00, 0x00, 0x00, 0x00 };
#defineBULK_SIZE 64 /* dummy */
#defineERR_CSW_FAILED -1
@@ -611,6 +614,11 @@
scsi_cmotech_eject, sizeof(scsi_cmotech_eject),
USB_MS_HZ);
break;
+ case MSC_EJECT_E1752:
+ err = bbb_command_start(sc, DIR_IN, 0, NULL, 0,
+ scsi_huawei1752_eject, sizeof(scsi_huawei1752_eject),
+ USB_MS_HZ);
+ break;
default:
printf(usb_msc_eject: unknown eject method (%d)\n,
method); break;
diff -u usbdevs.orig usbdevs.patched
--- usbdevs.orig2010-02-05 02:47:43.0 +0100
+++ usbdevs.patched 2010-02-09 23:27:38.0 +0100
@@ -1724,6 +1724,7 @@
product HUAWEI E143E 0x143e 3G modem
product HUAWEI E143F 0x143f 3G modem
product HUAWEI E14AC 0x14ac 3G modem
+product HUAWEI E1752 0x1446 3G modem
/* HUAWEI 3com products */
product HUAWEI3COM WUB320G 0x0009 Aolynk WUB320g
diff -u u3g.c.orig u3g.c.patched
--- u3g.c.orig 2010-02-09 22:10:21.0 +0100
+++ u3g.c 2010-02-12 11:39:28.0 +0100
@@ -92,6 +92,7 @@
#defineU3GINIT_CMOTECH 6 /* Requires CMOTECH SCSI
command */
#defineU3GINIT_WAIT7 /* Device reappears after a
delay */
#defineU3GINIT_SAEL_M460 8 /* Requires vendor init */
+#defineU3GINIT_HUAWEI_E17529 /* Requires Huawei E1752
init command */
enum {
U3G_BULK_WR,
@@ -281,6 +282,7 @@
U3G_DEV(HUAWEI, E220, U3GINIT_HUAWEI),
U3G_DEV(HUAWEI, E220BIS, U3GINIT_HUAWEI),
U3G_DEV(HUAWEI, MOBILE, U3GINIT_HUAWEI),
+ U3G_DEV(HUAWEI, E1752, U3GINIT_HUAWEI_E1752),
U3G_DEV(KYOCERA2, CDMA_MSM_K, 0),
U3G_DEV(KYOCERA2, KPC680, 0),
U3G_DEV(MERLIN, V620, 0),
@@ -668,6 +670,9 @@
/* Just pretend we ejected, the card will timeout
*/ error = 0;
break;
+ case U3GINIT_HUAWEI_E1752:
+ error = usb_msc_eject(udev, 0, MSC_EJECT_E1752);
+ break;
default:
/* no 3G eject quirks */
error = EOPNOTSUPP;
I am going
Re: Huawei E1752 under FreeBSD
On Saturday 13 February 2010 17:13:02 Hans Petter Selasky wrote:
On Saturday 13 February 2010 16:30:05 Milan Obuch wrote:
Milan Obuch
Hi,
Committed to USB P4:
http://p4web.freebsd.org/chv.cgi?CH=174658
http://perforce.freebsd.org/chv.cgi?CH=174658
Please verify the commit. Thanks for your patch!
--HPS
Everything looks OK, I just think there should not be a comma after last
enumerated value in usb_msctest.h:
enum {
MSC_EJECT_STOPUNIT,
MSC_EJECT_REZERO,
MSC_EJECT_ZTESTOR,
MSC_EJECT_CMOTECH,
MSC_EJECT_E1752,
};
(At least version before this change had not it there...)
Milan
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Huawei E1752 under FreeBSD
On Friday 12 February 2010 09:48:14 Hans Petter Selasky wrote:
On Wednesday 10 February 2010 10:50:08 Milan Obuch wrote:
Hi,
I got this 3G modem, it is not recognised under FreeBSD (tested with
fresh 9-CURRENT).
I found no relevant information googling for huawei e1752 freebsd,
but huawei e1752 linux got me
http://www.blogcatalog.com/blog/iwrite-2/dbbfb38ae5ef9ccef8540aad7f9edbd6
and there is part about usb modeswitch, part of config reproduced here:
# Huawei E1752
#
# Contributor:
DefaultVendor= 0x12d1
DefaultProduct= 0x1446
TargetVendor= 0x12d1
TargetProdct= 0x1001
MessageEndpoint=0x01
MessageContent=
55534243001106
It looks like this is the message necessary for switching this device
into modem mode, but I have no idea how to issue such comm and. Also, for
my use I need to get this working under 8.0-RELEASE/STABLE.
The last 16-hex bytes of the message is a SCSI command. Please make a new
one in:
usb/usb_msctest.c
Then test and make a patch for usb/usbdevs and usb/serial/u3g.c .
--HPS
Hmm, just to be sure I understand what you mean, I made following patches:
diff -u usb_msctest.h.orig usb_msctest.h.patched
--- usb_msctest.h.orig 2010-01-16 14:17:58.0 +0100
+++ usb_msctest.h.patched 2010-02-12 11:30:36.0 +0100
@@ -31,7 +31,8 @@
MSC_EJECT_STOPUNIT,
MSC_EJECT_REZERO,
MSC_EJECT_ZTESTOR,
- MSC_EJECT_CMOTECH
+ MSC_EJECT_CMOTECH,
+ MSC_EJECT_E1752
};
int usb_iface_is_cdrom(struct usb_device *udev,
diff -u usb_msctest.c.orig usb_msctest.c.patched
--- usb_msctest.c.orig 2010-02-12 11:15:40.0 +0100
+++ usb_msctest.c.patched 2010-02-12 11:30:00.0 +0100
@@ -94,6 +94,9 @@
0x01, 0x01, 0x01, 0x01, 0x00,
0x00 };
static uint8_t scsi_cmotech_eject[] = { 0xff, 0x52, 0x44, 0x45, 0x56, 0x43,
0x48, 0x47 };
+static uint8_t scsi_huawei1752_eject[] = { 0x11, 0x06, 0x00, 0x00, 0x00,
0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00 };
#defineBULK_SIZE 64 /* dummy */
#defineERR_CSW_FAILED -1
@@ -611,6 +614,11 @@
scsi_cmotech_eject, sizeof(scsi_cmotech_eject),
USB_MS_HZ);
break;
+ case MSC_EJECT_E1752:
+ err = bbb_command_start(sc, DIR_IN, 0, NULL, 0,
+ scsi_huawei1752_eject, sizeof(scsi_huawei1752_eject),
+ USB_MS_HZ);
+ break;
default:
printf(usb_msc_eject: unknown eject method (%d)\n, method);
break;
diff -u usbdevs.orig usbdevs.patched
--- usbdevs.orig2010-02-05 02:47:43.0 +0100
+++ usbdevs.patched 2010-02-09 23:27:38.0 +0100
@@ -1724,6 +1724,7 @@
product HUAWEI E143E 0x143e 3G modem
product HUAWEI E143F 0x143f 3G modem
product HUAWEI E14AC 0x14ac 3G modem
+product HUAWEI E1752 0x1446 3G modem
/* HUAWEI 3com products */
product HUAWEI3COM WUB320G 0x0009 Aolynk WUB320g
diff -u u3g.c.orig u3g.c.patched
--- u3g.c.orig 2010-02-09 22:10:21.0 +0100
+++ u3g.c 2010-02-12 11:39:28.0 +0100
@@ -92,6 +92,7 @@
#defineU3GINIT_CMOTECH 6 /* Requires CMOTECH SCSI
command */
#defineU3GINIT_WAIT7 /* Device reappears after a
delay */
#defineU3GINIT_SAEL_M460 8 /* Requires vendor init */
+#defineU3GINIT_HUAWEI_E17529 /* Requires Huawei E1752 init
command */
enum {
U3G_BULK_WR,
@@ -281,6 +282,7 @@
U3G_DEV(HUAWEI, E220, U3GINIT_HUAWEI),
U3G_DEV(HUAWEI, E220BIS, U3GINIT_HUAWEI),
U3G_DEV(HUAWEI, MOBILE, U3GINIT_HUAWEI),
+ U3G_DEV(HUAWEI, E1752, U3GINIT_HUAWEI_E1752),
U3G_DEV(KYOCERA2, CDMA_MSM_K, 0),
U3G_DEV(KYOCERA2, KPC680, 0),
U3G_DEV(MERLIN, V620, 0),
@@ -668,6 +670,9 @@
/* Just pretend we ejected, the card will timeout */
error = 0;
break;
+ case U3GINIT_HUAWEI_E1752:
+ error = usb_msc_eject(udev, 0, MSC_EJECT_E1752);
+ break;
default:
/* no 3G eject quirks */
error = EOPNOTSUPP;
I am going to compile it and test, just sent now if you see something wrong
(well, as said, I am not 100 % I understood exactly what you mean).
Regards,
Milan
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Huawei E1752 under FreeBSD
Hi, I got this 3G modem, it is not recognised under FreeBSD (tested with fresh 9-CURRENT). I found no relevant information googling for huawei e1752 freebsd, but huawei e1752 linux got me http://www.blogcatalog.com/blog/iwrite-2/dbbfb38ae5ef9ccef8540aad7f9edbd6 and there is part about usb modeswitch, part of config reproduced here: # Huawei E1752 # # Contributor: DefaultVendor= 0x12d1 DefaultProduct= 0x1446 TargetVendor= 0x12d1 TargetProdct= 0x1001 MessageEndpoint=0x01 MessageContent= 55534243001106 It looks like this is the message necessary for switching this device into modem mode, but I have no idea how to issue such command. Also, for my use I need to get this working under 8.0-RELEASE/STABLE. Any hint/help on this one? Regards, Milan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Huawei E169 and microSD
On Friday 21 August 2009 12:31:16 Milan Obuch wrote: On Friday 21 August 2009 12:29:14 Milan Obuch wrote: On Thursday 20 August 2009 09:15:35 Milan Obuch wrote: Hi, I tested E169 with both 7.2 and 8.0, with u3g loaded it works well here. Download speed 256 kBps is quite good I think. There is possibility to insert microSD into it and this one does not work. In 7.2, microSD is not even detected (see attached log-e169-72). In 8.0, microSD is detected, device created (in my case /dev/da1), but trying to use it gives dd if=/dev/da1 dd: /dev/da1: Device not configured error. And it is not a hardware problem, because I was able to initialize this card in Windows. Today I tried to get some debug, did sysctl hw.usb.umass.debug=-1, inserted E169 with microSD. Produced debug attached. Maybe it needs some quirk? Regards, Milan umass1: vendor 0x12d1 HUAWEI Mobile, class 0/0, rev 1.10/0.00, addr 2 on usbus0 umass1: SCSI over Bulk-Only; quirks = 0x umass1:umass_cam_action: 1:-1:-1:XPT_PATH_INQ:. umass1:1:1:-1: Attached to scbus1 umass1:umass_cam_rescan: scbus1: scanning for 1:1:-1 umass1:umass_cam_action: 1:-1:-1:XPT_PATH_INQ:. umass1:umass_cam_action: 1:0:0:XPT_PATH_INQ:. umass1:umass_cam_action: 1:0:0:XPT_PATH_INQ:. umass1:umass_cam_action: 1:0:0:XPT_GET_TRAN_SETTINGS:. umass1:umass_cam_action: 1:0:0:XPT_SET_TRAN_SETTINGS:. umass1:umass_cam_action: 1:0:0:XPT_PATH_INQ:. umass1:umass_cam_action: 1:0:0:XPT_PATH_INQ:. umass1:umass_cam_action: 1:0:0:XPT_SCSI_IO: cmd: 0x12, flags: 0x40, 6b cmd/36b data/18b sense umass1:umass_attach: Attach finishedumass1:umass_bbb_dump_cbw: CBW 1: cmd = 6b (0x12002400), data = 36b, lun = 0, dir = in umass1:umass_transfer_start: transfer index = 4 umass1:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=36 umass1:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 umass1:umass_transfer_start: transfer index = 8 umass1:umass_bbb_dump_csw: CSW 1: sig = 0x53425355 (valid), tag = 0x0001, res = 0, status = 0x00 (good) umass1:umass_cam_action: 1:0:0:XPT_SCSI_IO: cmd: 0x12, flags: 0x40, 6b cmd/56b data/18b sense umass1:umass_bbb_dump_cbw: CBW 2: cmd = 6b (0x12003800), data = 56b, lun = 0, dir = in umass1:umass_transfer_start: transfer index = 4 umass1:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=56 umass1:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 umass1:umass_transfer_start: transfer index = 8 umass1:umass_bbb_dump_csw: CSW 2: sig = 0x53425355 (valid), tag = 0x0002, res = 0, status = 0x00 (good) umass1:umass_cam_action: 1:0:0:XPT_PATH_INQ:. umass1:umass_cam_action: 1:0:0:XPT_PATH_INQ:. umass1:umass_cam_action: 1:0:0:XPT_GET_TRAN_SETTINGS:. umass1:umass_cam_action: 1:0:0:XPT_SET_TRAN_SETTINGS:. umass1:umass_cam_action: 1:0:0:XPT_SCSI_IO: cmd: 0x12, flags: 0x40, 6b cmd/255b data/18b sense umass1:umass_bbb_dump_cbw: CBW 3: cmd = 6b (0x1201ff00), data = 255b, lun = 0, dir = in umass1:umass_transfer_start: transfer index = 4 umass1:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=255 umass1:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 umass1:umass_transfer_start: transfer index = 8 umass1:umass_bbb_dump_csw: CSW 3: sig = 0x53425355 (valid), tag = 0x0003, res = 199, status = 0x00 (good) umass1:umass_cam_action: 1:0:0:XPT_GET_TRAN_SETTINGS:. umass1:umass_cam_action: 1:0:0:XPT_PATH_INQ:. umass1:umass_cam_action: 1:0:0:XPT_GET_TRAN_SETTINGS:. umass1:umass_cam_action: 1:0:0:XPT_SET_TRAN_SETTINGS:. umass1:umass_cam_action: 1:0:0:XPT_SCSI_IO: cmd: 0x00, flags: 0xc0, 6b cmd/0b data/32b sense umass1:umass_bbb_dump_cbw: CBW 4: cmd = 6b (0x), data = 0b, lun = 0, dir = out umass1:umass_transfer_start: transfer index = 8 umass1:umass_bbb_dump_csw: CSW 4: sig = 0x53425355 (valid), tag = 0x0004, res = 0, status = 0x01 (failed) umass1:umass_t_bbb_status_callback: Command failed, residue = 0 umass1:umass_cam_cb: Fetching 32 bytes of sense data umass1:umass_bbb_dump_cbw: CBW 5: cmd = 6b (0x03002000), data = 32b, lun = 0, dir = in umass1:umass_transfer_start: transfer index = 4 umass1:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=32 umass1:umass_t_bbb_data_read_callback: max_bulk=131072, data_rem=0 umass1:umass_transfer_start: transfer index = 8 umass1:umass_bbb_dump_csw: CSW 5: sig = 0x53425355 (valid), tag = 0x0005, res = 14, status = 0x00 (good) umass1:umass_cam_action: 1:0:0:XPT_PATH_INQ:. umass1:umass_cam_action: 1:0:0:XPT_SCSI_IO: cmd: 0x25, flags: 0x40, 10b cmd/8b data/32b sense umass1:umass_cam_action: 1:0:1:XPT_PATH_INQ:. umass1:umass_cam_action: 1:0:1:XPT_PATH_INQ:. umass1:umass_cam_action: 1:0:1:XPT_GET_TRAN_SETTINGS:. umass1:umass_cam_action: 1:0:1:XPT_SET_TRAN_SETTINGS:. umass1:umass_cam_action: 1:0:1:XPT_PATH_INQ:. umass1:umass_cam_action: 1:0:1:XPT_PATH_INQ:. umass1:umass_bbb_dump_cbw: CBW 6: cmd = 10b (0x2500...), data = 8b, lun = 0, dir = in umass1:umass_transfer_start: transfer index
Re: Huawei E169 and microSD
On Friday 21 August 2009 12:29:14 Milan Obuch wrote: On Thursday 20 August 2009 09:15:35 Milan Obuch wrote: Hi, I tested E169 with both 7.2 and 8.0, with u3g loaded it works well here. Download speed 256 kBps is quite good I think. There is possibility to insert microSD into it and this one does not work. In 7.2, microSD is not even detected (see attached log-e169-72). In 8.0, microSD is detected, device created (in my case /dev/da1), but trying to use it gives dd if=/dev/da1 dd: /dev/da1: Device not configured error. And it is not a hardware problem, because I was able to initialize this card in Windows. Also, built-in autoinstall flash presented as CD works well. Some time ago I was able to do some tests with E170. In this case, microSD worked out of the box, at that time, tested only with 8.0. Has anybody any idea, what's wrong here? Something to test? Regards, Milan For some reason, list software stripped second attachment... trying here... Anybody has any idea why this umass does not function? What could I test? Regards, Milan Strange, no go... inline version: ucom0: \M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^? \M^?\M^? HUAWEI Mobile, class 0/0, rev 1.10/0.00, addr 2 on uhub0 ucom0: Interface 0 of 4, not in use ucom0: Endpoint 0 of 3 ucom0: Endpoint 1 of 3 ucom0: Endpoint 2 of 3 ucom0: port=0 iface=0 in=0x82 out=0x2 ucom0: Interface 1 of 4, not in use ucom0: Endpoint 0 of 2 ucom0: Endpoint 1 of 2 ucom0: port=1 iface=1 in=0x84 out=0x3 ucom0: Interface 2 of 4, not in use ucom0: Endpoint 0 of 2 ucom0: Endpoint 1 of 2 ucom0: port=2 iface=2 in=0x85 out=0x5 ucom0: Interface 3 of 4, not in use ucom0: configured 3 serial ports (U0.%d) ucom0: at uhub0 port 2 (addr 2) disconnected ucom0: detached ucom0: \M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^? \M^?\M^? HUAWEI Mobile, class 0/0, rev 1.10/0.00, addr 2 on uhub0 ucom0: Interface 0 of 4, not in use ucom0: Endpoint 0 of 3 ucom0: Endpoint 1 of 3 ucom0: Endpoint 2 of 3 ucom0: port=0 iface=0 in=0x82 out=0x2 ucom0: Interface 1 of 4, not in use ucom0: Endpoint 0 of 2 ucom0: Endpoint 1 of 2 ucom0: port=1 iface=1 in=0x84 out=0x3 ucom0: Interface 2 of 4, not in use ucom0: Endpoint 0 of 2 ucom0: Endpoint 1 of 2 ucom0: port=2 iface=2 in=0x85 out=0x5 ucom0: Interface 3 of 4, not in use ucom0: configured 3 serial ports (U0.%d) umass0: \M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^? \M^?\M^? HUAWEI Mobile, class 0/0, rev 1.10/0.00, addr 2 on uhub0 (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI Status: Check Condition (probe0:umass-sim0:0:0:0): NOT READY asc:3a,0 (probe0:umass-sim0:0:0:0): Medium not present (probe0:umass-sim0:0:0:0): Unretryable error cd0 at umass-sim0 bus 0 target 0 lun 0 cd0: HUAWEI Mass Storage 2.31 Removable CD-ROM SCSI-2 device cd0: 1.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present Milan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Huawei E169 and microSD
Hi, I tested E169 with both 7.2 and 8.0, with u3g loaded it works well here. Download speed 256 kBps is quite good I think. There is possibility to insert microSD into it and this one does not work. In 7.2, microSD is not even detected (see attached log-e169-72). In 8.0, microSD is detected, device created (in my case /dev/da1), but trying to use it gives dd if=/dev/da1 dd: /dev/da1: Device not configured error. And it is not a hardware problem, because I was able to initialize this card in Windows. Also, built-in autoinstall flash presented as CD works well. Some time ago I was able to do some tests with E170. In this case, microSD worked out of the box, at that time, tested only with 8.0. Has anybody any idea, what's wrong here? Something to test? Regards, Milan u3g_huawei_init:269: usb_alloc_device:1781: Found Huawei auto-install disk! ugen1.2: vendor 0x12d1 at usbus1 ugen1.2: vendor 0x12d1 at usbus1 (disconnected) uhub_reattach_port:440: could not allocate new device! ugen1.2: vendor 0x12d1 at usbus1 u3g0: Data Interface on usbus1 u3g0: Found 3 ports. umass1: vendor 0x12d1 HUAWEI Mobile, class 0/0, rev 1.10/0.00, addr 2 on usbus1 umass1: SCSI over Bulk-Only; quirks = 0x umass1:1:1:-1: Attached to scbus1 (probe0:umass-sim1:1:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:umass-sim1:1:0:0): CAM Status: SCSI Status Error (probe0:umass-sim1:1:0:0): SCSI Status: Check Condition (probe0:umass-sim1:1:0:0): NOT READY asc:3a,0 (probe0:umass-sim1:1:0:0): Medium not present (probe0:umass-sim1:1:0:0): Unretryable error cd0 at umass-sim1 bus 1 target 0 lun 0 cd0: HUAWEI Mass Storage 2.31 Removable CD-ROM SCSI-2 device cd0: 1.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present (probe0:umass-sim1:1:0:1): TEST UNIT READY. CDB: 0 20 0 0 0 0 (probe0:umass-sim1:1:0:1): CAM Status: SCSI Status Error (probe0:umass-sim1:1:0:1): SCSI Status: Check Condition (probe0:umass-sim1:1:0:1): NOT READY asc:3a,0 (probe0:umass-sim1:1:0:1): Medium not present (probe0:umass-sim1:1:0:1): Unretryable error da1 at umass-sim1 bus 1 target 0 lun 1 da1: HUAWEI SD Storage 2.31 Removable Direct Access SCSI-2 device da1: 1.000MB/s transfers da1: Attempt to query device size failed: NOT READY, Medium not present ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
u3g serial device name query
Hi, I have HUAWEI 3g usb modem. It works with u3g from current. There is however one thing I did not get working yet. When device attaches, it is added into tree as u3gN, devd event is sent. It is easily matched with 'device-name u3g[0-9]' clause in devd.conf. I can start ppp automatically and it works well, given no other USB serial device is present. If another USB serial device such as uplcom is present, u3g serial ports does not have the same name. I found no way to relate serial device name to this event and looking in source I see no place where it is created. I would like to put a devctl notify call there. This way I could start ppp with correct device name even if there is some other USB serial device. Could someone point me in the right direction? Regards, Milan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: u3g serial device name query
On Thursday 30 April 2009 12:58:36 Hans Petter Selasky wrote: On Thursday 30 April 2009, Milan Obuch wrote: Hi, I have HUAWEI 3g usb modem. It works with u3g from current. There is however one thing I did not get working yet. When device attaches, it is added into tree as u3gN, devd event is sent. It is easily matched with 'device-name u3g[0-9]' clause in devd.conf. I can start ppp automatically and it works well, given no other USB serial device is present. If another USB serial device such as uplcom is present, u3g serial ports does not have the same name. I found no way to relate serial device name to this event and looking in source I see no place where it is created. I would like to put a devctl notify call there. This way I could start ppp with correct device name even if there is some other USB serial device. Could someone point me in the right direction? USB serial devices have their own unit management. There is however a way to override the unit number through the usb2_com_tty_name callback, which requires some code changes to the u3g driver. All USB modems and serial adapters end up with the same naming prefix: /dev/cuaU%d.%d, so the assigned numbers must be serialised. What we could do is to have a separate naming prefix for 3G modems, and use the device_get_unit() for unit number. See: src/sys/dev/usb/serial and usb_serial.c I looked over usb2_com_attach_tty function in usb_serial.c, and somewhere after call to tty_makedev (where a DPRINT is too) I could put a devctl call. All I need for it would be device name. In /var/log/message file I see a line telling 'u3g0 : Found 2 ports' just after usb2_com_attach_tty function is called. If you could tell me how I can get 'u3g0' name via sc argument in usb2_com_attach_tty function, I can solve this with no other change. Regards, Milan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB HID parser
On Thursday 15 May 2008, Chuck Robey wrote: Milan Obuch wrote: On Wednesday 14 May 2008, Chuck Robey wrote: I wrote a parser, and I don't know if anyone might be interested in it. I didn't write it as something to be used in a driver ... I wrote it as a learning aid, for someone who's trying to learn that horrible USB HID spec. It's quite verbose, most especially if you use it in GUI mode (I wrote it in Python, and it's got a integral Tkinter GUI. In Python mode, it's got help info available on every output it has, and displays the data it's parsing in a way taht makes it fairly easy to have the USB HID parser on your knee, while you slowly step the parser thru the input data. [ ... ] I called it parsetool. I know that's a fairly dumb name )(there are one or two projects already oout with that name), come up with a better one, and I'll gladly use it (if it's not overly silly). May I suggest another name? We have udesc_dump in ports, I would like to offer uhid_parse(r) as a better alternative... Write me if you want it, I'll mail it to you, the tarball is fairly small (even with all those tables, it's only about 25K compressed) and installation couldn't really get any easier, just make sure you have a working python of 2.3 or later, with a working Tkinter. Could you eventually make a port from it and submit it this way? I think it could be usefull for many... After getting no response to any requests for any feedback (like alpha test, but about either the protocol features, OR the accessibility of the UI) I begin to wonder if there is really any interest pool for this. Unless I get at least *some* feedback, I will make it available, but no port. Geeze, it doesn't need one! If you have Python + Tkinter, then copy it into come directory, then kick it off either with a redirect or a -f filename flag (yes, there's a usage()), it can't get a whole lot easier, could it? Not even any compiling! I sat for what seemed like forever and pounded those endless tables into the source code, too. Well, putting a port into repository is not that hard. Actually, it makes a bit more exposure for your code. All you need is a small Makefile, distinfo and that's all. And put distfile somewhere on web to make it actually accessible. Choose license for your code (if I understand it right you wrote it all, so there is nobody else to do this) and here you are. Then you can expect some responses or maybe even patches... If you would like to help with porting, we could cooperate. I do not think I am the best person for this, just offering a help if you like. I'm beginning to wonder if I will have even one FreeBSDer who wants it, Might get rid of a couple of Linux versions. I hate to admit that it works just as well on Windows, darn it. Maybe I could figure out how to break it for Windows, what do you say? Everyone working seriously with USB devices will try it when it will know about and it will be easily accessible, which is what ports are for. As for Windows, no idea. But if you could make some sort of how-to with simple guide hove to get all prerequisites fullfilled, expect some feedback. Or there will be none? If you won't try it, you won't know. Regards, Milan -- Address this mail is sent from is used only for this mailing list. Do not send any messages to it directly as a response, reply only to mailing list. For mail to me personally, use milan in address instead. ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
