Date: Fri, 21 Nov 2003 01:43:13 +0100 (CET) From: Barry Bouwsma <freebsd-misuser@remove-NOSPAM-to-reply.NOSPAM.dyndns.dk> To: FreeBSD Hardware Wizards <freebsd-hardware@freebsd.org> Subject: Re: USB camera compatibility question Message-ID: <200311210043.hAL0hDu01322@NOSPAM.spam.NOSPAM.spam.NOSPAM.dyndns.dk> References: <200311050441.hA54fhJ54978@NOSPAM.spam.NOSPAM.spam.NOSPAM.dyndns.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
[Drop my (IPv6-only) address if replying; I'll catch the archives]
I'm going to do a Bad Thing and follow up to myself, just because I
tend to write way too much. And in case this would be useful for the
archives or elsewhere...
I blabbered mindlessly the following a few weeks back:
> I'm wondering if anyone in the southern germany or adjacent border areas
> has any experience with the digital camera on offer from the discounter
> Aldi-Sued since 22.Okt, and FreeBSD. It's a `Traveller' or something
> Does it, or should I be able to expect it to, function as a USB storage
> device connected directly to a USB port under FreeBSD?
Yes, with a fair amount of kernel hacking.
> Or do I have to use some other device to access the memory cards and any
> images thereupon?
Yes, because so far the images snarfed with my hacks are okay for the
first 4096 bytes, thereafter failing to match the perfect images I can
download with the `mtools' utilities from a printer cum card slot.
There seem to be chunks of NULs present regularly throughout the file.
First of all, the device can be attached as a umass device -- I'm using
some mid-Sept. source code plus the RELENG_4-USB patches based on recent
-current code, fixing what breaks.
The device is identified as follows:
umass0: vendor 0x0784 product 0x1689, rev 0.01/0.01, addr 2, 8070i (ATAPI) over Bulk-Only
The vendor ID is listed in the NetBSD usbdevs source as JENOPTIK. Make
of that what you will. The product number is not present, no surprise.
The SCSI ID for the camera is as follows:
pass1 at umass-sim0 bus 0 target 0 lun 0
pass1: <CAMERA 5MP-9A3 1.00> Removable Direct Access SCSI-0 device
pass1: 650KB/s transfers
A quirk entry is needed in umass.c in order for the device to be
created as /dev/da*, without which one sees the following:
Creating DISK da1
(da1:umass-sim0:0:0:0): got CAM status 0x4
(da1:umass-sim0:0:0:0): fatal error, failed to attach to device
(da1:umass-sim0:0:0:0): lost device
(da1:umass-sim0:0:0:0): removing device entry
if (UGETW(dd->idVendor) == 0x0784) /* JENOPTIK */ {
sc->quirks |= FORCE_SHORT_INQUIRY;
}
(Whether additional quirks are needed, perhaps to solve the 4096-
byte corruption, well, I haven't experimented with that yet)
Also, a quirk could be added to scsi_da.c because this device does
not care for the SYNCHRONIZE_CACHE command. However, that looks to
be more of a shortcoming in the ATAPI transformation, and rather than
adding a line like
{T_DIRECT, SIP_MEDIA_REMOVABLE, "CAMERA*", "5MP-9A3*", "1.00*"},
/*quirks*/ DA_Q_NO_SYNC_CACHE
(The wildcard CAMERA* seems to be needed; the others probably can be
made much more generic)
instead, I thought I would see if I could get the atapi transformation
to ignore sync_cache instead of returning an error and putting out those
annoying messages all over my console. I don't suppose the CAM or xpt
or whatever layer would know it's talking to an 8070i device and thus
automagically apply the NO_SYNC_CACHE quirk...
So, with that, I have a modest amount of joy. Save for the corrupted
images, at least I can mount the card and get directory listings, and
copy the corrupt files at several hundred kB/sec, much faster than the
mtools access that gives proper images for those times I care about
data integrity, taking minutes rather than seconds.
Woohoo.
Barry Bouwsma
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200311210043.hAL0hDu01322>