View Single Post
Old 09-28-2012, 09:11 AM   #75
knc1
Going Viral
knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.
 
knc1's Avatar
 
Posts: 17,212
Karma: 18210809
Join Date: Feb 2012
Location: Central Texas
Device: No K1, PW2, KV, KOA
Quote:
Originally Posted by cavorite View Post
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):

Code:
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.

Last edited by knc1; 09-28-2012 at 09:55 AM.
knc1 is offline   Reply With Quote