Posted on 2 Comments

iphone camera dissection

From DealExtreme, I got these tiny iPhone camera modules (sku.16945) and was hoping to get the specs, but no luck. So I thought, why not sacrifice one.

iphone camera module with lens removed
iphone camera module with lens removed (false colors due to IR lighting for better visibility)

The heat gun melted off the lens in no time. Scratching off the last bits of plastic dirt reveals, as the rumours suggested:

  • It’s a SOC2020 or MT9D112 sensor (Aptina), respectively SpecTek WXMK15A in a special package
  • The sensor is protected by a glass layer
  • The bond wires are connected to a ceramic carrier
  • The ceramic carrier is directly soldered onto the flex

Unfortunately, the sensor pinout is still a secret, and I still don’t have an iPhone myself to probe. Perhaps it’s time for some good guessing?

Posted on 1 Comment

Sony P990 camera internals

The Sony P990 camera is a Aptina SOC-2010 or MT9D111.


P990 camera module
P990 camera module

Opening this beast, reveals some more details as shown in the pictures below. Also, we find out more about the sensor:

K14L die
K14L die, bonded to flex
  • It’s seems to be identical with the SpecTek part #WXMK15L
  • It’s bonded directly on the flex cable without protection. The bond wires can be damaged very easily when trying to buzz through the connections
  • The autofocus is a piezo spiral, driven by high voltage which is generated on the camera module by a DC/DC converter

The pinout

Flex Connector
Flex Connector (Mating: Molex 51338-0374)
Pin No. Signal Pin No. Signal
1 GND 30 GND
2 D1 29 D0
3 D3 28 D2
4 D5 27 D4
5 D7 26 D8
6 GND 25 GND
8 SCL 23 GND
11 VDD2.8 20 ?
12 GPIO 19 GND
14 GND 17 GND
15 VDDIO2.8 16 VDD1.8
Posted on 1 Comment

Yet another uClinux v4l2 framework

The goal: Building a Linux embedded camera
The problem: Supporting a large number of sensors with an even large number of registers and properties

Currently, the SOC framework in the more recent kernel versions addresses this in a smart way: a generic SOC v4l2 framework serves as a base for custom sensor support kernel modules that register their ioctls and generic v4l2 properties with this framework.
This intelligent approach still has one drawback:

  • It enlarges the kernel even more
  • Access of sensor properties needs to be coded manually

How to break the gordian knot? This is a sketch of an idea.

The netpp library allows to create abstract property lists from XML description files. These files describe a device in general, there can be a low level section specifying register addresses and an abstract property section linking property names (strings) to registers or bits. The XML code is translated into a compact property list of C structs and compiled into object code.

Now, we don’t want this stuff living in kernel space, right? We’d rather want some kind of callback functionality so that only the common denominator of all functionality is handled in kernel space.

Example: An embedded camera must handle several sensors even at the same time, possibly via bus tristating or on several video input channels.
This would require major efforts with the current model.

The proposed alternative:

  • A sensor kernel module handles only detection of a sensor type and the bus type methods (e.g. i2c). This would be a very thin layer, thus easy to implement.
  • Basic v4l2 functionality (like setting resolution) can be encoded in this driver as ioctl() handlers, if necessary
  • Preferrably, the more exotic ioctls or specific device properties that were so far handled by custom ioctls are now living in user space.
  • User space applications using these sensors register their sensor property lists via a kernel daemon. This daemon handles the callbacks from a kernel ioctl() to a user space property.


  • The total overhead may be increased, as the user application contains all the netpp description (C code, not XML) blurb.
  • User space code can do forbidden stuff, of course. Permissions must be sorted out well, extra checks for exploits must be taken care of.


  • Only generic code in Kernel
  • Most flexibility for multi head or pluggable camera hardware
  • Little development overhead required: Sensor properties are just encoded in a readable (style sheet capable editors!) XML source format.
  • It is up to the user which properties are exposed or hidden.


  1. What’s the optimum callback mechanism (hotplug/dbus?)
  2. Do we want more interaction between netpp and the kernel daemon?
  3. Do we want a very generic property netpp daemon?
  4. Do we even want enhanced remote property control (RPC) functionality