Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 24 Apr 2010 14:09:02 +0200
From:      maillist@diode.be
To:        freebsd-usb@freebsd.org
Subject:   webcamd and cameras with Micron (MT9M0x1 and MT9T0x1) chips
Message-ID:  <20100424140902.4b7meoicg084g04g@webmail.diode.be>

next in thread | raw e-mail | index | archive | help
Hello list members,

In the last months I have been toying with the video4bsd module and
webcamd, as this finally gave me a possibility to use CMOS cameras
with FreeBSD in an optics experiment (thanks!). For this I set up a
box with 8-STABLE, and followed the instructions from
http://www.selasky.org/hans_petter/video4bsd/ , using ports where
applicable.

I had instant success with an older Philips Toucam, and also with a
Logitech C300 at full resolution (1024x1280). What didn't work back
then was a Micron MT9T031 usb camera. I had hoped this would have
worked with the mt9t031.c driver from v4l in the webcamd code. But
there are some aspects of this camera that suggest it could be an
early prototype. As it didn't associate with a driver on other OS'es
as well, I didn't look into this further.

Now I have a Mightex MCE-B013-US monochrome 1.3MPixel camera, which
utilizes a Micron MT9M001 chip. There is a mt9m001.c file in the v4l
code, but unfortunately this camera isn't recognized either. This made
me wonder whether there is something special with these Micron
CMOS-chips (and the code) that differs from other webcams.

For both Micron cameras, #webcamd -B just gives `Cannot find USB device'.

dmesg output for the Mightex camera (MT9M001 chip):
ugen3.2: <Mightex> at usbus3

and usbconfig -d ugen3.2 dump_device_desc gives:
ugen3.2: <USB-MT9M001-2 Mightex> at usbus3, cfg=3D0 md=3DHOST spd=3DHIGH
(480Mbps) pwr=3DON

    bLength =3D 0x0012
    bDescriptorType =3D 0x0001
    bcdUSB =3D 0x0200
    bDeviceClass =3D 0x0000
    bDeviceSubClass =3D 0x0000
    bDeviceProtocol =3D 0x0000
    bMaxPacketSize0 =3D 0x0040
    idVendor =3D 0x04b4
    idProduct =3D 0x0228
    bcdDevice =3D 0x0000
    iManufacturer =3D 0x0001  <Mightex>
    iProduct =3D 0x0002  <USB-MT9M001-2>
    iSerialNumber =3D 0x0000  <no string>
    bNumConfigurations =3D 0x0001


For the MT9T031 camera (likely prototype), dmesg gives:
ugen3.2: <Micron> at usbus3

and usbconfig -d ugen3.2 dump_device_desc:
ugen3.2: <Demo2A Micron> at usbus3, cfg=3D0 md=3DHOST spd=3DHIGH (480Mbps) p=
wr=3DON

    bLength =3D 0x0012
    bDescriptorType =3D 0x0001
    bcdUSB =3D 0x0200
    bDeviceClass =3D 0x0000
    bDeviceSubClass =3D 0x0000
    bDeviceProtocol =3D 0x0000
    bMaxPacketSize0 =3D 0x0040
    idVendor =3D 0x0634
    idProduct =3D 0x1007
    bcdDevice =3D 0x0021
    iManufacturer =3D 0x0001  <Micron>
    iProduct =3D 0x0002  <Demo2A>
    iSerialNumber =3D 0x0000  <no string>
    bNumConfigurations =3D 0x0001




Now, I have no coding skills, but thought it would be good to have a =20
look into the driver code. I hoped I would find Vendor and Product =20
id's that differed from how the camera identified, this explaining the =20
refusal to associate. But while some other v4l drivers appear to =20
contain things like {USB_DEVICE(0xXXXX, 0xXXXX), .driver_info=3DXXXXX}, =20
such code is absent from the mt9xxxx.c files. Instead, there is a =20
function data =3D reg_read(client, MT9M001_CHIP_VERSION) that does some =20
sort of identification. But this is on the i2c level, reading the chip =20
version number. I thought that for doing this, the system would =20
already need to know what Micron chip it is dealing with.

Any thoughts would be appreciated.

Thanks.

Tiemen




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100424140902.4b7meoicg084g04g>