k3flasher, a USB download mode utility

[geekmaster]

Originally Posted by twobob

Worked example of the k3flasher unbricking a K3 to a 3.0.2 via Linux Mint ...

The pastebin has a 3.4 with jailbreak and combined developer keys preinstalled. I successfully debricked a K3 demo with it. Unfortunately, it is a two-part zip on Mediafire, with that new troublesome 10 downloads/week limitation. Too bad there is no mirror for 3.4+jb+keys... (Hint... Hint...)

[dsmid]

Originally Posted by geekmaster

Too bad there is no mirror for 3.4+jb+keys... (Hint... Hint...)

I would upload it to http://ge.tt/ but the limit prevents me from downloading

[geekmaster]

Originally Posted by twobob

...
Each write cycle is worth 2Mb. so 300 Mb = 150 loops...
each cycle takes about 30 seconds. so 4MB per minute.

681.6Mb = ~341 loops = 170.4 minutes = 2.84 hours

keep waiting... when it's done - reboot.
...

I was thinking we can speed this up in some cases, such as debricking by replacing a damaged partition with a clean copy of the SAME VERSION. All we have to do is modify k3_flasher to READ and compare blocks (perhaps 2MB blocks) and SKIP them unless there is a mismatch. Only write blocks that changed. Reads should be MUCH faster than block erase and write cycles.

Also, it might be worth verifying that the write blocks are aligned to erase block boundaries. If the start address causes an offset, it could be doing slow read/erase/write cycles across the boundaries. Better to align to erase block boundaries to skip the otherwise unneeded read (if they occur). This can be a huge problem for flash drives formatted on XP (the 53 sector/track size) not aligned to flash erase block boundaries. Not sure if a problem here, but worth investigating.

EDIT: What I did not make clear is that each block gets erased and rewritten TWICE when misaligned. Each erase block gets a read/erase/write for the tail end of an overlapped data block, plus ANOTHER read/erase/write for the beginning of the next overlapped data block. Alignment can eliminate not only ALL reads, but also a much slower extra erase and write. It can more than double the speed even when rewriting ALL blocks, compared to misaligned writes.

Whatever the case, more than two hours is too long (especially if it is draining the kindle battery). We should at least skip the write if the block does not need to change. Fast debricking using this would require reflashing an undamaged copy of your bricked firmware version, but that can be arranged.

[geekmaster]

Originally Posted by dsmid

I would upload it to http://ge.tt/ but the limit prevents me from downloading

In progress...

EDIT: (84% uploaded)

[twobob]

Originally Posted by geekmaster

Thoughts on stuff (see below).

excellent thoughts.

[geekmaster]

Originally Posted by twobob

excellent thoughts.

I added an edit to the quoted post to clarify the erase block misalignment problem. It is worth reposting here too:

EDIT: What I did not make clear is that each block gets erased and rewritten TWICE when misaligned. Each erase block gets a read/erase/write for the tail end of an overlapped data block, plus ANOTHER read/erase/write for the beginning of the next overlapped data block. Alignment can eliminate not only ALL reads, but also a much slower extra erase and write. It can more than double the speed even when rewriting ALL blocks, compared to misaligned writes.

Of course, it is better to read and compare first, and NOT write blocks that already contain the desired contents.

[knc1]

Originally Posted by geekmaster

I added an edit to the quoted post to clarify the erase block misalignment problem. It is worth reposting here too:Of course, it is better to read and compare first, and NOT write blocks that already contain the desired contents.

There are advantages to doing that on the host side.
Read the "broken" image to the host, compare by erase block size or a reasonable multiple there-of, only send the blocks that need to be re-written, and then:

Keep the "broken" image so that it can be determined what "broke".
It may be possible to find things that would be "fixable" without a full image re-flash.
Maybe even things that could be prevented to begin with.

[geekmaster]

Originally Posted by knc1

...
The Freescale binary remains a "blob" - just like other firmware blobs.
...

Speaking of proprietary firmware blobs, Broadcom just opensourced their video drivers that were previously available only as a binary blob:
http://www.raspberrypi.org/archives/2221

Let's hope they do this with other devices too, and that other chipset vendors opensource their blobs too.

[twobob]

Originally Posted by geekmaster

Speaking of proprietary firmware blobs, Broadcom just opensourced their video drivers that were previously available only as a binary blob:
http://www.raspberrypi.org/archives/2221

Let's hope they do this with other devices too, and that other chipset vendors opensource their blobs too.

Open source easy-ride Pi owners *grumble grumble*

[shihman]

Hello All:

I am a newbie and read through all Kindle 3 debrick posts and could not make them work. I use an XP machine and OSX Mt. Lion. I have zero background in programming and downloaded K3 flasher and downloaded it but I have no idea how to proceed. I have also tried K3 Noob's Guide and the download files there but XP would not install USB drivers.

Any help would be greatly appreciated! K3 is stuck for days now on boot image with child reading under tree. It cannot be identified on both my machines when connected via USB. Tried resetting, opening it too and removing battery. Nothing works.

THANKS!

[knc1]

Originally Posted by shihman

Hello All:

I am a newbie and read through all Kindle 3 debrick posts and could not make them work. I use an XP machine and OSX Mt. Lion. I have zero background in programming and downloaded K3 flasher and downloaded it but I have no idea how to proceed. I have also tried K3 Noob's Guide and the download files there but XP would not install USB drivers.

Any help would be greatly appreciated! K3 is stuck for days now on boot image with child reading under tree. It cannot be identified on both my machines when connected via USB. Tried resetting, opening it too and removing battery. Nothing works.

THANKS!

Keep it connected to a charger or a powered USB port while waiting to solve this problem! ! ! !

You can't tell what the K3 (or any e-ink machine) is doing until it updates the screen. The e-ink screens are "meta-stable", you could remove the screen (or just the battery) and set it on a shelf, it will continue to display what was last written to it for months (or perhaps years).

[twobob]

chalk me up for one more rootfs wipe.

thanks Hawhill really glad of this tool. went for 3.4 this time

[littelbro14]

So I've searched this entire thread for a solution to this issue. I'm not sure if I'm missing something, but I still haven't found one. I'm on Ubuntu 12.10, 64-bit. I compiled k3flasher from source (couldn't get the provided binary to work, not sure why), and I extracted the RAM kernel myself, directly from the latest ATK exe. Here's my in/output.

root@TARDIS:/home/colten/Downloads/k3flasher# ./k3flasher mx35to2_mmc.bin program 0x00041000 kernel.bin
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.
E: wrong transfer length, wanted to receive 8 bytes but received 4 bytes.
E: aborting. It is suggested you power-cycle the device.

Any help on this would be fantastic....

[twobob]

Originally Posted by littelbro14

So I've searched this entire thread for a solution to this issue. I'm not sure if I'm missing something, but I still haven't found one. I'm on Ubuntu 12.10, 64-bit. I compiled k3flasher from source (couldn't get the provided binary to work, not sure why), and I extracted the RAM kernel myself, directly from the latest ATK exe. Here's my in/output.

root@TARDIS:/home/colten/Downloads/k3flasher# ./k3flasher mx35to2_mmc.bin program 0x00041000 kernel.bin
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.
E: wrong transfer length, wanted to receive 8 bytes but received 4 bytes.
E: aborting. It is suggested you power-cycle the device.

Any help on this would be fantastic....

I recall GM saying something about this kind of thing. but don't recall what.
Assumedly you built the latest one from GIT so it's not an old version.

Ram kernel should be fine. it would just bork much earlier otherwise.

Hopefully one of the heavyweights can step up and guide you better.

EDIT: Is there any reason you are not just saying:
./k3flasher mx35to2_mmc.bin program kernel kernel.bin

???

[littelbro14]

Originally Posted by twobob

I recall GM saying something about this kind of thing. but don't recall what.
Assumedly you built the latest one from GIT so it's not an old version.

Ram kernel should be fine. it would just bork much earlier otherwise.

Hopefully one of the heavyweights can step up and guide you better.

EDIT: Is there any reason you are not just saying:
./k3flasher mx35to2_mmc.bin program kernel kernel.bin

???

Actually, I assumed the .zip from the first post was up-to-date, so I built from that. Could you direct me to the git repo?

As for the actual command, didn't know I could do that, but it makes it a bit easier. Thanks.