Unbriking Kindle DX

[cavorite]

@equinox1 - everything was working with no problem a few days ago. Nothing has really changed other than whatever is happening inside the DX softwarewise. I've verified that the driver is present and my comm programs are seeing and connecting to it as a serial port. One program, coolterm, goes as far as to have led-like status indicators for tx, rx, cts, dtr, etc., and I can see activity on the TX line when I type on the keyboard, but no activity on RX, i.e. no character echo back from the DX.

@geekmaster - aware of the battery problem, and have been careful to keep the DX connected to a charger. I have a yellow power led, for what that's worth. I did plug the DX usb into the mac to improve the ground path, but not a fix for the communication problem.
I should note that previous to this (just a few days ago), this was working without a problem (as far as serial comms) and I cannot fathom what might have changed hardware wise.

@knc1 - I've been using a spare ipad charger, which has a higher output current spec to allow the ipad to fast charge. I believe this is equivalent to the high current usb ports on the macbook pro I have. Now have the DX connected to the mac in order to have a reinforced ground for the TTL converter, as geekmaster suggested.

Nice "solution" to the charger problem from Amazon...

[knc1]

Originally Posted by cavorite

@knc1 - I've been using a spare ipad charger, which has a higher output current spec to allow the ipad to fast charge. I believe this is equivalent to the high current usb ports on the macbook pro I have. Now have the DX connected to the mac in order to have a reinforced ground for the TTL converter, as geekmaster suggested.

Nice "solution" to the charger problem from Amazon...

Isn't that a nice solution?
Hey, if its broke, don't ship it.

What your doing should be alright, those are probably 300ma maximum ports - just like the macbook "high current" port.
The Kindles (the few models I know about) can handle a 500ma charge rate.
The Amazon charger can output 800ma - and the firmware wasn't written to detect/correctly handle an "over current" condition.

The Kindle battery (at least the ones used in models capable of using 3G) can source/sink a 3amp (3000ma) current. So even the Kindle's "fast charge" wall charger wasn't coming close to "fast charging" that battery.

[cavorite]

The Kindle depends on the charger to limit output current? No internal current limiting??
What an interesting design choice.

[knc1]

Originally Posted by cavorite

The Kindle depends on the charger to limit output current? No internal current limiting??
What an interesting design choice.

No.
The battery management has a programmable current limiter.
The firmware (at least that of the diagnostic routine) tests for:
off, 100ma, 500ma, other
And the author assumed "other" would be between off ... 500ma.

The diagnostic routine (with the battery charge level at 30%) was reporting a charge current of 800ma (the maximum the charger could output).
And at that point, I didn't realize the hardware could not handle that - I could have just pulled the plug and saved my Kindle.

The firmware needed:
off, 100ma, 500ma, (other <= 500ma), over-current
tests in its case statement.

Eventually, Amazon will get back all Kindles that shipped with that firmware error and an Amazon wall charger.
At least the author of that routine put his name on it - they know who's paycheck to deduct for the self-destructing Kindles.

[cavorite]

So this was corrected at some point? And I am also surprised the hardware guys did not build in a failsafe. Fuses are cheap.

[knc1]

Originally Posted by cavorite

So this was corrected at some point? And I am also surprised the hardware guys did not build in a failsafe. Fuses are cheap.

I haven't returned my K3 yet, nor had time to look into just what failed. It may have an SMT fuse in it (that is now blown).

I still have about 2 months left on the warranty before I have to RMA the K3 - I may get a chance to check out the details of what happened.
Have just let myself get sidetracked from that problem.

OH, ( <- big oh)
It is not the charger circuit that died, it was some of the circuitry shared with the USB port. I can still charge the battery, it is just that the USB port no longer functions.

My battery is fully charged, and removed from the Kindle.
I just need to get a RoundToIt before the battery self discharges or the warranty expires on the Kindle.

[knc1]

The posted source code bundles that span the time of interest here are:
2.3, 2.5.5, 2.5.7, 2.5.8
There is no 2.4 posted.
As far as the kernel and u-boot are concerned, 2.5.7 and 2.5.8 used the same source code.

So unpack the archives into three parallel directories (2.3, 2.5.5, 2.5.8) and from their parent, apply: "sha1deep -r 2.3 2.5.5 2.5.8 | sort -n"
ref: http://minimodding.com/FW121NTSCcomp...llel_sub-trees

Then jumping to step 10 & 11 -
Generate an input file for the report generator and then generate the set of reports.

(I get to jump around in the directions because I wrote them, the first time reader should start at the top of the page.)

I.E: For the case of address mappings, we are only interested in files that are the same. For the case of kernel source code errors, we are only interested in files that changed.

In case the reader is wondering, there are 82,749 files in the input file list. Pardon me for not in-lining it here.

Since the file gallery at MiniModding.com is a developer's only resource -
I will attach the LFA application to this post.

The most complete set of directions on the use of LFA are the comments in the script file itself. (mmg is a developer's web-site; "read the code" is understood to always apply.)

[twobob]

now just need to get to a box that can read such files. doh. *drives 100 miles*

[knc1]

@twobob: Naw, I did that, see attached.

I recognize that the amount of documentation on LFA is a bit light, and what there is, is about auditing mips binaries.

So with the sources of DX(G) firmware as a test example ;
Using LFA under Lua-5.2 for the first time (it was written for Lua-5.1) ;
Without installing lfa.lua ;

A quick and dirty example :

Un-archive the parts of the three Amazon release bundles into parallel directories:

core2quad dxg $ ls -ld 2.*
drwxrwxr-x 4 mszick mszick 4096 2012-09-28 10:44 2.3_399380047
drwxrwxr-x 4 mszick mszick 4096 2012-09-28 10:44 2.5.5_495460008
drwxrwxr-x 4 mszick mszick 4096 2012-09-28 10:45 2.5.7_550650009
drwxrwxr-x 4 mszick mszick 4096 2012-09-28 10:45 2.5.8_555370010

We already know that the kernel and u-boot sources in 2.5.7 and 2.5.8 are the same - so we ignore 2.5.7 here.

Use sha1deep to build a list, by sha1sum of the three directories of interest, then sort that into a text file:

core2quad dxg $ sha1deep -r 2.3_399380047 2.5.5_495460008 2.5.8_555370010 | sort -n >ku_sources.sha1

Looking at the --help output of lfa, we can see we will need two magic numbers:

core2quad dxg $ /usr/local/bin/lua ../lfa/file_audit-1.0/lfa.lua --help
    --help        -    This text.
    -c Number    -    of records in each output file.
    -f Number    -    of the first path element of the target tree.
    -h        -    This text.
    -i Input_File    -    Without this option, reads stdin.
    -o OutBase    -    Base filename used for output filename construction.
    -p Number    -    of the path element containing the package name.
    -r CN        -    Common file names contained in package tree.
    -r CS        -    Common hash sums contained in package tree.
    -r List        -    of reports to produce from: CN,CS,NO,NP,SO,SP
    -r NO        -    File names ordered by number of occurances.
    -r NP        -    File names ordered by package name in package tree.
    -r SO        -    Hash sums ordered by number of occurances.
    -r SP        -    Hash sums ordered by package name in package tree.

There is a more detailed description of those as comments in the Lua script file.

Displaying the text file and grabbing a copy of the first record:

core2quad dxg $ less ku_sources.sha1
000ad28937f69ea948b567ae0ec973dfd022b592  /home/mszick/Downloads/dxg/2.3_399380047/linux-2.6.22/arch/powerpc/platforms/cell/Kconfig

We find the package name in field 5 of the record and the fileset name in field 6 of the record.
(Which gives us the: -p 5 -f 6 options.)
We know that we are using a more modern than version 2.4 of OpenOffice (and forked clones thereof), and we know there are less than 90,000 records in the input file (wc -l) so set the record count per output file to 90,000 (the -c 90000 option).

Toss in the input filename, the output filename prefix and the list of reports to generate gives us (in all its glory):

core2quad dxg $ /usr/local/bin/lua ../lfa/file_audit-1.0/lfa.lua -i ku_sources.sha1 -p 5 -f 6 -c 90000 -r CN,CS,NO,NP,SO,SP -o dx_ku_sources-

And in a handful of seconds, the script hands us back:

core2quad dxg $ ls -l dx_ku*
-rw-rw-r-- 1 mszick mszick  9976015 2012-09-28 12:36 dx_ku_sources-CN-p0001.csv
-rw-rw-r-- 1 mszick mszick 11894411 2012-09-28 12:36 dx_ku_sources-CS-p0001.csv
-rw-rw-r-- 1 mszick mszick 10077500 2012-09-28 12:36 dx_ku_sources-NO-p0001.csv
-rw-rw-r-- 1 mszick mszick 12380206 2012-09-28 12:36 dx_ku_sources-NP-p0001.csv
-rw-rw-r-- 1 mszick mszick 12005340 2012-09-28 12:36 dx_ku_sources-SO-p0001.csv
-rw-rw-r-- 1 mszick mszick 18754600 2012-09-28 12:36 dx_ku_sources-SP-p0001.csv

Standard comma separated values with a single record label header.
Suitable for import into your favorite data file viewer.

Here, I used OpenOffice to read the files, then output them with a touch of formatting as *.ods (Open Document Spreadsheet) files.

core2quad dxg $ ls -l *.ods
-rw-rw-r-- 1 mszick mszick 1835625 2012-09-28 13:09 dx_ku_sources-CN-p0001.ods
-rw-rw-r-- 1 mszick mszick 2089383 2012-09-28 13:00 dx_ku_sources-CS-p0001.ods
-rw-rw-r-- 1 mszick mszick 1763603 2012-09-28 13:10 dx_ku_sources-NO-p0001.ods
-rw-rw-r-- 1 mszick mszick 4217524 2012-09-28 13:13 dx_ku_sources-NP-p0001.ods
-rw-rw-r-- 1 mszick mszick 2015423 2012-09-28 13:18 dx_ku_sources-SO-p0001.ods
-rw-rw-r-- 1 mszick mszick 4674535 2012-09-28 13:24 dx_ku_sources-SP-p0001.ods

All ready to be browsed for things that are the same and things that are different (at the checksum level) of the three source bundles.

And/Or
For import into your favorite Database System (MySQL can import either the *.cvs or the *.ods format files for example).

Sorry folks, even though an *.ods file is another name for *.zip - this web-site does not know that, so the compressed files got compressed (again) for up-loading.

[knc1]

SO (checkSums by order of Occurrence) report, with selection of counts == 1 or 2 (of the tree of three).

How to read it:
Single occurrence, release 2.5.8 == New for 2.5.8
Single occurrence, release 2.3 == Dropped after 2.3

Double occurrence, release 2.3 & 2.5.5 == Dropped from 2.5.8
Double occurrence, release 2.5.5 & 2.5.8 == Added after 2.3

Double occurrence, release 2.3 & 2.5.8 == lab126 on 2.5.5 party night.

Etc. etc. etc.

No, it does not provide you with the "answer" -

Yes, it does narrow the number of files to be studied with more conventional source review tools from tens of thousands to only a couple of hundred.

Sorry, once again I had to compress a compressed file.

[knc1]

Not much of any significance (unless your trying to stop that autoboot: message):

core2quad dxg $ diff -u 2.3_399380047/uboot-1.3.0-rc3/include/configs/imx31_mario.h 2.5.8_555370010/uboot-1.3.0-rc3/include/configs/imx31_mario.h
--- 2.3_399380047/uboot-1.3.0-rc3/include/configs/imx31_mario.h    2009-10-21 16:05:34.000000000 -0500
+++ 2.5.8_555370010/uboot-1.3.0-rc3/include/configs/imx31_mario.h    2010-12-14 12:55:36.000000000 -0600
@@ -90,7 +90,7 @@
 /* this must be included AFTER the definition of CONFIG_COMMANDS (if any) */
 //#include <cmd_confdefs.h>
 
-#define CONFIG_BOOTDELAY         3
+#define CONFIG_BOOTDELAY         1
 #define CONFIG_BOOT_RETRY_TIME     15        /* reset if command-line is idle for too long */
 #define CONFIG_BOOT_RETRY_MIN     5        /* cannot set "bootretry" to less than 5 seconds */

[knc1]

This one makes a difference, worth upgrading for:

--- 2.3_399380047/linux-2.6.22/arch/arm/mach-mx3/mario.c    2009-10-21 16:07:11.000000000 -0500
+++ 2.5.8_555370010/linux-2.6.22/arch/arm/mach-mx3/mario.c    2010-12-14 12:57:23.000000000 -0600
@@ -721,6 +721,21 @@
     gpio_activate_audio_ports();
 }
 
+static void pmic_rtc_unconfigure(void)
+{
+    /* Ack the RTC timer interrupt */
+    pmic_write_reg(REG_INTERRUPT_STATUS_1, 0, 0x2);
+
+    /* Mask the RTC alarm interrupt */
+    pmic_write_reg(REG_INTERRUPT_MASK_1, 0x3, 0x3);
+
+    /* Clear out the RTC Alarm time register */
+    pmic_write_reg(REG_RTC_ALARM, 0x0, 0xffffffff);
+
+    /* Clear out the RTC Alarm Day register */
+    pmic_write_reg(REG_RTC_DAY_ALARM, 0x0, 0xffffffff);
+}
+
 /*
  * mx31 power off (halt)
  */
@@ -728,6 +743,8 @@
 {
     t_pc_config pc_config;
 
+    pmic_rtc_unconfigure();
+
     pc_config.auto_en_vbkup2= 0;
     pc_config.en_vbkup2= 0;
     pc_config.vhold_voltage = 3;

[equinox1]

cavorite, you have two choices - listen for people and do what they recommend or stop writing here and do whatever you want

1. Terminal program status indicator doesn't show HARDWARE status - it just shows logical state your OS port, not usb2ttl in your case.

2. You have to disconnect your usb2ttl from DX and connect RX to TX wire of usb2ttl together. This way you will test HARDWARE of your usb2ttl - if TX sends AND RX receives data. If you will see echo - it means that TX sends ELECTRICAL signal and RX is able to receive it and send back to USB. I suspect that you burned your usb2ttl RX port (or both TX/RX). If you will see the echo - it means that usb2ttl is OK and you burned your DX serial port (at least TX) or something wrong with your uboot (low chance).

I'm not very familiar with uboot internals but looking at environment variables I think it's possible to set uboot wrong way so it will configure serial interface for wrong speed/port.

Originally Posted by cavorite

@equinox1 - everything was working with no problem a few days ago. Nothing has really changed other than whatever is happening inside the DX softwarewise. I've verified that the driver is present and my comm programs are seeing and connecting to it as a serial port. One program, coolterm, goes as far as to have led-like status indicators for tx, rx, cts, dtr, etc., and I can see activity on the TX line when I type on the keyboard, but no activity on RX, i.e. no character echo back from the DX.

[geekmaster]

Originally Posted by equinox1

cavorite, you have two choices - listen for people and do what they recommend or stop writing here and do whatever you want ...

That seems a bit harsh. It looked like cavorite was being responsive to our requests.

[cavorite]

@equinox1 - You make some interesting assumptions. My experience with the Coolterm program and usb/serial converters is that the status indicators correctly report the state of the serial interface as communicated by the converter. Have you had situations when Coolterm did not do this correctly?

I said that I could see TX activity only, which could mean either the DX wasn't talking or the FTDI converter wasn't listening. I rule neither possibility out at this stage. I completely agree with you, connecting the converter's TX and RX lines will be an absolute test, locating the fault in either the converter or the DX. Haven't had the opportunity to do it yet, but it's definitely my first step.

If you felt as if I was not listening to you, that definitely was not the case, so perhaps next time give me the benefit of the doubt, ok?