k3flasher, a USB download mode utility

[geekmaster]

@hawhill: Is adding K4/K5 USB Downloader mode to this project on the schedule yet? Great project. Looking forward to a unified K3/K4/K5 "button" solution (eventually).

Now... who can find the "magic key" for the DX and DXG? And what is the USB VID/PID for DX/DXG USB Downloader mode?

[knc1]

Originally Posted by arooni

Also can't get it to compile (yes I did install the latest libusb library before trying to compile. I also ensured that I added /usr/local/lib (where the libusb libraries were installed to, to my .bashrc file to set the path correctly).

Only problem with that, this is Linux, not Windows.
Nothing about the executable search path ($PATH) affects locating libraries either at build time or at run time.

At build time -
The tool chain looks in both "trusted" library locations: /lib and /usr/lib by default.
That search path and order may be changed by compiler options (which get passed on to the program linker) with the -L/path option(s).
Similar for locating the header files (which your program isn't finding), only then the option(s) is -I/path
Plus, the order of the options matter, because the linker is single pass. Unless the single pass behavior is altered with the start group/end group options.

Prefix_Index -> Tools_Index#Technical_References
And you will find a link to the gcc on-line manuals.
Go RTFM

[arooni]

Originally Posted by knc1

Only problem with that, this is Linux, not Windows.
Nothing about the executable search path ($PATH) affects locating libraries either at build time or at run time.

At build time -
The tool chain looks in both "trusted" library locations: /lib and /usr/lib by default.
That search path and order may be changed by compiler options (which get passed on to the program linker) with the -L/path option(s).
Similar for locating the header files (which your program isn't finding), only then the option(s) is -I/path
Plus, the order of the options matter, because the linker is single pass. Unless the single pass behavior is altered with the start group/end group options.

Prefix_Index -> Tools_Index#Technical_References
And you will find a link to the gcc on-line manuals.
Go RTFM

You're right I was confused about how general compilation works and how the $PATH var does not affect it.

That being said, the Makefile was broken, and wouldn't compile on my computer and presumably the patcher's box... and thanks to a patch its now fixed... see earlier posts. or as you would put it, "Go RTFT".

[knc1]

Originally Posted by arooni

You're right I was confused about how general compilation works and how the $PATH var does not affect it.

That being said, the Makefile was broken, and wouldn't compile on my computer and presumably the patcher's box... and thanks to a patch its now fixed... see earlier posts. or as you would put it, "Go RTFT".

I did. And the patch only made the changes related to my comment about how you "thought" you had "installed" the library.

[hawhill]

Please don't let this get into a sad story. I'm more interested in actual usage reports. And, of course, patches.

[arooni]

Well I tried today... looks like it did attempt to flash, but I don't think any attempt was ever 100% successful. It's still bricked

You can see the output here: https://gist.github.com/53c711088172cfb8ff9b

[hawhill]

The output you provide is quite helpful. Thanks. The first run failed with an error due to the device disconnecting. However, the second run, starting at line 59, was successful! The other runs were failing, though.

However, I think you're flashing the wrong file. Luckily it's not big enough to harm the flash sections following the kernel, but now I can definitely tell you that your kernel is broken (i.e. no kernel at all anymore). You need to extract update packages with kindletool (https://github.com/yifanlu/KindleTool), _within_ them is a raw kernel image (file named "uImage", without extension). As there was no easy way of flashing a raw kernel image before, both yifanlu and seaniko provided theirs as update packages.

So you did go the absolutely correct steps here, just using a wrong file to flash. I've been there, I flashed a lot of crap even to address 0x00000000, luckily, it is nicely recoverable.

I'm happy to see that even for a device in a tight reset loop there seem to be "windows of opportunity" to at least flash a full kernel image size's worth of data. That's actually nice.

[geekmaster]

I added this thread to the "References" section of the "Simple Debricking" sticky thread, listed as "K3flasher (K3 USB debricking)".

[arooni]

Originally Posted by hawhill

The output you provide is quite helpful. Thanks. The first run failed with an error due to the device disconnecting. However, the second run, starting at line 59, was successful! The other runs were failing, though.

However, I think you're flashing the wrong file. Luckily it's not big enough to harm the flash sections following the kernel, but now I can definitely tell you that your kernel is broken (i.e. no kernel at all anymore). You need to extract update packages with kindletool (https://github.com/yifanlu/KindleTool), _within_ them is a raw kernel image (file named "uImage", without extension). As there was no easy way of flashing a raw kernel image before, both yifanlu and seaniko provided theirs as update packages.

So you did go the absolutely correct steps here, just using a wrong file to flash. I've been there, I flashed a lot of crap even to address 0x00000000, luckily, it is nicely recoverable.

I'm happy to see that even for a device in a tight reset loop there seem to be "windows of opportunity" to at least flash a full kernel image size's worth of data. That's actually nice.

Thanks for your feedback. Got yianfu's package. Trying to extract the Kindle package using:

./kindletool create ota --device k3g ~/development/KindleTool/KindleTool/images/

Cannot read input.
Segmentation fault

I get a seg fault. Not sure; why I think I'm following the programs syntax. Luckily enough, this one compiled without any issues ;p. Ideas now?

[geekmaster]

Originally Posted by arooni

Thanks for your feedback. Got yianfu's package. Trying to extract the Kindle package using:

./kindletool create ota --device k3g ~/development/KindleTool/KindleTool/images/

Cannot read input.
Segmentation fault

I get a seg fault. Not sure; why I think I'm following the programs syntax. Luckily enough, this one compiled without any issues ;p. Ideas now?

NiLuJe posted a FIXED version of that tool.

[NiLuJe]

@arooni: Use my fork: https://github.com/NiLuJe/KindleTool, yifan's original is known to behave strangely regarding to the CLI on some (most?) recent Linux distros.

(My best guess would be because messing with getopt's optind in a certain way or optreset seems to be a potentially unportable BSD hack :? [Yifan's main dev platform is OS X])

Or get a static build from here.

Or, as it's not an OTA2 package, use the goold old python packer .

[arooni]

EDIT: Static compiled version appeared to work. Now to flash it.
EDIT2:

I was able to create a kernel image with the static builds NiLuJe provided using:
./kindletool create ota --device k3g . updatek3g.bin

And the flash result:

LilArooni ~/development/k3flasher: sudo ./k3flasher mx35to2_mmc.bin program 0x00041000 updatek3g.bin
W: cannot find device (is it in USB loader mode? are you root?) - waiting for it.......
I: success.
I: found suitable device
E: wrong transfer length, wanted to receive 8 bytes but received 4 bytes.
I: above error can be ignored, it's due to the device being in ROM kernel mode
I: RAM kernel should be running now. Trying to re-open device: .
I: got it.
I: size is not a multiple of 512
I: flashing 0x00019b29 (=105257) bytes
I: wrote 0x00019b29 (=105257) bytes, waiting for completion...
I: flashed 0x00010000 (=65536) bytes
I: flashing of 0x00019b29 (=105257) bytes complete
==========================================
And the Kindle? Still looks bricked to me. Still stuck on library screen and reset does nothing. Not exactly sure why the updatek3g.bin file is only 103KB.... maybe I did something wrong at that step.

[NiLuJe]

@arooni: That's not what hawhill asked . The goal was to *unpack* the update package to get to the uImage.

Alternatively, if you were trying to flash yifan's kernel, just get it from the original package here: http://yifan.lu/p/kindle-custom-kernel/, it's in the src folder.

And for seaniko7's kernel (https://www.mobileread.com/forums/sho...d.php?t=175602), you want to do a convert or an extract with KindleTool, NOT a create .

┌─(niluje@ajulutsikael:pts/11)─────────────────────────────────────────────(~/Downloads/kindle_3.3_shell_kernel(1))─┐
└─(0.85:44%:19:42:%)── kindletool extract update_kindle_3.3_shell_kernel_k3g.bin Kernel             ──(Thu, Jul 12)─┘
Extracting update package update_kindle_3.3_shell_kernel_k3g.bin to Kernel
Bundle         FC02
Bundle Type    OTA V1
MD5 Hash       1da9a04d2ef32921fa6cee017712c141
Minimum OTA    0
Target OTA     2147483647
Device         Kindle 3 Wifi+3G
Optional       0
x flash-custom-kernel.ffs.sig
x kexec.sig
x update-kernel.md5.sig
x update-kernel.tar.gz.sig
x support/kernel-flash.sig
x flash-custom-kernel.ffs
x kexec
x update-kernel.md5
x update-kernel.tar.gz
x support/kernel-flash
x update_kindle_3.3_shell_kernel_k3g.dat
x update_kindle_3.3_shell_kernel_k3g.dat.sig
┌─(niluje@ajulutsikael:pts/11)─────────────────────────────────────────────(~/Downloads/kindle_3.3_shell_kernel(1))─┐
└─(1.10:44%:19:42:%)── tar tvzf Kernel/update-kernel.tar.gz                                         ──(Thu, Jul 12)─┘
-rw-r--r-- intromatyk/intromatyk 2687396 2012-04-17 01:31 uImage
-rw-r--r-- intromatyk/intromatyk      42 2011-01-13 22:50 uImage.partitions
-rw-r--r-- intromatyk/intromatyk   88984 2009-12-31 01:07 kexec

[arooni]

@NiLuJe

Thanks for your help.

I downloaded the uImage from the src directory of yianfu's kernel. I wasn't able to flash it (see below). Is it worth trying a different kernel; is my kindle messed up, or is the software not flashing correctly?

sudo ./k3flasher mx35to2_mmc.bin program 0x00041000 uImage
W: cannot find device (is it in USB loader mode? are you root?) - waiting for it.....
I: success.
I: found suitable device
E: wrong transfer length, wanted to receive 8 bytes but received 4 bytes.
I: above error can be ignored, it's due to the device being in ROM kernel mode
I: RAM kernel should be running now. Trying to re-open device: .
I: got it.
I: size is not a multiple of 512
E: wrong transfer length, wanted to receive 8 bytes but received 4 bytes.
E: aborting. It is suggested you power-cycle the device.

[geekmaster]

If the image is not a multiple of 512, it might be necessary to pad it with /dev/zero.