Winner, Name that Ware November 2009

November 25th, 2009

The Ware for November 2009 is the Openmoko Wikireader! It’s a very tidy device; well designed and well manufactured.

The winner for Name that Ware November 2009 is cesarb, since jacob did not post his plaintext by judging time. My normal judging rules consider factors other than who was the first to make the correct guess, but this was a lightning round. Although, to be fair I think that cesarb showed good intuition in his explanation, and intuition is an important part of reverse engineering.

Congrats, email me to claim your chumby One!

chumby One

November 13th, 2009

The chumby One is finally released. You can buy it now for a $99 “chumby insider” pre-order price; once we start shipping, the price will go up to $119.



While I’ve been working on several new hardware platforms for chumby, this is the first of the crop to hit the market. This one made it out before the Christmas season because it is an evolution of the original chumby design, now called the “chumby classic”, as opposed to a completely new form factor for the device.

The key goal of the chumby One platform was cost reduction: my first sketches for the device were drawn on the back of a napkin about a year ago, back when the stock market was in a free-fall and losing several hundred points a day. Unfortunately, the chumby classic hit full-stride launch in the middle of the worst economic downturn since the Great Depression, and its cute cuddly form factor comes at a fair bit of a price tag that many couldn’t stomach. So, I did what any entrepreneur would do in a recession, I suppose … scale back, and take a good hard look at everything and try to build a product that is cheaper, faster, and better for the market, to try and win new customers, and to retain the loyalties of our existing customer base.

Fortunately, around that time, a Freescale apps engineer contacted me about a new CPU (the i.MX233) they were going to launch in 2009 that could hit a remarkably low price point. So, I drew up some strawman renderings and did some cost scenarios, and in CES 2009, we circulated the idea around with a few potential customers to get feedback on the features and pricing. The idea sort of slow-rolled through the first few months of 2009, and after chinese new years, I taped out the first prototype board in late March. Around May we contracted an industrial designer to do some sketches, and by June we had a near-final ID; our first 3D printed prototypes were made around then (we couldn’t afford a mechanical engineering contractor I had to learn Solidworks and do the mechanical integration for the 3D prototype myself — since I enjoy learning new things, this was quite a rewarding experience). In July, we inked a PO for steel tooling and by August we had first-shot plastics. September was spent refining and debugging the design, and October was spent doing more testing, refining, and ramping up mass production. And, here we are now, in November. When I wrote this, the first shipment of chumby Ones were somewhere 35,000 feet above the Pacific Ocean en route to LAX. As for the i.MX233, I believe we are one of the first devices on the market to use it…I even got a quote in their launch press release last August, although I couldn’t refer to the chumby One by name at that time.

Just to give you an idea of what the final assembly line for the chumby One looks like, below is a video of a part of the assembly line:


[flashvideo file=http://www.bunniestudios.com/blog/images/c1mp_line.flv /]

In addition to being about half the price of the original chumby, the new device added some features: it has an FM radio, and it has support for a rechargeable lithium ion battery (although it’s not included with the device, you have to buy one and install it yourself). There’s also a knob so you can easily/quickly adjust the volume. But I don’t think those are really the significant new features. What really gets me excited about this one is that it’s much more hackable. The most significant improvement is that the firmware is stored on a microSD card.

The microSD card isn’t replaceable from the outside — this is to prevent non-hackers from pulling it out and wondering why the device isn’t booting anymore — but if you take the back panel off (screws this time, no glue seals), it’s fairly easy to access. The key here is that no longer do you have to worry about bricking your chumby device: if you screw up the firmware, you just pull it out, mount it on your dev box, and dd a new image onto it. Also, microSD is a “managed” NAND device, unlike our previous generation device which used a raw NAND device. This means that we don’t have to rely on a MTD layer for the filesystem, and instead we can directly drop ext3 onto the device. While we still mount the root partition as read-only to harden the device against accidental damage, unlike our original cramfs implementation, you can trivially remount it as read/write and modify the linux on the device. Also, our OS image takes up only a small portion of the total device capacity, so there’s actually over a gigabyte of extra space on there for you to load extra applications and libraries.

Significantly, what’s good for the hackers is also good for the developers. Because of this additional flexibility, we could add a ton of great features into the OS. For example, the chumby one supports certain 3G modems, and will serve wifi as an access point through the 3G modem (it can also serve as an access point for an ethernet connection provided via a USB-to-ethernet dongle as well). This is really slick, because that makes it basically a 3G to wifi router; it is enormously useful when I’m traveling and I need to create a wifi hotspot for other devices to use. Of course, this feature isn’t exposed yet at the mainstream user level, but if it turns out to be a popular application it’s something we could wrap a GUI around and make it more friendly to use. There are also other little refinements, such as if you plug a USB keyboard into a chumby One, it will automatically pop up a console shell that you can type into; very handy for times when you can’t ssh in, like when you are debugging network scripts. It also has high-speed USB2.0 support, so unlike our previous generation device, you can plug a USB camera into this one and grab images at a decent speed. And yes, we’ve booted Android on the chumby One. Android runs on linux after all, so why not? Eventually we’ll get these hacks documented on the chumby wiki (heck, maybe even compile them into a book), but right now we’re a little pre-occupied with making sure the product launch goes smoothly. Actually, to give credit where it’s due, most of these cool hacks were implemented by xobs (remember him? he ported quake on the chumby classic), not me — I’m just the hardware guy, xobs is the software guru.

Below are some annotated photos of the chumby One mainboard. Schematics and gerbers are forthcoming, should be up in about a week or two; the GPL source code is already up.

This is actually a pre-production pilot board. The mass production board is basically identical to this, with some minor tweaks to enhance compatibility with the SMT machines we use in China. There’s a couple of noteworthy points about the board. First, the footprints are available on the board for you to populate some parts to break out a composite video signal (NTSC or PAL). We’ve actually wired this up and confirmed that it works, and it’s pretty neat for presentations where you want to plug into a projector and show a crowd of people some widgets. There’s also a pair of test points on the board labeled “SETEC ASTRONOMY” that you can use to bypass the write protect on our authentication ROM, in case you want to wipe out the keys we use to authenticate your chumby. I can’t think of a real reason why you’d want to do that, but I added them on the principle that hardware you own shouldn’t hold secrets from you, so if you don’t like it you can nuke the encrypted access codes we put into each device (of course, it means you no longer have the codes to fetch widgets from our servers, but hey, it’s your hardware, void the warranty and do what you want with it). The security system is actually a bit convoluted on this device, but it uses basically the same, published protocol we employed on the chumby classic with some enhancements to leverage the internal AES engine on the i.MX233 to save the cost of an external cryptoprocessor unit.

One other really cool thing about the motherboard that I’d like to point out is that the power regulators are embedded inside the CPU. And they aren’t just linear regulators, they are switching regulators. And they just aren’t any switching regulators — this switching regulator derives three voltages using just a single inductor. How cool is that? Mad props to the guy who designed that system. The insanely high level of analog integration on this CPU — it pulls in the audio codec, power regulators, speaker amplifier, USB PHY, video DAC, battery charger and more — is one of the key things that has allowed me to create a system that you can buy at an affordable price.

If you’ve seen any of the chumby classic boards, you’ll instantly recognize that there are also mounting holes and features so this board can be retrofitted back into a chumby classic. That’s very intentional, although chumby doesn’t currently have a schedule to put this into a chumby classic; the classic line costs a lot to produce for more reasons than the PCB (think hand-stitched Italian leather). There’s also a couple of technical issues with integration, the most significant being the brutal thermal environment inside the chumby classic: the CPU contains the battery charging circuitry, and unlike the main supply, the charger circuit is a linear regulator so when charging it puts out a lot of heat. This is why we added a heatsink to the CPU, so we could charge the battery at maximum rate without having to throttle the CPU’s activity. I’m not quite sure how I would solve this problem if I were to put the board into a chumby classic, since there are no cooling holes in the device. I also get the sense that there wouldn’t be very much interest in a chumby classic that was a little bit cheaper, but still lacking the much-requested rechargeable battery: I am stuck between a rock and a hard place. However, the initial reactions to the battery in the chumby One are an interesting study in consumer psychology. For some reason, even though the chumby One is smaller and lighter than the chumby classic, and does largely exactly the same things, people don’t feel like it should have a rechargeable battery; they have no intrinsic desire to pick up the chumby One and carry it around. Just goes to show how much form influences a consumer’s perception of function. Also, as a very important note to intrepid hackers who want to try to retrofit one of these boards into their chumby classic: even though the footprint is identical, the chumbilical is absolutely not compatible with the chumby classic. For one thing, the chumby classic gets 12V from the chumbilical, and this device expects 5V. So if you were to just solder on a header and plug it into a chumby classic housing, you would get quite a cloud of smoke out of the device!

Also, as a little game for the readers, I will award a chumby One as a prize to the first person who can most accurately guess the number of vias on the chumby One circuit board based on the photos in this post. It’s a bit like one of those competitions where if you can guess the number of jellybeans in a jar you get the jar of jellybeans. This is vias not counting through-hole pads. Since the gerbers aren’t posted yet, you can’t cheat and use a CAD program to count the number of vias. :-) I’ll end the contest once the gerbers are posted, in about a week or so.

Name that Ware November 2009

November 12th, 2009

The ware for November 2009 is shown below. Click on the image for a much larger version.

This is from a brilliant little device that I’m thoroughly enjoying right now. Well-designed, and surprisingly addictive. First person to guess this correctly gets a chumby One as a prize.

As a reminder, if you want to enter a tentative guess without letting everyone else know, you can post an md5sum or a sha1sum of your guess string, and then post the source text for your hash in about a week — but remember to do that, because if you just leave a hash and fail to post your source text, I can’t judge your entry and the prize might go to someone else!

Winner, Name That Ware October 2009

November 12th, 2009

The winner for October 2009’s ware is insidetronics. All I can say is, dang, I don’t know how people managed to figure out where this one came from, but the web links you posted to photos of the assembled boards convinced me. If you do get a chance, please share with us how you knew or discovered the answer.

Very impressive! congrats, email to claim your prize!

Advice on Reliable SSD Chipset?

November 9th, 2009

I spent the weekend transferring my data and applications to a new Crucial 256 GB M225 SSD, and after about 10 hours of operation, the hard drive simply failed. It failed while “hot” even — the hard drive lite jammed on, my MP3 stopped playing, and the system froze up — like my worst nightmare come true. How is this possible? It’s supposed to be solid state. It’s supposed to have greater than 1,000,000 hours MTBF. Yet, it’s true. No matter what laptop I put it into, I now simply get this on boot:

2100: HDD0 (Hard disk drive) initialization error (1).

The drive isn’t 100% dead per se. There is a little switch on the drive that puts it into configuration mode, and it will identify itself as a Yatapdong Barefoot device (instead of a Crucial device) in this mode. So presumably, the embedded controller is still alive and kicking, but even in this mode I can’t seem to reflash the drive’s firmware or re-initialize it to a state where the normal mode is functional. When I switch it back out of configuration mode, the BIOS refuses to enumerate the drive, and without enumeration I can’t even run a diagnostic on the device. It’s definitely not an OS issue — BIOS-level diagnostics simply refuse to recognize the drive.

Searching around in the Crucial Forum, it seems these drives “have a high failure rate”. So much for a million-hour MTBF. I’m not sure exactly what’s causing it, because it is entirely solid state, and the SMT process used to build these drives are a very robust and well-proven technology. My guess is it’s got something to do with the firmware or the controller chip; they already have three firmware releases out for this drive, and disturbingly you can reflash these from inside the native OS — seems like a great candidate method for deeply embedding malware into a PC. Well, hopefully I can just return this drive for a full refund, since it failed so quickly.

At any rate, I’m wondering if anyone can give some advice on a good, reliable brand of SSD to use. The few hours I did spend with the SSD were quite positive; the performance boost is excellent, and a large number of my common work applications greatly benefited from the extremely fast access times. I’m still a bit spooked by the idea that these drives can fail so easily, but then again, fundamentally if I were in a jam I am equipped with the tools to recover the data — these devices use simple TSOP flash memory, so I suppose in the worst case I could dump the ROMs. Fortunately this one failed young, so the quickest solution is to just return for a refund and try something else.

Poking around a bit on-line, it seems that this Crucial drive uses the same Indilinx controller and firmware as the OCZ Vertex, the Patriot Torx, and the Corsair Extreme series (based on the “Yatapdong Barefoot” ID in configuration mode). On Amazon.com, I can see other users are experiencing exactly the same issue with a Corsair Extreme Indilinx series device. So I think it’s safe to say I’d like to steer clear of a solution based on the Indilinx chipset, at least until this issue is patched — ironically, the Indilinx website’s motto is “Beyond the Spin” (who are these guys, Fox News?), but it seems to me like their website’s got a lot more spin than substance. A link to a datasheet or firmware spec would be nicer than the marketing fluff.

Thanks in advance for the advice!