Unbriking Kindle DX

[twobob]

I'll PM him a bump on it.

[geekmaster]

Originally Posted by knc1

...
Because I think the DX is one of the machines which alternates between the two boot image files on the machine with each hard re-start.


The image files look as if they have two (2) complete sets of U-Boot environment and kernel images.
All stored in a device physically different than the device that has your broken system image.
...

NiLuJe says here that one of the two kernels is for update mode, which is used for flashing an updated kernel for normal boot mode:
https://www.mobileread.com/forums/sho....php?p=1026623

In which case it is probably not alternating between boots.

[twobob]

I don't know about the alternation at boot discussion but I think I recall that usage from Yifan Lu's docs somewhere too, if that lends credence any.

[knc1]

Originally Posted by geekmaster

NiLuJe says here that one of the two kernels is for update mode, which is used for flashing an updated kernel for normal boot mode:
https://www.mobileread.com/forums/sho....php?p=1026623

In which case it is probably not alternating between boots.

So the two capture files will help to determine that.

One factor against there being two kernels, each for a specific purpose, is that in the image files under discussion here, the two kernels are bitwise (and checksum wise) identical.
Page back a bit in the thread.

PS: If you quote someone, please do not change the text of the quote. That includes any emphasis. I already have include the emphasis that I felt was required in my original.

The normal practice when adding emphasis in written communications is to make a note of "emphasis added".

[geekmaster]

Originally Posted by knc1

So the two capture files will help to determine that.

One factor against there being two kernels, each for a specific purpose, is that in the image files under discussion here, the two kernels are bitwise (and checksum wise) identical[COLOR added for partial reply matching, not "emphasis"].
Page back a bit in the thread.

PS: If you quote someone, please do not change the text of the quote. That includes any emphasis. I already have include the emphasis that I felt was required in my original.

The normal practice when adding emphasis in written communications is to make a note of "emphasis added".

I remove text in a quote that is not relevant to my reply, which is recommended in the MobileRead forum guidelines for posting here.

I mark portions of quotes and portions of my replies in matching colors, to show what part of my reply refers to which part of the quote. The colors are for matching, not for emphasis.

If you follow the link I provided, it links to yifalu's website, where he uses a script that flashes BOTH kernels with his custom kernel, which explains why they would be identical.

P.S. I commonly correct common obvious spelling errors in quotes too, instead of inserting "[sic]" after unchanged errors. Embedded editorial comments in a quote, such as [Emphasis added], only makes it harder to interpret the technical content. But color changes do not affect comprehension, so I use that...

[twobob]

I always liked [sic]

It makes me think of Bill and Ted if they were cool today, which is never a bad thing.
: )

[geekmaster]

Originally Posted by twobob

I always liked [sic]

It makes me think of Bill and Ted if they were cool today, which is never a bad thing.
: )

Ted is still cool, except now he goes by the hacker alias "Neo".

Here is the new "Bill and Ted 3" promo:

http://www.billandted3.com/

[knc1]

mtd_0.bin - U-Boot
mtd_1.bin - uImage kernel
mtd_2.bin - Machine specific data
mtd_3.bin - U-Boot
mtd_4.bin - uImage kernel
mtd_5.bin - "unused" (@ 0, rest of device erased)
mtd_6.bin - "diag" (@0, rest of device erased)
mtd_7.bin - 40 bytes of ARM code, marked as: TMGKTrampoline v1.0.0
mtd_8.bin - "unused" (@0, rest of device erased)

Next, puzzle over those two (2) capture files to be posted RSN.

[NiLuJe]

Take my double kernel comment with a grain of salt, it's been a good while since I wrote that, and it may not be entirely accurate ^^.

The only thing I'm sure of is that there are two kernels .

[knc1]

Originally Posted by NiLuJe

Take my double kernel comment with a grain of salt, it's been a good while since I wrote that, and it may not be entirely accurate ^^.

The only thing I'm sure of is that there are two kernels .

The "flash update" utilities are implemented as shell scripts.
I have not studied them enough to know in what order they are called.
But they do share a common organization structure:
They update U-Boot (if available)
They update the uImage (if available)
They update the system image (if available)

And there is scripting for each "set" of U-Boot / uImage
(They could have done with fewer scripts if they had duplicated the thing I labeled: "machine specific data" - but they didn't.

Since all of this is in the mtdblock device, none of which has a file system that could be mounted during normal operation - it should be "safe" to re-write the contents at any time.

In the case of this thread - all that is lacking is the storage addresses as seen from U-Boot and this problem is solved.

There are two DX(G) machines involved - one with a working serial port, reported as booting to u-boot (although I suspect it is actually booting the kernel and the kernel is doing a panic halt) ;

The other machine - without a serial port, that works normally.
Separated by at least 6 time zones.

It isn't exactly a "real-time interactive" troubleshooting session.

It may take a bit of "peeking" into /dev/mem on the working machine for "known values" of the various images.
And then some confirmation by "peeking" from U-Boot (which should be the same - /dev/mem translates from virtual to physical addresses).

At this point -
getting closer to that noob's DX cure.

[cavorite]

Originally Posted by knc1

I want to get some more information from your machine.

So lets use that functional serial interface port and whatever terminal emulator you have.

Get your communications all setup with the serial port, Kindle, terminal emulator, etc.

Enable the emulator's capture to file feature.
In (Linux) minicom it is in the configuration panels as "Capture File"
In (Windows) ??? I am not sure, it will depend on the application but should be somewhere - perhaps in configuration - session - logging.
Sorry, knowing what you may be using under Windows would not help me, I would have to look up that application's docs - I don't know windows.

This may give what is required at this point:

• You have communications established over the serial port ;
• You have set up recording the communications to a (capture, log, transcript, whatever) file ;
• Use the: "Hold power switch forever" method of getting the Kindle to do a complete restart ;
• Save the recorded result file ;
• Start another recording file ;
• Repeat the complete restart.

Twice? In two capture files?
Yes.
Because I think the DX is one of the machines which alternates between the two boot image files on the machine with each hard re-start.


The image files look as if they have two (2) complete sets of U-Boot environment and kernel images.
All stored in a device physically different than the device that has your broken system image.


zip or tar/gzip the two files, attach to post.
I expect they will tell me what to either do next or what to ask for next.

File is attached, just one. Took awhile. I'm on a Mac, OSX 10.8, using secureCRT to capture the session. Using FTDI TTL-232RG-VREG1V8-WE converter. Only one file because the system is in a loop and can only be interrupted at the U-boot point. The file has basically one iteration of the loop. Hope the information is helpful in spite of this.

I have a new problem that just ate up an additional couple of hours. My serial port has gone silent. With no changes to hardware setup, I suddenly have nothing coming out of the DX. Tried on two other computers with same result. Holding down power key seems to have no effect, though with enough random keypressing I have got into a reboot to happen, and even a recovery console once, but on DX screen only, silence from serial port.

To cover the obvious, I have examined my soldering and nothing has changed as far as I can see. Rebooted, tried on different computer, checked drivers, checked sanity. Research tomorrow.

[cavorite]

Originally Posted by knc1

There are two DX(G) machines involved - one with a working serial port, reported as booting to u-boot (although I suspect it is actually booting the kernel and the kernel is doing a panic halt) ;

With that, I can perhaps achieve a better description. I believe it does boot the kernel, and without intervention enters a loop as documented in the file I attached above. I can (or COULD) break in at the point where it is possible to enter u-boot. As of now, my serial port appears to have gone silent.

[equinox1]

Try to disconnect your serial cable from DX, connect cable's RX directly to TX and type something. If you will not see echoes - something wrong with your usb2ttl, drivers or COMn settings. If usb2ttl works - try to take DX battery off, let it sit for a minute and connect it back.

PS: after fixing your serial ( I hope) - could you please attach the dump of uboot's "printenv" ?

Originally Posted by cavorite

I have a new problem that just ate up an additional couple of hours. My serial port has gone silent. With no changes to hardware setup, I suddenly have nothing coming out of the DX. Tried on two other computers with same result. Holding down power key seems to have no effect, though with enough random keypressing I have got into a reboot to happen, and even a recovery console once, but on DX screen only, silence from serial port

[geekmaster]

@equinox1: Be sure to fully recharge your battery. A bricked kindle does not "sleep" and can fully DISCHARGE the battery while it is sitting idle. Try keeping the USB cable plugged into a charger or computer while debricking it with the serial port.

Also, several kindle models seem to have unreliable GND connections on the serial port. It helps to have a USB cable attached to the same host PC as the serial adapter (for an extra ground path). Try that.

[knc1]

Originally Posted by cavorite

With that, I can perhaps achieve a better description. I believe it does boot the kernel, and without intervention enters a loop as documented in the file I attached above. I can (or COULD) break in at the point where it is possible to enter u-boot. As of now, my serial port appears to have gone silent.

Correct - with the added problem of there being a coding error in the "panic halt" routine - which is what is looping rather than doing a "panic halt".

Your installed kernel's build date:
Thu Sep 16 14:43:09 PDT 2010

The image file's kernel build date:
Thu Jan 13 20:13:23 2011,

So we can hope that lab126 fixed that problem with the kernel's "panic halt" routine.

Then we get an example of **why** an embedded system should not have two **identical** kernels (when they both have the same identical build error):

Hit any key to stop autoboot:  0 
boot globals: computed residue = 0x7FA247FC, checksum = 0x0A0B6EA2
boot globals: failed
Boot globals invalid. Clearing
Using fallback kernel. Clearing boot globals
Booting Secondary kernel...
## Booting image at a0400000 ...

Which, if we could believe what is reported ....
Means that U-Boot sees mtd_4.bin portion of the mtdblock device mapped into memory address: 0xA0400000

We will not use that information until it can be verified on a known working machine!
I'll get with twobob (out-of-band, we have other than Mobileread communications) to work out that verification.

Note also that lab126 rebuilt the U-Boot image:
Yours: U-Boot 1.3.0-rc3-lab126 (Sep 16 2010 - 14:42:54)
Image file's: U-Boot 1.3.0-rc3-lab126 (Jan 13 2011 - 18:13:00)

Translation:
There is hope for your machine still, all we have to do is a full firmware update using the working U-Boot command prompt.

Next:
Keep that DX battery charged.
DO NOT use the Amazon wall charger!
If you can use one of the "high current" USB ports on your Mac, that is alright.
Otherwise, just let it trickle charge from the USB port of a powered USB hub.

Why:
There is a combination hardware/firmware error in the Kindle's charging circuit, that combined with the Amazon wall charger that causes the Kindle's charge controller to self destruct.

That happened to my K3 while I was watching it with the factory battery management diagnostic.
Amazon has "fixed" that problem in the Kpaperwhite by not shipping the Amazon wall charger and re-writing the "how to keep it charged" section of the Kpw user manual.

Edit:
You could use a small expect/send script on that serial port to watch for: autoboot:
And send a character at the correct time to get into the U-Boot menu.
See: http://www.nist.gov/el/msid/expect.cfm
It is one of the very basic *nix tools, I am sure you can find a MacOSx version.