By now you might have heard of the Amazon Kindle, the e-paper based reader, that allows wireless access to a vast library of electronic books from Amazon, and some selected blogs, newspapers, and such. There is even “experimental” access to the internet, though it’s not very powerful, and is geared around static data only. I won’t rehash more of the publicly available details on the unit, but give an inside peek at the guts of the unit.
One of the things that I noticed right away is the limited set of file formats that Kindle supports. Glaring omissions were the popular PDF format, and all forms of images, such as JPG and TIFF. Amazon provides a service that can be accessed for free and for fee, that converts image files to Kindle format. However, the service seems a bit slow, and requires the the file must be e-mailed to be converted.
To see what it can do, I used the service to convert several image files. The result was an image file that apparently had a maximum size and maximum resolution. An analysis of the files that were produced showed a header, followed by some HTML code, and then a binary image file. What appeared to be some closing bytes appeared at the end of the file.
With a hex file editor I cut&pasted the obvious header and footer, and placed them around some JPG files of my own. The resulting combinations did appear in Kindle as files, and were even partially viewable as images.
Kindle, however, seemed to refuse to display images above a certain size. While I did not determine the exact cut off point, it seemed to be somewhere around 64kB. An image larger than 64kB would only display correctly for information in the first 64kB. The remaining pixels were shown in a uniform pleasant gray.
I can’t tell if the behavior is an intentional limitation in the Kindle software, a CPU-driven feature (e.g. 16-bit registers), or caused by memory constraints. I wanted to find out, hence I had no alternative to popping the covers on the unit.
The unit is relatively easy to open. There are 8 screws, all accessible without peeling labels. The corners of the plastic case have tabs with a very firm grip, but they will pop with an even pull on the side while pushing the top cover in the opposite direction. (Kids, if you have never done this before, or if you are worried about having a broken Kindle, don’t try this at home.)
The interior of the unit was not exactly crowded. There is one main circuit board, with attachments for the keyboard, the displays, main power switches, scrolling mouse and the SD card adapter.
The AnyData DTEV-DUAL cellular modem is connected using a board-to-board connector, but its shell is permanently soldered to the main circuit board. It seems to have two antennas, one on the top, and one on the bottom right side of the unit.
The main microcontrollers are a Microchip PIC16LF874A, NXP ISP1761BF and Intel PXA255. The purpose of the PIC part is unknown, but a hunch based on its location is that it provides handling for the scroller and the keyboard. The NXP part is a USB-On-The-Go controller, which means that it can also function as a USB host, even though the Kindle only supports being a USB client device. The Intel part is an X-Scale ARM processor, which likely is the main processing unit for the Kindle.
Audio is handled by a Wolfson Microelectronics WM8971 Stereo codec that seems to be driven by another small PIC microcontroller marked “6282E/7270SH”. The latter could also be memory or a voltage controller, but I had insufficient time to determine its type.
Memory on the unit is present in two Infineon 256 megabit Mobile-RAM parts, giving the PXA255 a total of 64 megabytes of RAM, accessible over a 32-bit bus. There are two Samsung K6F4016U6G chips that provide 1 megabyte of SRAM, accessible over a 32 bit bus, which are either working memory for the NXP part, or more likely video memory. Firmware is stored in a Spansion 512 megabyte boot-sector Flash, type S29AL004D90BFI01.
The display controller is the same as on the Sony electronic book series, a part marked “9322 571 0032 1 Apollo 1.18 T6TW8XBG-001”.
The only part that remained a minor mystery is marked KFG2G16Q2M-DEB8 from Samsung. It is located next to two ADG3247 bus switches. It appears to be a 2 gigabit Flash part (256 megabytes). Its proximity to the bus switches might mean that these provide for sharing of the Flash between the NXP part when USB is connected to a PC, and the Intel PXA255 in the normal operating mode.
The last parts worthy of mention are a LM75A and a LTC3455. The LM75A measures temperature, and is likely used to avoid overheating the battery and the cellular modem. The LTC3455 provides battery power management, charging, and DC-DC conversion to change the variable voltage of the battery to a fixed voltage for the internal electronics.
Now that I know what’s inside the unit, it’s easier to say where limitations to functionality are intentional and where they are not.
First, there appears to be no good reason for this system to not handle large images. The CPU thinks in 32 bit, there is plenty of memory, and video output is not generated on the fly, but stored in SRAM. Hence, the limit is arbitrary.
This system should also easily be able to handle compressed and encrypted PDF files, making that limit arbitrary as well.
The USB-OTG controller is interesting, as it means that the unit might have future applications beyond what’s apparent.
I’m not about to start hacking my Kindle, but it’s apparent that serious hacking opportunities are present. The PXA255 is a common MCU, and its firmware comes from an external flash. The file system is likely on the other flash. And access to all is likely to be easy, since the board seems to have JTAG connectors and connection points for programming the various microcontrollers and memories. One of the connectors is even accessible while the case is closed, just by popping off a small access panel next to the battery.
If you end up hacking your Kindle, please let the world know what you find!