Openembedded Chumby images

Get the images and instructions from here:

From the README:

What works

  • console access, though the colours are a bit off (seems like red and green are swapped
  • Input via USB Keyboard
  • WiFi (association to Open and WPAPSK Networks tested) You need to follow iwpriv-usage.txt which is included in the rt73 sourcecode to setup encrypted networks
  • Sound via alsa
  • Touch screen


  • Mode switching seems broken. When X is started or when tscalibrate exits the screen becomes really unstable. I have now added a patch, that just returns when the kernel function is called. The function that needs to be fixed is imxfbactivate_var. There is already a workaround in this function, but it doesn't seem to help.
  • Something isn't right regarding the colours. Maybe the kernel thinks it's using palette mode while it's not or vice versa.
  • Using the rt73 drivers provided by chumby resulted in a kernel panic after some traffic.

Please send any issues/advice/questions to

Posted by daniel 20/01/2008 at 12:53

Chumby killed and resurrected

Actually this post was supposed to be about how cool and flashy the Chumby - my new toy - is. I even had an hour to play around with this ARM9 based alarm clock and try out some of the flash widgets (their whole UI is flash based) and so far it was fun.

However, then we didn't have enough US -> Euro power plug converters (I group ordered the Chumby together with Wansti, Shoragan and Stefan) so I dug around and found a power supply that was rated at 12V, 1A. The website of the Chumby said it would function over quite a range of voltage so I didn't bother to check more closely.
This changed when I noticed the magic smoke coming out of my Chumby. That can't be good! Turns out the power supply I used had the polarity reversed and the Chumby doesn't have any protection for that case.

Now nothing would happen any more, even with the original power supply plugged in, so I needed to open up my Chumby. I was planning on doing that anyway to hack the hardware, but under these circumstances I wasn't too happy having to do this now. Fortunately both the software (at least most of it) and schematics for the hardware are openly available, so I was able to download the schematics and try to figure out what went wrong.

It turns out that both 3.3V power regulators were fried. The one powering the P33V_BKUP rail just passed the input voltage (12V) right through. At this point I was quite sure that my Chumby was beyond recovery since the cryptochip is powered from that rail, but I went ahead and replaced the regulator with a different one I had at home. Now something happened when I tried to turn on the Chumby. The other power rails came up when I pressed the power button, and since the power logic is handled by the crypto processor it must still be alive! Apart from that, nothing much happened, though, except that the Chumby drew ~100mA more power than one of its little brothers (Thanks Shoragan for entrusting me with your Chumby after I already killed mine) and mine didn't even turn its display on. So I measured again and found the second bad 3.3V regulator that delivered 3.8V to the P33V power rail (and got pretty hot in the process). After replacing that part the power consumption seemed about right. Time to connect the display again and try it out...yay, it powers up, boots, and....doesn't find the wifi card. Well, I didn't have it plugged in so that's okay. :-)

Check out the pictures here:

What a relief! Now I resoldered the power regulators so they would fit in the assembly (The ones I have weren't even SMD parts) and reassembled everything.

And it works! Words can't describe how relieved I was when the Chumby greeted me with its little startup animation.

I have now joined Shoragan's efforts to add Chumby support to OpenEmbedded and we already have a working kernel and rootfs. Unfortunately the bootloader keeps passing cramfs as the fstype to the kernel and OpenEmbedded doesn't really seem to like a readonly filesystem, so the kernel needs to be patched to ignore the cmdline arguments and use it's default - for now. I'd like to use u-boot on the Chumby in the long run so that it can be updated via dfu-util. That would save quite some space which is now used as backup kernel/rootfs and a cache partition that holds OTA firmware updates before they are flashed.

Right now though we have a 22MB rootfs partition which is too small for most images (like the openmoko-image). Booting from USB stick works, though, which is what we'll try to optimize for now.

If you want to try out the images (use at your own risk!) they're at

Let me know if you have any problems, either by mail or in ##chumby on freenode.

After two days of playing around with the Chumby I have to say that I really like that form factor. It's really nice as a small display for various information, as an alarm, a small portable wifi terminal (Just plug in a USB keyboard and you're set) or all sorts of other things.

Posted by daniel 19/01/2008 at 06:07