Posted on

LeanXcam hacking

The leanXcam has been out for a while now, finally I got my hands on a OEM module.

The first impressions:

  • Interesting 4 plane layout. The bypass caps are somewhat far away from the processor on the top side. Not sure if they are really useful that way..
  • Cheap optics, but they do the job
  • Plugging in Ethernet and Power, I was able to telnet into the beast at the default within seconds and try the webserver. Nice!

Now, how to run our standalone netpp framework:

The JTAG (which we definitely need for bare metal, i.e. non uClinux development) wasn’t populated. The helpful folks at Supercomputing systems told me the specs of the somewhat unusual SMD header:

Farnell, Order #1421678

Keep in mind that pin 3 must be spare for the key.

So, after being set with JTAG, I plugged in one of the new ICEbearPlus units and run the flashloader:

flashload --info --driver=spi_flash.dxe

This is what we get:

Detected Device: BF-537(536) rev:3
Manufacturer        : Atmel
Device Type         : Dataflash 45DB321D
 Driver title: SPI flash programmer (STM, Atmel)
 Description: AT45DB321D
 Manufacturer Code: 0x1f
 Device Code: 0x27
 Number of sectors: 0x41
 Number of regions: 0x3
 Bus width: 0x8
 Buffer size: 0x2000
 Flash size: 0x400000

Cool, that worked from the spot. There is another flash on SPI select 5, i.e. found by flashloader via the –unit=4 option. Before starting to hack, it might be a good idea to save the flash images:

flashload --info --driver=spi_flash.dxe --unit=0 --dump leanx_0.img --size=0x400000

Downloading code

So now. We got this standalone shell code to try out stuff, lets see how the code from the pretty similar STAMP BF537 board can be ported. After a few modifications later, I seem to be able to talk to the shell via the bfpeek console (the bfpeek channel is a way to do stream I/O over JTAG without the need to attach a serial cable):

strubi@gmuhl:~/src/blackfin/shell/boards/LEANXCAM$ nc localhost 4000

// test shell // (c) 2004-2009, <hackfin-├Ą>  //

Board: LeanXcam BF537

Let’s see if we see something on the i2c bus:

> i
Detecting devices: 5c

Right, that should be the i2c address of the MT9V032 sensor.

Let’s try grabbing a frame with the ‘v’ command – oops, timeout! Could it be that the sensor is in standby mode? I guess we’ll have to check the schematics now. And here we should emphasize: The leanXcam does not make a secret about its internals: The schematics are openly available (Why keep something a secret that isn’t really one?)

Nah, everything ok, the sensor should run. Giving it a few tries and running into the usual obscure core faults we remember: Random core faults mostly got to do with bad SDRAM! After revisiting the settings and fixing them, we see:

> v 3
Initializing video with 640x480
Video start
Process frame [0], 0 jiffies
Data error in frame 0
Process frame [1], 21 jiffies
Data error in frame 1
Process frame [0], 21 jiffies
Data error in frame 0
Video stop (9 frames received)
 (6 overrun)

Bingo. We lost 6 frames due to the output via the bfpeek channel that burns many CPU cycles, but that was to expect. We ignore the data error, because we didn’t yet enable the test pattern.

Well, this is kinda amazing. It does not happen so often that you plug in hardware of that sort and it works that smooth right away.

Thus, I can recommend the leanXcam to anyone who wants to get into serious image processing, be it uClinux or standalone.

Posted on

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