I'm afraid my problem isn't about computer anymore, it's very deep inside my Kindle. That's sad. Because geekmaster promissed that Kindle will always be able to boot in fastboot mode (at least first time before it gets modified using fastboot) and I now can see it's wrong. I hope it will turn out that problem is in me doing something wrong, but right now I have no idea.

BTW: Where is geekmaster? His last post here was a pretty long time ago (for him ). I hope he can say something useful about my problem.

I'm afraid my problem isn't about computer anymore, it's very deep inside my Kindle. That's sad. Because geekmaster promissed that Kindle will always be able to boot in fastboot mode (at least first time before it gets modified using fastboot) and I now can see it's wrong. I hope it will turn out that problem is in me doing something wrong, but right now I have no idea.

BTW: Where is geekmaster? His last post here was a pretty long time ago (for him ). I hope he can say something useful about my problem.

I said it will always be able to boot into USB Downloader mode, even if you corrupt the flashboot code stored in mmc. You can flash another copy of bist u-boot to get fastboot working again.

But we have a problem (that is fixable). I successfully used yifanlu's fastboot to repair my k4nt before I owned a touch. My k4nt 4.0 was hopelessly bricked and nothing worked. I bought a replacement k4nt that came with 4.0.1. When I made my first modified u-boot, it was for k4nt only, and I added code to it to repair my k4nt, including writing a valid pcbns to it so that u-boot could decide how to initialize the hardware and continue, instead of just halting. I then booted to fastboot and flashed everything, after copying from my new k4nt. I flashed mmcblk0p1 and mmcblk0p2 and the main and diags kernels and bootloaders. I know that it worked for two reasons -- the flashing took a long time to complete, and it booted up into 4.0.1 (it was 4.0 before firmware flashing images from my new k4nt).

Now, on the touch, I see that in fastboot it reports "Success" in just a few seconds, and it quits. It cannot have flashed that much data in that short of a time.

So for now, fastboot method only works on the k4nt. It is not hopeless for the touch though. It is possible to boot a full bist (built-in self-test) version of the u-boot bootloader that includes a FIXED fastboot module, so that it WILL work. The problem is figuring out WHY it is not working, because I compared the 4.0.1 and 5.0.1 u-boot source code and the ONLY differences appear to be that 5.0.1 includes support for more devices (including the touch, and the k4nt, and other kindle models), and it has a little more sophisticated SDRAM initialization.

I might have missed something though because I was not aware of touch fastboot problems at that time. If you compare them and find a fastboot-related anomaly, please let me know the details about it.

Now, about ALWAYS being able to install our own custom code, we can do it by using MfgTool (or some new software program that can communicate with the kindle using USB Downloader mode). We can copy ANYTHING to the kindle RAM (not just u-boot). It could be another OS like android, or it could just be an extra memory-resident kernel-mode program that allows us to have root access even with a locked-down for encrypted mmc.

My next goal is to get fastboot working on my Touch. It can currently only boot to fastboot mode, and flashing "completes" too quickly. I plan to work on this until I succeed.

Meanwhile, last night on IRC I helped another Touch owner debrick his kindle that sat on the shelf in a previously HOPELESS condition. We gave up on trying to flash with fastboot. He booted to diags using my Select Boot tool (MfgTool and custom u-boots), then he used my data.tar.gz to run his RUNME.sh, which did "dd if=/mnt/us/mmcblk0p1.img of=/dev/mmcblk0p1 bs=1024". Then everything started working again.

Bricked kindles tend to discharge their batteries COMPLETELY. Charging does not work reliably. For the kindle we debricked last night, there were many problems until it finally got enough charge.

Symptoms of not enough charge are: MfgTool sees kindle and starts download but does not complete, or kindle not seen in fastboot mode even after booting to fastboot mode with MfgTool. Or kindle boots to diags and runs creates RUNME.done but the USB Drive cannot be loaded, or RUNME.sh starts but it never completes and you sit and the "Kindle Tree" screen. This is because the system detected a dead battery and switched to low power mode, with no mmc and no SDRAM -- only the battery charger firmware keeps running (apparently not reliably).

Solution: plug kindle into a WALL CHARGER for two or three hours, then use MfgTool to change to fastboot mode. Leave kindle connected to computer in fastboot mode for several hours (preferably overnight).

By monitoring a kindle serial port using MfgTool and fastboot, it appears that the kindle charges much faster in fastboot mode.

After you have a full charge (or at least charged in fastboot mode for a couple of hours), try using MfgTool to boot to diags.

I believe that many kindles do NOT need to reflash their mmcblk0p1, but even if you do, that can be done from diags mode in a RUNME.sh script. You need to boot to diags and copy data.tar.gz to it to install the code that checks for a RUNME.sh during every boot to main or diags. Be SURE to add an ENABLE_DIAGS or it will reboot to MAIN instead of DIAGS. Copy a custom RUNME.sh with the "dd" shown in the previous post. Reboot FROM THE MENU. There are reports that a HARD reboot (holding the power button) does not always run the RUNME.sh script.

Cross your fingers. If that does not work, do not give up. We will eventually have a full fastboot solution. This is a WORK IN PROGRESS. I post my progress to give us all hope. We WILL have a solution if we can remain patient, and for those willing to use the tools I provided (with a full battery charge) there is a HIGH success rate...

WARNING: Although fastboot seems to flash partitions correctly on a K4NT, according to serial port messages while flashing various partitions on the Touch, it always writes to mmcblk0 instead, which destroys the linux kernels for both the main and diags partitions. More evidence is that after I flashed mmcblk0p4 with a "filled in" version (I cannot export the USB drive), it now reports "cannot find linux kernel" when trying to boot main or diags. Both linux kernels are in mmcblk0p1, which is what appears to get damaged when you try to flash anything else. This is also probably why it finishes so quickly.

I plan to fix this with a custom bist u-boot that contains a repaired fastboot (if that is where the problem lies). If it is a communication problem between the u-boot fastboot module and the kindle fastboot tool, then that is where I will fix it. This will take some study.

For now, I recommend that if plan to write a backup copy onto the main system boot partition (mmcblk0p1), you should do it by booting diags and using "dd if=/mnt/us/mmcblk0p1.img of=/dev/mmcblk0p1 bs=1024" from RUNME.sh, after booting diags, adding ENABLE_DIAGS and the custom RUNME.sh, and if data.tar.gz has not been installed yet add it too. Then reboot from the menu. A hard reset (long power hold) has been reported to not always run RUNME.sh. As you can see in the IRC session I posted to the "Select Boot" thread, this method works well.

When fastboot is more reliable, that is the easier way to go, but for now, RUNME.sh is better...

We can still use fastboot for some things, like "sudo ./fastboot setver bootmode diags" to write bootmode diags to mmc so it become the default boot location (unless overridden with MfgTool). Just do not flash partitions on a touch with fastboot until we fix the problem.

WARNING: Although fastboot seems to flash partitions correctly on a K4NT, according to serial port messages while flashing various partitions on the Touch, it always writes to mmcblk0 instead, which destroys the linux kernels for both the main and diags partitions. More evidence is that after I flashed mmcblk0p4 with a "filled in" version (I cannot export the USB drive), it now reports "cannot find linux kernel" when trying to boot main or diags. Both linux kernels are in mmcblk0p1, which is what appears to get damaged when you try to flash anything else. This is also probably why it finishes so quickly.

I plan to fix this with a custom bist u-boot that contains a repaired fastboot (if that is where the problem lies). If it is a communication problem between the u-boot fastboot module and the kindle fastboot tool, then that is where I will fix it. This will take some study.

For now, I recommend that if plan to write a backup copy onto the main system boot partition (mmcblk0p1), you should do it by booting diags and using "dd if=/mnt/us/mmcblk0p1.img of=/dev/mmcblk0p1 bs=1024" from RUNME.sh, after booting diags, adding ENABLE_DIAGS and the custom RUNME.sh, and if data.tar.gz has not been installed yet add it too. Then reboot from the menu. A hard reset (long power hold) has been reported to not always run RUNME.sh. As you can see in the IRC session I posted to the "Select Boot" thread, this method works well.

When fastboot is more reliable, that is the easier way to go, but for now, RUNME.sh is better...

We can still use fastboot for some things, like "sudo ./fastboot setver bootmode diags" to write bootmode diags to mmc so it become the default boot location (unless overridden with MfgTool). Just do not flash partitions on a touch with fastboot until we fix the problem.

Here's a little suggestion: Please use bs=1M instead of bs=1024. 1k blocks will make the dd progress very slow. 1M seems to be a reasonable block size.

That makes a lot of sense, if the destination partition is a multiple of 1MB. The actual image files start with a flash header that shows the actual size of its contents. It is okay to write a little extra as long as you do not write into the next partition area on the mmc, or lose some data in the last partial block (depending on dd default behavior). I just did it the way yifanlu suggested (1024 is the default minimum block size in linux file systems) and it seemed to work fine, but a larger block size for dd would be a lot faster.

And one more question: will I be able to repair my Kinle with serial cable if I get one?

The serial cable connection gives you more options that are built-in. You can export and flash partitions using the ymodem protocol. Using USB-only requires using software tools that we are still creating and learning how to use. At this time the most reliable way (if your kindle is not TOO bricked) is to boot to diags and repair your kindle by putting the commands you need in a RUNME.sh script). You can write a backup copy to the main system boot partition with:

dd if=/mnt/us/mmcblk0p1.img of=/dev/mmcblk0p1 bs=1024

This has been documented multiple times in this and other threads.

You may want to change bs=1024 to bs=1M to speed up the write, but I have not yet verified that the version of dd in the kindle supports the "1M" size (not all version do).

The serial cable connection gives you more options that are built-in. You can export and flash partitions using the ymodem protocol. Using USB-only requires using software tools that we are still creating and learning how to use. At this time the most reliable way (if your kindle is not TOO bricked) is to boot to diags and repair your kindle by putting the commands you need in a RUNME.sh script). You can write a backup copy to the main system boot partition with:

dd if=/mnt/us/mmcblk0p1.img of=/dev/mmcblk0p1 bs=1024

This has been documented multiple times in this and other threads.

You may want to change bs=1024 to bs=1M to speed up the write, but I have not yet verified that the version of dd in the kindle supports the "1M" size (not all version do).

I have backups of mmcblk0p1 and mmcblk0p2.
But my Kindle does not boot in main, diags or fastboot(?) modes.
Right now I'm charging it to try fastboot again.
So right now I'm choosing between buying new Kindle, serial cable (but I don't know where) or just waiting for you to solve this (but I don't know how long).
So most likely I will buy new one and just enjoy reading

if you want to retry under ubuntu, the correct command is "sudo ./fastboot flash system mmcblk0p1.img"

This does not seem to work for the Touch. If you monitor status messages at the internal serial port, it says it is flashing mmcblk0, which can kill your linux kernels for both main and diags. It appears that there is a fastboot bug that needs to be fixed with a custom bist u-boot. After I tried flashing with fastboot, booting to main or diags gives status messages on the serial port saying "linux kernel not found" (or something like that)...

This command worked will on my K4NT though, so this problem seems to be restricted to the touch. It is better to use dd in a RUNME.sh script while booting diags, as described elsewhere.

As for the K3 devices: I've been trying AdvancedToolkit on my K3 Wifi - and wasn't successful. Might be because I was handing over USB2 traffic to a Windows XP running in VirtualBox, though. But it recognized the MX35 in the USB Downloader mode. However what didn't work was dumping the MMC using that approach. The flash tool just told that it wasn't successful to bring the device into the right mode.
Maybe it doesn't support dumping MMC contents? Then it might only be bad timing because of virtualized USB2... I've not yet looked into the Freescale data sheets whether it might be write-only, but that's a quite common feature on microcontrollers...

As for the K3 devices: I've been trying AdvancedToolkit on my K3 Wifi - and wasn't successful. Might be because I was handing over USB2 traffic to a Windows XP running in VirtualBox, though. But it recognized the MX35 in the USB Downloader mode. However what didn't work was dumping the MMC using that approach. The flash tool just told that it wasn't successful to bring the device into the right mode.
Maybe it doesn't support dumping MMC contents? Then it might only be bad timing because of virtualized USB2... I've not yet looked into the Freescale data sheets whether it might be write-only, but that's a quite common feature on microcontrollers...

It looks like part of mmcblk0 on the MX50 is write-only too (for user-land apps). Most of the stuff before the main kernal is all 0x00 when you dump it with "dd", and the idme tool writes to its vars directly to mmc, but reads /proc to read its var from a kernel module.

In the k4 and touch that write-only restriction might not apply to kernel modules.

I have yet to spend much time with AdvancedToolKit on my K3. It might need some special config files for the K3. I needed to create configs for the MfgTool to get it working the way I wanted it to work...

As for the K3 devices: I've been trying AdvancedToolkit on my K3 Wifi - and wasn't successful. Might be because I was handing over USB2 traffic to a Windows XP running in VirtualBox, though. But it recognized the MX35 in the USB Downloader mode. However what didn't work was dumping the MMC using that approach. The flash tool just told that it wasn't successful to bring the device into the right mode.
Maybe it doesn't support dumping MMC contents? Then it might only be bad timing because of virtualized USB2... I've not yet looked into the Freescale data sheets whether it might be write-only, but that's a quite common feature on microcontrollers...

Try running that under Wine, you should get much less USB latency.http://www.winehq.org/
Should be in major Linux distributions (but the distro versions may be version-old).