Alternate "Simple" debricking methods for K5-Touch, K4-Mini, & K3-Keyboard

[geekmaster]

For my K4 custom u-boot, I added a like that inserted my hard-coded (string constant) values immediately after reading the value from mmc. There is a function for reading mmc.

It was able to boot up that way, even though it did not write to mmc. The K4 needs to know the serial number AND pcbsn to decide how to init DRAM.

[adi23]

Originally Posted by geekmaster

For my K4 custom u-boot, I added a like that inserted my hard-coded (string constant) values immediately after reading the value from mmc. There is a function for reading mmc.

It was able to boot up that way, even though it did not write to mmc. The K4 needs to know the serial number AND pcbsn to decide how to init DRAM.

In /common directory i have found the idme functions (something like idme_find_var, idme_set.., i don't have the code right now). I was thinking maybe i can set the vars from to code before the system check them (with idme_set..()). Anyway before this i must try to build U-boot with no errors.

[knc1]

Originally Posted by adi23

In /common directory i have found the idme functions (something like idme_find_var, idme_set.., i don't have the code right now). I was thinking maybe i can set the vars from to code before the system check them (with idme_set..()). Anyway before this i must try to build U-boot with no errors.

Back up one page to see my post at the bottom of the prior page.

[geekmaster]

The serial output shows that u-boot reported "Invalid board id! Can't determine system type for RAM init.. bailing!", which is what I got on my K4. It reports that message when deciding how to init DRAM, based on the pcbsn idme var. Right after the code reads that var (using idme_find_var?) I changed the return value to my original pcbsn. I also did that for the other known idme vars. Then it booted, and I used "idme -d" from SSH to write those to mmc.

But I was able to use MfgTool to run my custom u-boot.

EDIT: If you cannot build your own, it may be possible to patch my u-boot binary, replacing my idme vars with your own.

[geekmaster]

Originally Posted by adi23

I have recovered my old values from a log file, but i don't understand how should i set the values with the idme command.

Thank you

Please PM me your values, and I will patch them into my custom u-boot binary that forces them. Just rename the MfgTool diags.bin file to diags.orig.bin, and then put the new diags.bin with your idme vars patched in that folder. Then boot diags with MfgTool.

EDIT: In the diags Settings menu, the pcbsn idme var is called "PCBA ID". The only idme vars I need to patch are serial and pcbsn.

EDIT2: I just tested this. It boots to whatever mode the bootmode idme var and/or ENABLE_DIAGS file selected, just like a normal bootup. WARNING: It actually wrote the idme vars. My demo kindle serial and pcbsn changed to the forced values from my other kindle. I have a backup though, so I will change them back...

[geekmaster]

I just patched the serial and pcbsn in my custom u-boot binary, replacing some of my hex characters with ascii zeroes. It does not boot. They must contain a check-digit or something. And of course it WROTE the idme vars, so it is bricked until I patch some real values in my u-boot and let if write those to mmc...

Fun, huh? Anyway, it works right when you patch in REAL serial and pcbsn (even if from a different kindle).

[knc1]

Does the u-boot have access to its environment before it initializes ddr ram?

If so, put the desired values in the environment and pull them from there.
Then people would not have to re-build the u-boot binary, just hex-edit the saved environment strings (hmm... we could probably even script that number edit).

[ixtab]

Originally Posted by geekmaster

I just patched the serial and pcbsn in my custom u-boot binary, replacing some of my hex characters with ascii zeroes. It does not boot. They must contain a check-digit or something. And of course it WROTE the idme vars, so it is bricked until I patch some real values in my u-boot and let if write those to mmc...

Fun, huh? Anyway, it works right when you patch in REAL serial and pcbsn (even if from a different kindle).

I don't think that you can just "binary-patch" u-boot images, I think there's a CRC32 (or whatever other) checksum or something... I vaguely remember that I had to recompile u-boot images if I even wanted to change a single character in a path. I may be wrong though.

[geekmaster]

Originally Posted by ixtab

I don't think that you can just "binary-patch" u-boot images, I think there's a CRC32 (or whatever other) checksum or something... I vaguely remember that I had to recompile u-boot images if I even wanted to change a single character in a path. I may be wrong though.

You are probably right. I will try to patch the source and rebuild it. I want ID info with lots of zeros, so it is obvious that it needs to be changed from the DIAGS settings menu (or SSH "idme -d" command). I have a working one, but it has MY idme vars in it...

It only needs serial and pcbsn to boot. It "permanently" changed those values on my demo K4 (which I used to test it because that u-boot has K4 values in it). Now I have a pair of K4s with the same serial and pcbsn. I should change it back before they "phone home".

@knc1: The u-boot running on the kindle does not have access to environment variables on the host PC, where MfgTool was running when it pushed the hacked u-boot to the kindle. I was planning to try appending a text config file to the u-boot image file though (and adjusting the flash header length to compensate, so it all gets sent over USB). I hope the CRC check does not use the flash header length...

[knc1]

Originally Posted by geekmaster

@knc1: The u-boot running on the kindle does not have access to environment variables on the host PC, where MfgTool was running when it pushed the hacked u-boot to the kindle. I was planning to try appending a text config file to the u-boot image file though (and adjusting the flash header length to compensate, so it all gets sent over USB). I hope the CRC check does not use the flash header length...

No, I am not that much of a beginner -
The **U-Boot Environment Variables** in the **U-Boot** build!
As in:

#define CONFIG_EXTRA_ENV_SETTINGS                                       \
        CFG_BOOTFILE                                                    \
        CFG_ROOTPATH                                                    \
        "netdev=eth0\0"                                                 \
        "nfsargs=setenv bootargs root=/dev/nfs rw "                     \
                "nfsroot=${serverip}:${rootpath}\0"                     \
        "ramargs=setenv bootargs root=/dev/ram rw\0"                    \
        "addip=setenv bootargs ${bootargs} "                            \
                "ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}"      \
                ":${hostname}:${netdev}:off panic=1\0"                  \
        "addtty=setenv bootargs ${bootargs} console=ttyS0,${baudrate}\0"\
        "flash_nfs=run nfsargs addip addtty;"                           \
                "bootm ${kernel_addr}\0"                                \
        "flash_self=run ramargs addip addtty;"                          \
                "bootm ${kernel_addr} ${ramdisk_addr}\0"                \
        "net_nfs=tftp 200000 ${bootfile};run nfsargs addip addtty;"     \
                "bootm\0"                                               \
- - - -

And yes, you have to either patch the checksum or do it the "lab126 way" and no-op the checksum tests.

Which is how they get away with bspatching the u-boot and uImage files and still be able to load them.
If you use the various mkimage tools, you will find that the patched images fail the checksum tests but load and run anyway.

[eureka]

Originally Posted by knc1

And yes, you have to either patch the checksum or do it the "lab126 way" and no-op the checksum tests.

Which is how they get away with bspatching the u-boot and uImage files and still be able to load them.
If you use the various mkimage tools, you will find that the patched images fail the checksum tests but load and run anyway.

JFYI, U-Boot was never changed by any KT firmware update. KT's OS hasn't access to U-Boot paritition (read access, at least; it looks like idme tool can write to it).

Recent versions of kernel can access eMMC boot parition, but this functionality isn't present in KT's kernel/modules.

[kasumi]

Originally Posted by geekmaster

Another success report copied from a PM debricking session:Factory reset erases and repopulates the USB drive with default files. You need to reinstall stuff.

Wow I just saw my name up there in the debricking report!

Since it took me hours to find, here's a bit more information should someone find themselves in the same situation.

Model: Kindle 4.1

Problem: Repair Needed screen comes up after restart screen stops halfway on the progress bar. No USB drive detected.

Bricked Reason: Main kernel not corrupted, just entered wrong framework start path

Solution: http://www.mobileread.com/forums/sho...sh#post1979349 (geekmaster's) MfgTool.exe+data.tar.gz+RUNME.sh

Lesson: Never try to hack your Kindle when you're sleepy and don't give up!!

[twobob]

Originally Posted by kasumi

Snip
Lesson: Never try to hack your Kindle when you're sleepy and don't give up!!

Hacking tired Kills (kindles)! Take A Break!

[Speaker_unclear]

Hello World,
I am, as of last week, the proud owner of a brick.
My delightfully bricked brick sometimes also goes by the name of KT: 5.1.2.
Also included in my enviable Brick Technology are the following modifications:

• Jailbreak
• Jailbreak Patch
• Kindlet Jailbreak Patch
• Collections Manager
• Font Hack
• GUI Launcher w/Launcher Collection
• Leafpad w/sh script altered to launch matchbox keyboard
• XTerm Kindlet Launcher
• Altered /usr/share/webkit-1.0/pillow/javascripts/search_bar.js file
• (Store button altered to launch xTerm Kindlet)
• Diags Partition +ssh
• Extend w/original .img file (the huge one)

Some time ago I bricked up my kindle--black screen of death--which I was able to correct with MFG tool, flashing diags +ssh, and reinstalling main partition (re: simple debricking thread).

then, after I got it unbricked, and Sometime during the modifications listed above, I no longer had access to 3G

At work the other day, I very much wanted to look some stuff up on Wikipedia, so, stupidly and without thinking, I did a 'reset device' to see if maybe that would get me 3G. har har har, of course this did not help anything at all.

The kindle was acting flakey after that, claiming I did not have the developer flag anymore, though I did according to the settings > device info.
I figured it would be easier to start over on the whole shebang from scratch, then to try and diagnose what had blown the thing's mind so drastically, as it seemed to be totally knackered. (by totally knackered, I just mean that it was starting to chug, seeming generally flaky)

I tried to enable USBnetworking, but it no longer worked on the main system, so I booted into diags, but it no longer worked there. I had intended on reinstalling the main partition from a back up, but, ho-hum, diags froze up. I couldn't hard reset, I couldn't SSH, I couldn't do jack. It stayed frozen in diags until the charge battery screen came on. I am assuming that the diags log was deleted in the system reset, so that might be *part* of what caused the flakiness, but it is now at a point where I am truly 100% bricked out, or so it seems.

I have since scoured the forums for some kind of insight, but what I've seen is "charge it in the wall" and "charge it in fastboot mode" First I tried keeping it plugged into the wall for a good 9 hours. The orange light came on when it was plugged in, and then it would go off after about an hour of charging. I kept it plugged in. After that, I attempted to reboot it into its regular boot mode via MFG, but it failed, (I don't remember the error). Then I tried to boot it into fastboot, with the intention of trying to charge it in fastboot, but MFG tool, however, errored out (again, I don't remember what the error was that caused it to fail) and failed to get anywhere.

BTW, seems obvious, but worth note, when I plug it into my computer, it does not show up at all as a removable device. the computer just acts like it doesn't exist.
I will run it through those steps again when I get a moment and post the errors that MFG tool spews at me when I try to use it. Those are really all that I have to go on unless I try to get at the serial port, but even then, I don't know what that would accomplish without any power.

I am at a loss. I don't know how to even begin to diagnose this thing if I cant even get it to a point where it will hold a charge enough to provide any sort of means to get in. I really would like to own a functioning kindle. really, like, a lot.

Traditionally I like to maintain my status as a lurker until I have something to contribute to a community, and I like to be fairly self-sufficient until I get a feel for things, but at this rate I've been trying for days and am about ready to give up. figured it was time to throw in the towel and just ask. Noob here. Any thoughts or advice? I'm out of ideas.

[knc1]

Step one: Re-charge the battery.

Yes: I can see in your post that you have already read about that, but now your situation may well be different.

Either (or both) of two things has happened:
The battery has been over-discharged enough that it can no longer hold enough charge, OR
The battery has been discharged to the point that the internal battery management can no longer re-charge it.

Remove battery from Kindle, recharge it with an "Amazon Approved" re-charger.
That is the "official" company line.

For DIY situation - you can use any general purpose Li-Ion charger, OR
You can "fake it" -
Use a constant current, voltage limited, charging source;
Recharge at 30% of the listed (on the battery) one-hour rate for two hours.
Do not exceed a terminal voltage of 4.2 volts under charge;
Do not let the temperature of the battery raise enough to damage it.

That **might** (if not suffering from lack of charge holding capacity) get the battery back to a condition where you can get the Kindle into the "fastboot" re-charge mode.