Geekmaster's adventures in K1 spelunking

[geekmaster]

I purchased a K1 (Kindle 1st generation) on ebay a couple of years back, from a pawn shop with an ebay store. As received, the all-important roller wheel was incredibly flaky, making the cursor jump around (going the wrong direction almost as often as the correct direction). I gave up and put it in storage. When I mentioned this problem to the vendor, they gave me a full refund (including shipping), and they did not want it back.

Recently, I updated my entire kindle collection (about 150 devices) by recharging them, then using kubrick to flash them to a recent jailbreak version of firmware. Interestingly, I (re)discovered that they charge to a green light MUCH faster (hours instead of a couple of days, because the batteries had all gone complete dead) if I do a hard reset on them after they have charged for a few minutes. Before I started doing that hard reset (hold power button for 30 seconds), it could take many hours for the power LED to even begin to glow. After a hard reset the LED would begin to glow within a couple of minutes, fading in to full brilliance. Later I discovered that I could have charged even faster in fastboot mode (according to posts I left in this forum long ago). Memories fade when you do not refresh them...

As it turned out, the kindles I had charged for days until the LED turned green (before I started hard resetting them) where all in USB downloader mode -- apparently the batteries were too discharged for them to initialize SDRAM when they charged just enough for the SoC to power-on boot.

Later, I discovered more about the charging speeds by examining USB device power usage (as reported in Windows properties) with kindles attached via USB in different boot modes. In USB downloading mode it only draws 10mA, which can take days to charge the battery (typically about 40 hours or so). I also noticed (but did not record which boot modes) 100mA and 500mA USB power usage -- I am not sure whether fastboot or main boot mode charges faster, but either is 10x to 50x faster than USB downloader mode.

*** So, when charging a dead kindle, remember to do a hard boot after charging the battery for about five or ten minutes, even (especially) if the power LED has not begun to glow yet. It may have put itself into USB downloader mode, and that charges at a snail's pace.

I will post more to this thread in the near future. I have been spelunking (exploring its contents at a deep level) recently, and I have discovered many interesting things it has in common, and that are very different, from later kindle models.

What made me more interested in this device is that I found an online store that has replacement roller switches for only $0.99 plus a couple dollars shipping. I ordered one, but before it arrived my roller switch became less flaky and now works quite well. After the replacement switch arrived, examination shows that it is indeed old technology -- MECHANICAL switches, which cleaned themselves (wiping off metal surface oxide) with use. It took a LOT of use for it to become reliable again, so perhaps taking it apart and cleaning the switches with "Tarn-X" (or other metal tarnish remover) would have worked better and faster.

Also, this device contains a small LCD panel (two pixels wide and 100 pixels tall) to the right of the eink display, just above the roller switch. The LCD has a white background, and active pixels are small squares that are perfect mirrors. Sadly, when sitting on the table reflecting my ceiling, the LCD background is almost a perfect match for my reflected ceiling. Depending on time of day, I need to hold the kindle at various angles (preferably reflecting a much darker or much lighter object off the pixels) to make it viewable. This LCD is used as a progress bar (hence 100 pixels tall for percentage), and as a "busy" indicator (bottom 2x2 pixels), but especially for normal usage, it contains a 2x1 marker used to select RIGHT-JUSTIFIED menu items. I suspect this very-early eink device used this LCD because they may have been worried about wearing out the eink by drawing interactive highlighted menu items on it instead of the LCD. As seen in later kindle models, this turned out to be a non-issue, and later kindles do not need an LCD panel in addition to the eink.

Another thing is that the flash memory is NOT eMMC, and does not contain its own embedded processor to manage write wear-levelling and bad block relocation. Instead, these things are managed by a proprietary Samsung XSR device driver, providing both raw block management layer (bml) devices for read-only partitions, and sector translation layer (stl) devices for writable partititons. For some reason, I can only backup bml partititons with dd (even bml partitions underlying stl partititons like /opt and /mnt/us). Because of block relocation, those partitions are specific to a particular flash with its own collection of bad block and write wear-levelling relocations. Therefore I also tarred up the corresponding mounted filesystems. All the read-only (raw) partitions seem to be squashfs, whereas /opt is ext3 and /mnt/us is vfat. One of the partitions that I backed up is not mounted, nor in mtab, so I am not yet sure what format it contains.

One particular thing to note about jailbreak compatibility is that the K1 does NOT contain a /var/local partition -- config vars seem to be stored in /opt instead.

Also, there is no five-way pad -- only the up-and-down roller button, and no arrow keys. To be compatible with most hacks, they would need to support arrow-keys using WASD keys, or perhaps the roller button could do horizontal scrolling while the PREV-PAGE button is pressed.

Also, this device uses the older Apollo eink controller which only supports two-bit pixels (four pixels per byte, 4 grey levels). I will need to update my gmplay dithering to support 2-bit pixels. EDIT: Done!

And BTW, I now have a working KUAL extension for my kindle video player and some of my native mode video demos (which I will post later).

Enough for now. More later in this thread. This is a fascinating device -- apparently relatively rare these days (perhaps discarded when seldom used roller switches oxidized and became unreliable). These go for more than their original $399 price on amazon (more than $1000 in some cases) though there are a few on ebay right now for less than $30.

I plan to support this model, so we may need to add a K1 prefix to this forum and to the master index wikis (see the sticky).

Comments are welcome in this thread.

[geekmaster]

My K1 is running old firmware (ver 1.0.8). When I started playing with it (radio switch off), I did a backup of the filesystem. Recently, I turned it on for a few seconds so the time and date could be updated (no longer 1970). Then I did another backup. Yesterday I noticed a "Your kindle has been updated" document on it, but the firmware version was still 1.0.8 (as shown in the settings menu). I compared backups, and I see that MANY files are different. Most of the executables are different (presumably recompiles at least), and what is strange is that many lib (.so) files were previously text loader script files (containing the name of a parent executable .so file), and now they are all binary files (with ELF header).

I am curious why amazon made all these OTA changes to my device without changing the firmware version number...

[NiLuJe]

I recently did a round of 'charge all the Kindles', and I can concur on your observation on charging times when starting from a flat battery .

If possible, waiting for the framework to reboot, but even before that, just a hard-reboot and re-tripping the "low battery" check helps.

I can also confirm that my new motherboard deals with some of those crappy USB controllers much, much better than my old desktop. I haven't had one downgraded to low-speed like I consistently used to .

[geekmaster]

The eink framebuffer is /dev/fb/0, not /dev/fb0 as used on the newer kindles. The eips command uses different parameters than its newer cousins.

The eink driver in rootfs seems more concerned with screensaver management than with controlling the eink display device.

As I recently discovered, it is incredibly easy to drive the bare eink displays you can get on ebay for $15 or less (k5 replacement displays) with a simple $3 "ESP" computer (with wifi):
http://essentialscrap.com/eink/waveforms.html

Some "compatible" eink displays have a couple extra control lines (presumably for addressing quadrants in larger displays):
https://spritesmods.com/?art=einkdisplay

These displays are very easy to control with a handful of GPIO pins, but only in saturated black and white. It is greyscale that is complex, requiring "waveforms" (timing tables that vary with mfg batch and with temperature).

To get grey pixels, you drive the pixel saturated (either black or white) and then the other direction with a short pulse (pulse duration sets grey level, but varies with temperature as sensed by a thermistor mounted on the display).

Because the displays require different timing at different temperatures, and also per-device, the waveform tables are stored in a writeable chip mounted on the flex cable of the display. Some displays come with this chip erased, but there are workarounds in these forums, if you are concerned about greyscale quality (as used in font rendering).

The reason these devices vary in timing is that they contain a myriad of tiny spheres sandwiched between the top and bottom glass (or plastic) plates. These beads contain a mixture of oil and black and white charged particles. The black particles are negatively charged and attracted to a positive electrode, while the white particles are positively charged and attracted to a negative electrode.

The displays contain a grid of electrodes on both the top and bottom, a pair of electrodes for each pixel position on the display. The electrodes can be set to either +15v or -15v. When top and bottom electrodes are both +15v or -15v (or both 0v when the display is off), no change occurs to the display pixel. With top electrode at +15v and bottom at -15v, the black particles rise to the top and form a black pixel. It takes time for the particles to travel from one surface to the other until it becomes saturated (all black or all white). To get grey, you saturate the pixel in one direction, then give it a short pulse in the other direction to get only SOME of the particles to switch positions. The time it takes for the particles to move is determined by voltage differential and by time, with oil viscosity being a major factor in particle travel speed. And oil viscosity varies with manufacturing and with temperature, hence the "waveform" tables for greyscale management.

Again, when using saturated pixels (pure black and white), there is no need to first saturate the pixel in one direction before setting it to a grey value, and therefore the display can be operated much faster (as used in my native mode demos and kindle video player).

If y'all are interesting in hearing more about my K1 spelunking adventures, please comment with encouragement. I have learned a lot, and I have a lot to share, if it is worth my time (i.e. sufficient endorphine-inducing encouraging feedback).

[knc1]

Check the lowest, oldest, layer of electronic things in your storage - -
Back in the days when televisions had mechanical tuners, tarnished contact points (even though gold plated) where a recurring problem - -
And the industry had a "tuner cleaner" spray for fixing them.
You might even have some at the bottom of your oldest pile.

= = = =

You may have discovered what Lowrey learned the hard way back in the '70s - -
There are some plastics (as used in their keyboard contact supports) that will 'out gas' over time, a gas that will corrode gold (which their contacts where plated with).

I spent a summer working for a Lowrey dealer = going to people's homes and disassembling their organ, using a tarnish remover on the keyboard contacts, and if the people where nice to me - putting the sucker back together.
(It was about a five hour job - the factory never thought those contacts would have to be cleaned.)

[geekmaster]

The K1 does not use a FreeScale SoC, and does not support USB downloader mode. I tried all the buttons and keys just to see, while doing a hard reset. The USB vid/pid did not change, so as suspected, no USB downloader mode.

I repackaged NiLuJe's "Dummy Test Hack" from here, so it would run on my K1. This resulted in a number of updates to the kindletool to properly work on Win x64 versions, so I could keep working on my win7 x64 laptop. I am happy to say that the mingw kindletool works great on x64 windows at this time.

I modified the script to give a dir listing of the entire directory tree, and then to dump out various scripts in the file system, and to display various /proc information.

I later started over with a new script, and because I am using it to explore the K1, I named it "k1snoop". It contains an install.sh that runs when you copy the package (k1, ota) to the userstore (or to the installed SD card) and do UYK (Update Your Kindle).

I found that later kindles require OTA2, but the K1 requires OTA update*.bin files.

I am now writing my install script log files to "mnt/us/documents/k1snoop_<version#>" so they are viewable in the kindle document reader, but I set the font (aA key) to its smallest size to minimize wrapped lines.

After I figured out how to use eips (it works rather differently here), I also write some progress and log contents to the eink display. I can modify the framebuffer (/dev/fb/0) and use either eips or writing a 1 to the einkfb proc to force a display update.

As mentioned previously, the embedded apollo eink controller only supports 2 bits per pixel (4 shades of grey). I have not yet tested to see if the eink drivers do a fast refresh when the display contains only saturated black and white pixels, as is done for newer kindle models. I plan to do that soon -- I want my kindle video player working on this too. In fact, I plan to package my player as an update.bin file so it can be run from UYK on compatible kindles, with NO mods required to the filesystem on the kindle (no jailbreak or root shell required). Later, I want a native menu system to aid exploring the kindle, which also runs with no filesystem mods.

Exploration revealed that this K1 does not contain support for usbnetwork (RNDIS). There is no g_ether USB gadget. There is a g_serial gadget, but according to the dmesg logs, it is used by the 3G (EVDO) modem. There is also no wifi support. However, it does support an SD card, so we can get wifi by using a wifi SD card. I prefer using a hacked version of the Transcend SD wifi card, so I can SSH into the SD card processor (also running its own linux). See HACKING TRANSCEND WIFI SD CARDS for details.

The search commands (starting with ~debugOn) do not have "usbNetwork". However, the DO have "Terminal", which presumably starts a shell on the internal serial port (available on a connector accessible under the easily removable back external cover, where you also insert the optional SD card).

Regarding SD cards, though it is claimed at MR that the K1 recognizes 16GB SDHC, it does not support any of the microSDHC cards in my collection, but all the full-sized SD cards (and SDHC) I have work fine. Because microSD is not required to support SPIO (one-bit serial) access mode, I wonder if the K1 is using SPIO to access the SD port. That would make it slower than 4-bit mode, but still very useful.

Because USB networking (i.e. RNDIS) requires support compiled into the linux kernel, I suspect that compiling an adding a compatible g_eth kernel module would not work. Therefore, I plan to go really old-school, and do a "shared file" (mailbox style) interactive shell. This involves a pair of log files for input and output, with each side "tail following" its input log. On the K1, the bash shell would receive commands from its file (written to by the host PC), and it would write its output to the other log file, which the host would follow and display. The downside is that you need some hackery to defeat 4K buffering when writing to a pipe or a file. Even line buffering could be a problem for non-line-oriented character output in programs such as "top" or "nano". However, such a "mass-storage mode terminal" would be useful even on newer model kindles.

Defeating linux stdio buffering is an age-old headache for linux fans, usually involving "screen" or "stdbuf" or "unbuffer", but these are not installed in my K1, and I have not yet been able to successfully have my update.bin install.sh script run my own executable, or script, or even to source my own script into install.sh. That seems strange because install.sh is called by the "otaup" script, and it sources (existing) files just fine. I need to investigate more...

More later, chores to do now...

[geekmaster]

I finally got my update*.bin install.sh script to execute another script (/mnt/us/RUNME.sh). The key was that after seeing how all the amazon/lab126 scripts installed on my K1 habitually used full absolute paths on everything (data files, executables, scripts, everything) and wondering why, I stumbled across a comment in a script saying to use full absolute paths because "relative paths are unreliable". Well, aparently so, even when I can see the file in the current working directory with "ls -lash" and it tests TRUE with [ -f file ], but yet I was unable to execute or source it.

I changed my code to use a full absolute path to the RUNME.sh file in my current working directory, and it executed just fine (displaying its news on the eink display). Yay! One more step forward! I suspect that I can source files this way too (but using '. </path/file>' instead of 'source </path/file>').


I now have an Update*.bin that does nothing but execute /mnt/us/RUNME.sh if it exists. This could launch an interactive menu, once I figure out the keyboard codes.

So far, I have not found a proc or other way to interact with the keyboard directly (no /dev/input/event devices and no obvious /proc interfaces). The K1 does have a "waitforkey" command, but it does NOT wait for just any key and return its keycode. Instead you must supply the keycode you want to wait for, and it waits for only that key. Which means you cannot easily use it to discover keycodes in a while loop, where you just echo the returned keycode.

I am considering a way to leverage the only way I know to determine a pressed key, by "bending" this limited "waitforkey" command. I plan to launch a bunch of background "waitforkey" commands, one with each possible keycode, followed by an echo of that (input) keycode into a temp file. I can monitor that temp file in the foreground, displaying whatever was last put into it by one of the background "waitforkey" processes. Then I can press all the keys and discover their keycodes. No, I did not find the keycodes in the GPL source, nor in any of the scripts (except for the "R" key, as used in u-boot).

With the limited knowledge I have discovered, can any of y'all think of a better simpler way to discover K1 keycodes? I am all ears (or all thumbs, as the case may be).

[geekmaster]

Exploring the K1 scripts last night, that I previously archived as part of my backup procedure, I learned a few things. One was that I should always use full absolute paths (not relative such as "./script.sh", or even "sh script.sh"), as mentioned previously in this thread.

I also learned how to explore the unusual (for kindles) filesystem and flash storage. Here is a manual (PDF file) from Samsung, for those interested (this filesystem is common on Samsung smartphones):
http://pdfstream.manualsonline.com/b...1cf720b9eb.pdf

I added some code as used in K1 scripts to my "k1snoop" script. Here are the results:

cat /proc/rfs/bmlio

minor       position           size    blocks       id
   1: 0x00000000-0x00180000 0x00180000     12        3
   2: 0x00180000-0x00300000 0x00180000     12       17
   3: 0x00300000-0x00480000 0x00180000     12       16
   4: 0x00480000-0x005c0000 0x00140000     10       15
   5: 0x005c0000-0x00700000 0x00140000     10       14
   6: 0x00700000-0x01500000 0x00e00000    112        8
   7: 0x01500000-0x02400000 0x00f00000    120        9
   8: 0x02400000-0x03a00000 0x01600000    176       10
   9: 0x03a00000-0x0fa00000 0x0c000000   1536       11
  10: 0x0fa00000-0x0fa40000 0x00040000      2        4

(0) bad mapping information
  No  BadBlock   RsvBlock
   0:     1354      2006 
  0: OneNAND 256MB 1.8V

 BML code : out

This information tells us a number of interesting things. One is that the flash block size is 0x2000 (128K) bytes. Another is that there is a bad block @ 1354 (which appears to be inside block device ID 11, the largest partition mounted as /mnt/us). The bad block contents on my specific onboard flash device were relocated to reserved block 2006. That suggests that whatever partition contains block 2006 (partition ID 3) is a reserved partition for bad flash block relocation by the sector translation layer (stl) filesystem driver. There are other small partitions of the same size, perhaps also reserved for special use by STL (including sector remapping metadata).

The only partitions normally mounted are for /mnt/us (rw,vfat,stl), / (ro,squashfs,blm), /mnt/dc (ro,squashfs,blm), and /opt (rw,ext3,stl). I was hoping one of them might be a diags partition, though for all I know now, some of them may contain boot kernels (and I saw potential evidence that one might be the initrd (initial RAM disk) used to boot the kernel. More investigations to follow.

The code that mounts /mnt/us is a LOT more complicated than that for newer kindles, with all sorts of management for both the raw block device and the sector translation layer, with a lot of processing going on to determine locations and sizes, with sane fallbacks for cases where not available (in cases where /mnt/us gets reformatted). This code also give hints about how I should be able to mount (or unmount) STL (sector translation layer) devices so I can get contiguous backups. Even though there is only one bad block on my device, it is likely that sectors were remapped for write wear-levelling, making the raw underlying block device images I now have a bit scrambled for my purposes. A number of the BML devices failed with "dd", and none of the STL devices could be backed up with "dd" (yet). Hopefully using some of that info (as posted above in this post) may help.

TTYL

[geekmaster]

Weird. I stripped down the install script that WAS able to execute RUNME.sh when found, so it is quite simple, and now though it finds RUNME.sh, trying to do "sh /mnt/us/RUNME.sh" fails with a "not found" message, just like prior testing. I am using full absolute paths this time too. I am attempting baby steps from what works to an interactive cmd shell via shared files on /mnt/us/. Another step back... Perhaps it may work "more better" after I get some sleep? Things on this K1 are certainly puzzling at times...

[NiLuJe]

@GM: Try using an absolute path for the calling interpreter, too? (i.e., /bin/sh /mnt/us/RUNME.sh)

[geekmaster]

I figured it out as I was falling asleep last night. It fails when scripts are at /mnt/us (userstore) or even if I copy them to /tmp and set the +x flag, but it succeeds when scripts are at /mnt/mmc (SD card).

I began using an SD card for my installs when I was dumping partition images, to minimize write wear on the embedded flash device. Then I noticed that scripts could run (from SD card).

I was getting annoyed at how long it takes for windows to mount the drive letter for /dev/mmc, and also how long it took to eject the device so I could safely unplug USB (the K1 does not leave usbms mode until cable unplugged, not just ejected). I quit using the SD card, then noticed sourced or shelled scripts were failing again. Perhaps the kindle really IS using (one-bit) SPI mode to talk to the SD card, as I guessed because it does not support my microSD cards (in SD adapters).

Anyway, when I want to run scripts, they need to be on SD card until I figure this out.

I will try /bin/sh. I see that plenty of built-in scripts do exactly that, even after adding things to the PATH var. Comments in some scripts suggest that lab126 staff were also fighting this battle back in the day...

For now, I will insert an SD card when I want an install script to run something from it, and leave the card out when I want to switch quickly in and out of usbms mode.

What is also strange is that I have seen amazon install scripts that DO copy scripts to /tmp and set +x on them, but doing exactly that failed for me. They must do this as a workaround for the problem I am experiencing. Installing from SD card is convenient, but leaving an SD card plugged in all the time is annoying when I want to repeatedly use usbms mode. I need to find my wifi SD card, so I can access the card from wifi instead of slow-to-change usbms mode (with the added benefit that the kindle framework will be running even while I access the SD card contents). With a wifi SD card, I will not need to even bother using usbms mode...

EDIT: I found my Eye-Fi wifi SD card, but it is not known to be hackable (though there are replacement server hacks). It will do for now (though I prefer root shell on all my devices)...

[NiLuJe]

@geekmaster: Does the K1 has the same fuse proxy layer as later devices? If it does, does running stuff from base-us instead of us work better?

[geekmaster]

Originally Posted by NiLuJe

@geekmaster: Does the K1 has the same fuse proxy layer as later devices? If it does, does running stuff from base-us instead of us work better?

There is not base-us, so no fuse. It does have the added complexity when mounting of dealing with both the raw bml0/9 device AND the sector-translated stl0/9 device, along with extra wrangling with the device drivers to perform the mount. The /mnt/mmc device (SD card) is much simpler because mmc (SD) devices contain their own embedded processor and firmware to hide sector translation from the host (kindle in this case). OTA update mode is not particularly special in that "otaup" is called inside the framework script when the framework exits successfully (presumably when UYK is selected). A restart from the menu must not return "success" or otaup would run.

Also, on the k1, the update*.bin package is NOT removed (only update_system*.bin firmware updates are removed) in the framework script. My install.sh now removes all update*.bin files from /mnt/us and /mnt/mmc before doing anything else. Because my script kept running when waking up from screensaver mode, it may also be necessary for install.sh to clean up the files (install.sh etc.) from the /tmp folder as well.

Exploring the K1 is certainly a learning experience, considering all the differences (and similarities) with other kindle devices. This weird problem of not being able to run anything from /mnt/us is puzzling considering that the files are both found (-f) and executable (-x). I need to try running a copy from /tmp again, because existing scripts do that so it must work -- just need to figure out what I did wrong in my attempt.

Also, the Eye-Fi card is a big PITA, insisting that I log into their cloud service just to configure my SD card. I tried a password reset on my Eye-Fi account, but they never sent me the confirmation email. I really need to find my Transcent wifi SD card, which should be in my box of Raspberry Pi stuff (if I can find it)...

EDIT: The kindle does not keep the SD card powered up for any significant amount of time, which only makes sense when conserving battery, but that makes a wifi SD card useless in this context. And all variations of trying to run a script from /mnt/us (or copying it to /tmp first) have failed (again). They run from /mnt/mmc (SD card) so I guess I will just have to get used to waiting a long time for SD card mount and eject over USB. I detest "giving up" on something that SHOULD work, but I have spent enough time stuck on this (for now)...

[geekmaster]

Okay, I have had some limited success having my update.bin file run a RUNME.sh script on /mnt/us, BUT it cannot log to a file, or create a file, on /mnt/us. Any command that redirects STDOUT to a file fails. Even "touch /mnt/us/LOGFILE.txt" fails (with an "fd error"). However, I now know it runs because I am using eips to write to the display from RUNME.sh, and I can see that just fine. RUNME.sh also seems to fail when reading files from /mnt/sh, so though I have made progress, there are still some bugs to work out.

After the framework shuts down on the K1, things get rather weird, it seems. When I thought that scripts on /mnt/us were not running, I was apparently wrong -- they just cannot leave any evidence (other than on eink) that they ran. Strangely, running /mnt/mmc/RUNME.sh works as expected, so I knew it was working straight away.

More investigation to come. Again, my goal is a simple "shared file" terminal program to provide root shell without network or serial port access. This could also be useful for other kindle models, provided you can launch an update*.bin install package, or other method to launch a script on the kindle such as "certain secret persistent kindle bug" (no hints for lab126) commands.

[geekmaster]

I tried exporting USB mass storage from my update install script, but it only exported the 0MB version used for battery charging. I suppose there must be some flag file or env var I need to set or unset. I wait for the "R" key pressed on the K1 keyboard before restarting (borrowed from a script).

Any clues from readers would be more than welcome, because I also have other tasks demanding my time...