Noob's guide to debricking through ATK :D

[knc1]

USB downloader mode has a time-out, if no activity is detected withing the set time period, the SoC will be reset.

Software can "fix" that - send downloader mode one valid command (get info will do) -
That will cause it to disable the initial safety timer.

Note: the "time out" is evidently related to clock speed - - its 90 seconds for the i.MX31 (K-DX) and only 30 seconds for the i.MX53 (K4&K5).

[elisaf]

Hello, I've been trying to debrick my Kindle 3 by following the noob's guide step by step, but so far without success. I downloaded Geekmaster's K3 v3.0.2 firmware and kernel and flashed them with ATK (running on Windows 7 32-bit). According to ATK the flash programming was successful, but my Kindle still won't reboot (and the battery is charged). Actually at step 4 when I clicked the "next" button I got an "USB not detected" error message, but then everything went fine, apparently. Can someone please help me? Thanks in advance

[melib]

Originally Posted by elisaf

Hello, I've been trying to debrick my Kindle 3 by following the noob's guide step by step, but so far without success. I downloaded Geekmaster's K3 v3.0.2 firmware and kernel and flashed them with ATK (running on Windows 7 32-bit). According to ATK the flash programming was successful, but my Kindle still won't reboot (and the battery is charged). Actually at step 4 when I clicked the "next" button I got an "USB not detected" error message, but then everything went fine, apparently. Can someone please help me? Thanks in advance

Did you extract files from .tar.gz to get .img before rename them to .bin?

[elisaf]

Yes, I did.

[hawhill]

What exactly happens at the stage you shortly described with "still won't reboot"? What screen changes happen, does the LED blink (when not connected via USB), ...?

The images uploaded until now do not include the very beginning of the eMMC partition, which holds a partition table and the boot loader. I think I'll upload an image of those soon, too. I consider it even more likely that those could get broken than I would for the kernel. So, please give the requested description and hold your breath for 1-2 days until I manage to put the partition header/boot loader image somewhere.

[knc1]

Originally Posted by hawhill

The images uploaded until now do not include the very beginning of the eMMC partition, which holds a partition table and the boot loader. I think I'll upload an image of those soon, too. I consider it even more likely that those could get broken than I would for the kernel. So, please give the requested description and hold your breath for 1-2 days until I manage to put the partition header/boot loader image somewhere.

In this post, I presume from the context that you mean the "User data area boot partition" (I.E: The one you can read as part of the rest of the user storage area.)

The eMMC of the K3 has two other, hardware, boot partitions.

The device end (client end, kindle, RAM kernel, whatever you call it) does not have the code to access the eMMC control registers required to access the hardware boot partitions.

Something on one of my many todo lists. Extend the downloaded command processor ("RAM kernel") with some general purpose eMMC utilities.

May never happen, I may die before I get around to it.

[hawhill]

I don't think the design uses any of these special "MMC partitions". So no, I was merely talking about the first sectors of the default user partition of the eMMC, not to be confused with actual "partitions" referenced in the partition table. The eMMC starts with MBR+partition table, but the partitions referenced in there do not cover everything. Uboot follows that partition table, then the Kernel. However, both are not within one of the partitions referenced in the partition table.

[knc1]

This English language has its faults at times.
HardWarePartitions of the HardWareDevice determined by the HardWareDeviceControlRegisters.

That is as close to German as I can get.

But yes, we are both talking about the same thing.
Them other "partition" thingies.

[hawhill]

Ooops. My "no" wasn't in place, since of course you hit the nail right on. I don't think we have a more detailed vocabularies for partitions of different abstraction levels in German than there is in English :-) And in the end, probably everything we talk about is software-defined. Well, in fact such small memory controllers are among the devices where the difference between hardware and software is blurred....

[Pixelpille]

Originally Posted by hawhill

Hm, you did put the kindle into Downloader mode, right? Does it still show the boy under the tree? Does power cycling or bringing the Kindle into Downloader mode change anything on screen, does the power LED change? Again, this also could be hardware failure.

Nothing changes on screen. Still the boy under the tree. LED also does not change from orange to something else. I've put my K3 yesterday evening back to the wall-charger, will try again this evening if something happens.

[elisaf]

Originally Posted by hawhill

What exactly happens at the stage you shortly described with "still won't reboot"? What screen changes happen, does the LED blink (when not connected via USB), ...?

Hi, when I say that it won't reboot I mean that it remains frozen on the last page I read, just as before the whole debricking procedure. When I slide the power switch the LED blinks but nothing happens no matter how long I hold it. Since it froze, not the slightest screen change has happened. At this point I'm afraid it might be beyond recovery...

[knc1]

If you don't already have a copy, sign-out a copy of: AN3996.pdf from the Freescale site.
(Its one of those free ones that has to be signed for, else I would just post a link to my copy.)

Lots of good information there of the start-up process from power-on-reset through bring up the iROM code.

Such as the SoC setup state.
Interesting things, like there is a single MMU mapping installed, an identity mapping with the four high bits forced to zero giving a virtual memory to physical memory identity map for the lower 32bits of the address space.
You want to access something in the other 60Gbytes of address space, you get to install your own MMU mapping.

Includes a bit-by-bit description of the iROM protocol.

How do they support so many different (usually flash) storage media in the tiny code space used by iROM?
Everything is done "bit serial" and they set the core clock speed to run at the same clock speed of the memory part.
Making synchronous transfers simple. And -
making the user sit there, wondering if anything is happening.

The ATK protocol is in the ATK documentation (they are different).
But your k3flasher info message shows that you already know that.

The only useful thing in this post is the ap-note number.

[geekmaster]

Originally Posted by Pixelpille

Nothing changes on screen. Still the boy under the tree. LED also does not change from orange to something else. I've put my K3 yesterday evening back to the wall-charger, will try again this evening if something happens.

That is normal behavior for a bricked kindle even when it CAN be debricked using the simple debricking method (flashing known good partitions). USB Downloader mode does not write to the eink display. A bricked kindle does not reliably indicate charge status with the power LEDs.

If you are using the 3.0.2 images, be sure that you properly extracted the multi-part zip file. Is the total size of mmcblk0p1 about 350MB?

[knc1]

Originally Posted by geekmaster

USB Downloader mode does not write to the eink display.

I am learning more about that as time passes.
USB Downloader mode is running the $10 SoC part as if it was a (rather dumb) $1 micro-controller.
It can start up the off-chip ram, the off-chip rom, run the serial or usb port ...
Duh...
That's it folks. (So don't expect it to turn on the battery management or anything else.)

[geekmaster]

Originally Posted by knc1

I am learning more about that as time passes.
USB Downloader mode is running the $10 SoC part as if it was a (rather dumb) $1 micro-controller.
It can start up the off-chip ram, the off-chip rom, run the serial or usb port ...
Duh...
That's it folks. (So don't expect it to turn on the battery management or anything else.)

It uses limited ($1 microcontroller) functionality that can fit into the on-chip RAM. But you can send code to it over USB Downloader mode (such as my patched u-boot images) that can enable SDRAM, and can load a full linux kernel (with loadable kernel module drivers on initrd). If the kernel contains eink drivers, then it could also talk to eink. You can essentially bootstrap a full OS over USB Downloader mode if you really want to, without even touching the mmc.