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

[Pyrocitus]

Using DD worked a charm, the step i was missing was the copying of the mmcbkl0p1 image to the kindle in USB drive mode.

Enable USB mode on diagnostics mode was not working, I circumvented this by performing the operator test suite to the end where it says to export the xml file and temporarily activates USB storage mode and copying over the image then.

Thanks guys, I realised where I went wrong but you managed to tip me in the right direction to gain the knowledge I needed!

[knc1]

Sorry, I couldn't find the "RED, BOLD, FLASH" thingy.

[geekmaster]

Originally Posted by Pyrocitus

Using DD worked a charm, the step i was missing was the copying of the mmcbkl0p1 image to the kindle in USB drive mode.

Enable USB mode on diagnostics mode was not working, I circumvented this by performing the operator test suite to the end where it says to export the xml file and temporarily activates USB storage mode and copying over the image then.

Thanks guys, I realised where I went wrong but you managed to tip me in the right direction to gain the knowledge I needed!

Skipping steps can be a problem. Forgetting to put the eggs in your omelette can make a less than satisfying breakfast.

Is your kindle repaired and working now?

[Pyrocitus]

Ah it was not an issue of skipping steps, i did not initially realise that the kindle was formatted into two separate kernels and two separate partitions, perhaps this should be made clearer? Or maybe it is just me.

At some point I must have tried to flash the main partition with a diag image or vice-versa which threw a spanner in the works causing the customer partition not ready error.

[geekmaster]

Originally Posted by Pyrocitus

Ah it was not an issue of skipping steps, i did not initially realise that the kindle was formatted into two separate kernels and two separate partitions, perhaps this should be made clearer? Or maybe it is just me.

At some point I must have tried to flash the main partition with a diag image or vice-versa which threw a spanner in the works causing the customer partition not ready error.

The pastebin was made clearer about a week or so ago. Is it okay now?

I ask again: Is your kindle working now?

[Pyrocitus]

Yes, kindle is fully operational now and down from 5.1.1 to 5.0.0 which I wanted for greater compatibility with extensions.

EDIT: And has just self-updated to 5.0.4 to no ill effect with Lifan's screensaver hack 2.0 and launcher installed.

[geekmaster]

Originally Posted by Pyrocitus

Yes, kindle is fully operational now and down from 5.1.1 to 5.0.0 which I wanted for greater compatibility with extensions.

EDIT: And has just self-updated to 5.0.4 to no ill effect with Lifan's screensaver hack 2.0 and launcher installed.

Now that is what I wanted to hear! Your success report has been added to "the list". Congratulations on your successful kindle debricking.

[Loko_bielsa]

Well...

thx geekmaster for the help. I could fix the kindle touch this afternoon. The guide is totally fine, except I made mistakes in copying files to USB mode (copy an image from 70 mbs, rather than the image of 350 mbs).

Anyway, thank you very much for your help and patience. The translation of the guide commits the weekend, because I have a test in college.

[geekmaster]

Originally Posted by Loko_bielsa

Well...

thx geekmaster for the help. I could fix the kindle touch this afternoon. The guide is totally fine, except I made mistakes in copying files to USB mode (copy an image from 70 mbs, rather than the image of 350 mbs).

Anyway, thank you very much for your help and patience. The translation of the guide commits the weekend, because I have a test in college.

Please post here the results of your afternoon debricking session with the correct length image. Thanks.

[ixtab]

EDIT: Please see second edit below.

I guess something went terribly wrong here.

We finally got our hands on some 5.1.1 images. I first installed only the main partition (over the previous 5.1.0), and it worked almost smoothly. ("almost" meaning that everything except the Wifi would work). The Wifi wouldn't work because of some missing kernel symbols. Makes sense if you're not running the matching kernel.

So I went through the entire process with mfgtool and fastboot to flash the main kernel. I didn't change anything else. And now here's the situation:

• Resetting to "HID mode" works.
• Booting to fastboot mode works.
• Booting to diags works.
• Booting to main doesn't work. There's simply absolutely nothing happening. No flashing of the screen or LED... nothing. Hard resets have absolutely no effect either. The only thing that I can get back into is the HID mode.

So I thought: ok, whatever. Let's try to flash the previously working (main) kernel back onto it. It still doesn't work.

Since I can boot to diags, I can verify (using getkernels.sh) that the kernel on the device is actually the one that was flashed (md5sums match).

So... the big question is: WTF is going on here?!
Does anyone have a clue, or a hint on what could be done to troubleshoot this? As said, fastboot and diags work completely normally. Just trying to boot to main (whether using mfgtool, or by rebooting from diags) does absolutely nothing at all. For the record: I also tried to erase p3, though I didn't expect it to change anything (and it doesn't). The filesystem on p1 looks ok (and as said, it worked before).

Note: I only have USB access to the device (no serial cable or so).

Any help is really appreciated.

EDIT:
I may have found the reason for this. In fact, re-installing 5.1.0 (kernel AND partition) did NOT work. But installing 5.0.0 got the device back alive. The funny thing is the following... I flashed this 5.0.0 kernel of 5090176 bytes:

md5sum kt_5.0.0-kernel.img
ade683d89aa95b452e73778dd30058cd *kt_5.0.0-kernel.img

However, for this kernel, the getkernels.sh returned a kernel of 5090304 bytes:

md5sum main_kernel.img
f51c5478ffe8e8729c55a1988efe5dd5  main_kernel.img

I have verified that it is indeed the same file, but with a few trailing junk bytes.
My suspicion is now that the kernel is somehow checked for integrity (CRC32 or whatever, need to look this up) and is simply thrown away if something is wrong. But I need to look further into it. I'll go kamikaze and try again now with 5.1.0 and 5.1.1

[knc1]

5090304 - 5090176 == 128
Too unreasonable for that to be a "random" difference.
I think you will find that the "short one" is missing one compressed block of its initramfs.

Even kernels that "don't have an initramfs", have an initramfs that holds the initial /dev/null and /dev/console as a gzip'd, cpio.
If you drop that off of the kernel, it isn't going to boot, it will panic - -
And as you wrote above, you don't have a serial port cable to read the panic message on.

[ixtab]

I think I got it. This was a bitch to figure out, but in the end, it's actually quite simple.

I'll explain it the hard way though. Maybe this can serve as a sort of "tutorial" to some folks about how to approach such things.

Let's recapitulate:
- flashing 5.0.0 with the currently available kernel works
- flashing 5.1.0 does not always work, neither does 5.1.1.
- after some (lots) of initial panic, trial, and error, I came to the conclusion that this has to do with the kernels used. Indeed, with a 5.1.1 partition, and the 5.0.0 kernel, the system will at least try to boot, while it wouldn't do anything with the 5.1.0 or 5.1.1 kernels.

So, wtf? I decided to take a closer look at the kernels with a hex editor, and to make sense of the obfuscated getkernels.sh code (some like to call that "condensed" )

Turns out there is the length of the image (4 bytes) at offset 0xc in every image, and after staring at the code for some time, I finally understood how getkernels.sh used that value to produce files of the corresponding size (rounded up to the next multiple of the block size (1024)). That all looked sort of correct, but the kernels weren't working...

Since the official update for 5.1.0 is available in binary form, and it contains kernel updates as well, I used kindletool to extract that. Simply extracting it, I found a file called "kernelinfo", containg information about one kernel that is flashed during the update. Poking around here and there, some more information appears:
- that particular kernel file is of size 5111808, but its header says 0x4dab40 (5090112). But taking a look at this kernel, this is yet another one, different from the 5.0.0 and the (extracted) 5.1.0 one. In fact, the update installs this kernel in stage 1 of the update, then patches it (using bspatch, if you're interested) during stage 2 of the update (which is contained in payload.bin and is itself an update that can be extracted).
- so I actually did that and patched the stage 1 kernel using the stage 2 patch, and sure enough, I got the same kernel as the getkernels.sh yielded - except that it was a larger file, and that it was actually booting.

Now that I had 3 kernels which were working (and 2 which weren't) I compared the working ones. They're all mostly binary gibberish of course, but at least... if all of those files are larger than what is stated in their header, then what actually IS at the offset indicated in the header? Turns out quite simple: there are 0x40 bytes of obviously meaningful content, then all the rest is filled with 0xFF bytes.

And what about that 0x40 (64)? Why would it state its own length "almost" correctly, but forgetting about those 64 bytes? Let's go back to the beginning of each file, and it suddenly makes sense: There is a 64-byte header, containing information about the name and the size. But the size concerns the payload, which comes after the header.

The grand and simple conclusion: getkernels.sh has to consider 64 more bytes (before the rounding), and all is well.

@geekmaster: would you please update the getkernels.sh script accordingly?

PS: Well, at least now I'm not afraid of mfgtool and fastboot anymore... at all! After all, I've been switching between all 4 modes (USB download, fastboot, diags, main) about a hundred times during the procedure

[geekmaster]

Originally Posted by ixtab

I think I got it. This was a bitch to figure out, but in the end, it's actually quite simple.
...
There is a 64-byte header, containing information about the name and the size. But the size concerns the payload, which comes after the header.

The grand and simple conclusion: getkernels.sh has to consider 64 more bytes (before the rounding), and all is well.

@geekmaster: would you please update the getkernels.sh script accordingly?

Thanks for figuring this out! I am sure glad that kernel images made with getkernels worked as well as they did for as long as they did for as many people as they did. But of course, it is time to redo them with the extra 64 bytes. Sorry about that. It will be fixed today. We need to redo all the kernels in the first post too. Unfortunately, we need to do them from a 32MB mmcblk0 image file, or from REAL virgin kindle (NOT from kindles that have been flashed back from a newer to older kernel). I will see what I can find.

Regarding the condensed/obfuscated code: It really IS true that I can understand code faster and easier when more of it fits on the screen within my field of view with no scrolling. I grew up in the days of 80x25 text screens and programmers such as myself often coded in that style, so it sort of IS my "native language". Adapting to "fluffy" whitespace-riddled code just never worked for me very well. And comments that say something OBVIOUS that is already clear in the code just waste space without adding anything useful. I do add comments where I think they are needed (such as variable definitions, and important code that is otherwise not clear).

EDIT: Part of the apparent "obfuscation" in the getkernels script was that earlier versions scanned for kernel images, in case they moved to another start address in the future. To fix a glitch in version 1.2, 1.3 just used hard-coded start offsets, but the of the OLD (now mosly obsolete) code was left in the script (accidentally complicating/obfuscating it).

EDIT2: Some kernels may be okay (if the 64-byte header fit inside the last written block after padding to the 1K blocksize. I will check them and replace any that may be missing up to 64 bytes at the end.

[flashmozzg]

It doesn't work for me. then i launch fastboot it says: waiting for device.

[geekmaster]

Originally Posted by flashmozzg

Will this work for non bricked but messed up kindles?

Yes. That is a common use for it. You can also use it to restore an OLDER firmware if you do not like a new version.

You can even use this method to flash a firmware image with several common hacks pre-installed (which can be downloaded in the pastebin).