[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

USB Mass Storage Adapter/Adaptor umass.c 'fixes'.



I've got a few USB 2.0 to IDE 3.5" HDD / CD-ROM / DVD-ROM enclosures.
They're 'USB 2.0 IDE Storage Adapters' known by several models and vendors:

ME-320U2

http://www.atechdigilog.com/
Atech Digilog ADUE235W

http://www.triumphtech.com/p/tt-320/pa320-215.htm

I'm not sure what the actual chipset is, or what other vendors may OEM the same
basic unit.  It is possible that there are significant firmware differences
out there, or other Vendor / Device I can't say.

OpenBSD 3.1 codebase seems to recognize the unit I am debugging as:
USB_VENDOR_DMI 0x0c0b
USB_PRODUCT_DMI_SA2_0 0xb001
in /usr/src/sys/dev/usb/usbdevs.h

It did not work in stock OpenBSD 3.1, and it produced the following
dmesg output as it was recognized:

umass0 at uhub2 port 1 configuration 2 interface 0
umass0: DMI USB 2.0 Storage Adaptor, rev 2.00/11.10, addr 3
umass0: using SCSI over BBB-P
umass1 at uhub2 port 2 configuration 2 interface 0
umass1: DMI USB 2.0 Storage Adaptor, rev 2.00/11.10, addr 4
umass1: using SCSI over BBB-P
scsibus1 at umass1: 2 targets
cd0 at scsibus1 targ 1 lun 0: <TOSHIBA, DVD-ROM SD-M1212, 1R10> SCSI0 5/cdrom removable

I have edited /usr/src/sys/dev/usb/umass.c and recompiled the kernel to attempt
to debug the problems.  I have produced a kernel which seems to work for this
device using a modified umass.c.  The main 'problem' seemes to be that it
seems to be functional when ATAPI over UIPROTO_MASS_BBB is used, and fail when
what seemed to be detected as SCSI over UIPROTO_MASS_BBB_P is used.

I am still rather confused why this device is explicitly listed in the OpenBSD 3.1
source code (USB_VENDOR_DMI 0x0c0b USB_PRODUCT_DMI_SA2_0 0xb001) and yet totally
failed to be properly configured.  

I am also rather suspicious of what seems to be a possible general weakness in 
umass.c for determining access modes for unrelated devices in the function:
umass_match_proto().  I would think that sc->subclass and sc->protocol et. al.
could be more consistently initialized depending on code flow.

My testing of the changes has been limited, but entirely successful so far.

Maybe there are problems with using the same storage enclosure but with
IDE Hard disks instead of a DVD/CD ROM inside, however I have not tested that
yet, preferring to get the CD configuration working first.

For the reasons of my limited understanding of some of the code, my limited testing,
and my suspicions of remaining code weaknesses, I will not now say this is the
exact/only/final change that should be made to umass.c.

However, I will post what I have so far in case someone else needs to use it,
or in case others with more famialiarity with this device / this codebase may
like to know of the developments.

--- umass.c.rel31	Wed Mar 13 19:16:08 2002
+++ umass.c.alpha	Fri Jun 28 06:00:49 2002
@@ -711,6 +711,24 @@
 	vendor = UGETW(dd->idVendor);
 	product = UGETW(dd->idProduct);
 
+#if 1 /* CDH */
+	if (vendor == USB_VENDOR_DMI &&
+	    product == USB_PRODUCT_DMI_SA2_0 ) {
+		sc->drive = DRIVE_GENERIC;
+		sc->proto = PROTO_UNKNOWN; /* umass.c 361 */
+		sc->proto |= PROTO_ATAPI;
+		sc->proto |= PROTO_BBB;
+
+		sc->subclass = UISUBCLASS_SFF8020I;
+		sc->protocol = UIPROTO_MASS_BBB;
+
+#if 0
+		printf("CDH DMI SA2 ATAPI BBB\n");
+#endif
+		return (UMATCH_VENDOR_PRODUCT);
+	}
+#endif	/* CDH */
+
 	if (vendor == USB_VENDOR_SHUTTLE &&
 	    product == USB_PRODUCT_SHUTTLE_EUSB) {
 		sc->drive = SHUTTLE_EUSB;

EOF
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com



Visit your host, monkey.org