Finding a recovery path with Freescale's Advanced Toolkit

[knc1]

Originally Posted by hawhill

Nevertheless, it actually is /var/local, yes :-) I'm going to try wiping it, just for the fun of it (to explore the recovery path). Plus, I have a backup and now there is this quite reliable way of flashing that back. Also, I think I'm going to try yifanlus recovery kernel, I think it is easier to just flash that and use its MMC export mechanism to flash other things (should be a lot faster). However, ATK alone is a nice one-stop application for flashing whatever the user needs to be flashed (I did not try the user partition yet).

Hmm...
User partition ~= 5x system partition == 2.5 hours ~== 12.5 hours.
Does the kindle remain powered (usb or charger) during that time?
That is a lot of erase, re-program cycles, the battery might need some help from an outside power source.

Is this utility (still) doing only 512 byte writes or did you get it to do 4096 byte writes?
Or is the special kernel at the Kindle-end consolidating writes into erase block chunks?
Doing 8x(erase, re-program) cycles per erase block chunk size will (perhaps is) a very slow, power hungry, process.

Just a few questions for thought before spending 12 hours watching a USB cable light blink.

[geekmaster]

Originally Posted by knc1

Please check your posted link above. It goes to a K4 thread not a K3 thread.

Damn. I have endless grief with copy/paste not working, and pasting OLD stuff from my clipboard... Now that it was confirmed, I removed that bad link. Thanks for the correction.

[geekmaster]

Originally Posted by hawhill

Nevertheless, it actually is /var/local, yes :-) I'm going to try wiping it, just for the fun of it (to explore the recovery path). Plus, I have a backup and now there is this quite reliable way of flashing that back. Also, I think I'm going to try yifanlus recovery kernel, I think it is easier to just flash that and use its MMC export mechanism to flash other things (should be a lot faster). However, ATK alone is a nice one-stop application for flashing whatever the user needs to be flashed (I did not try the user partition yet).

I am anxious to add this to the "simple debricking" sticky. Now we just need some step-by-step instructions, and perhaps some "forensics" archive images.

Next, we need to find the "magic key" for the DX and DXG. Then see if ATK works with them too.

[WoenK]

Not at home right now and can not try it, but one question that pops up is:
Is the .img file dumped the exact same like the ones one can get on the net or does it contain additional data ?!
If I remember correctly the .IMG files did not contain the whole partition data but only what was needed for a backup.

[geekmaster]

Originally Posted by WoenK

Not at home right now and can not try it, but one question that pops up is:
Is the .img file dumped the exact same like the ones one can get on the net or does it contain additional data ?!
If I remember correctly the .IMG files did not contain the whole partition data but only what was needed for a backup.

Partition and kernel images are complete. In the past, it was common to backup the first 32MB of the entire mmc device (/dev/mmcblk0), which contained the kernel (and other stuff). You can use the getkernels.sh script to extract the kernel(s) from such a backup image, or directly from the device.

[hawhill]

The "dumping" process is to make dumps, probably useful as backups of original data. Thinking of it, dumping the first ~32MB is probably a good idea in any case. It also serves as a quick test of the connection to the Kindle.

Currently, it's mainly partition images for the root partition and kernels what's floating around. We probably need partition table, eink data, uboot and some other stuff, too. However, in the first few sectors there's also a device identifier, I think. This should probably remain untouched for general-purpose recovery.

[geekmaster]

The eink waveforms are programmed into a chip mounted on the eink flex cable, not in the mmc. The device identifier (pcbsn, serial, and other idme vars) is in the image for K3 and earlier, but on a K4/K5 those areas are write-only (and read as all zeros). To read stuff from those areas you need to get it from a driver /proc interface. Even the idme tool does that (read from a /proc, write to /dev/mmcblk0).

[WoenK]

Originally Posted by geekmaster

The eink waveforms are programmed into a chip mounted on the eink flex cable, not in the mmc. The device identifier (pcbsn, serial, and other idme vars) is in the image for K3 and earlier, but on a K4/K5 those areas are write-only (and read as all zeros). To read stuff from those areas you need to get it from a driver /proc interface. Even the idme tool does that (read from a /proc, write to /dev/mmcblk0).

hmmm...if the serial for the K3 is in an image, one must edit that before writing it on another K3. Would make a one-fits-all image for noobs impossible, unless a small batch is done, which writes the necessary device specific files and creates the image file for that specific reader.

ok...at home...downloaded ATK 1.67 and first problem is "No USB detected" (it is a absolutely bricked K3 3G+WiFi US with nothing coming out of the serial either).
Did a hard reset removing the battery, held the power on for over a minute without a battery.
When connecting the USB ist finds it for a second and then goes away (Kindle is not recognized)

[knc1]

Originally Posted by WoenK

hmmm...if the serial for the K3 is in an image, one must edit that before writing it on another K3. Would make a one-fits-all image for noobs impossible, unless a small batch is done, which writes the necessary device specific files and creates the image file for that specific reader.

ok...at home...downloaded ATK 1.67 and first problem is "No USB detected" (it is a absolutely bricked K3 3G+WiFi US with nothing coming out of the serial either).
Did a hard reset removing the battery, held the power on for over a minute without a battery.
When connecting the USB ist finds it for a second and then goes away (Kindle is not recognized)

Google: JTAG or eJTAG for ARM (or Freescale).

The eJTAG group of pads are identified on the board, but the individual pads are not identified as to the signal present.

Will take either a fancy (expensive) eJTAG device that self identifies the individual pads - or some hardware guru's time and o'scope.

Then all we have to do is discover the registers and register bits functions in the Freescale SoC.

Hmm...
Didn't you say you had a spare K3 e-ink display for sale?

[WoenK]

Originally Posted by knc1

Google: JTAG or eJTAG for ARM (or Freescale).

The eJTAG group of pads are identified on the board, but the individual pads are not identified as to the signal present.

Will take either a fancy (expensive) eJTAG device that self identifies the individual pads - or some hardware guru's time and o'scope.

Then all we have to do is discover the registers and register bits functions in the Freescale SoC.

Hmm...
Didn't you say you had a spare K3 e-ink display for sale?

nope...no display for sale because even if this one is fried, I will keep it for spare parts

I think the problem is that Win7 can not do anything with that SE RINGO thingy and the drivers in the Freescale dir do not seem to be the right ones.

edith: Not sure if it was the last reset or the ATK program, but no the USB port goes on and off...which is better then before becaus it was onle once after a reset on for a few secs

edith: seems like I need the V1.70 and not the 1.66 I downloaded, which is a bummer, because for the V1.70 one has to register

Update:1.66 works fine in XP mode...

Update: Have the 1.67 and not the 1.66...I can get to the moment where it would start flashing, but it loses the connection to USB. I seems that I can only find the port shortly after a reset, but Win7 cuts it again because it has no 64Bit driver for it

last update before sleep: found V1.70...surely not easy to find and not directly from Freescale ...and also does not include any 64 bit drivers,actually in the windriver dir are the same drivers as in V1.67. Deinstalled it on Win7, installed in virtual PC and there I am at least getting to the flash tool, but the USB port gets disconnected on the Win7 side and reconnects (disconnects exactly the moment I try to dump or program)...absolutely no way to dump or write anything that way....
Not sure if it is the setup or the K3, will try to install XP on another machine...
Had Codewarrior installed in the meantime, because it seemed to have the drivers...wasted time
...after 6 hours of fiddling around, I lay my head and rest

[yifanlu]

Wait. there's usb download mode for the Kindle 3 now?! more information? (PM me if you don't want to talk publicly) thanks!

[geekmaster]

Originally Posted by yifanlu

Wait. there's usb download mode for the Kindle 3 now?! more information? (PM me if you don't want to talk publicly) thanks!

K3 USB Downloader mode history: I played with Advanced Toolkit a bit after poking around and finding the K3 "magic key" (mentioned in the GPL source code) to start USB Downloader mode (Vol-), then mentioned it as a possible debricking tool (with more study) in my "simple debricking" thread. Then hawhill played with it too, but did not get much farther than me. Recently, hawhill began playing with it again, and after studying its source code, he has made WONDERFUL progress, including flashing kernel and main partition with it on a K3.

I still have not found the "Magic Key" for DX or DXG.

I hope we can add the K3 to your "One Button Recovery" tool.

[geekmaster]

Wrong thread? This isn't the one I was viewing before posting! Off-topic message deleted.

[hawhill]

Originally Posted by yifanlu

Wait. there's usb download mode for the Kindle 3 now?! more information? (PM me if you don't want to talk publicly) thanks!

Hi yifanlu! Great to see you again. I would have poked you anyways in the coming days, since I have two questions about your K3 rescue kernel. But to answer your question: Yep! We can read (!) and write (!!) any single part of the MMC with bare Freescale SoC ROM-based USB downloader. So the K3 is now considered fully recoverable. It was actually very simple and not a big deal. I started out with a much more complex idea on it, and in the end it showed that the Freescale defaults did already fit the Kindle platform.

As ATK writes plain binary images, I have a first question for you: I flashed the uImage you provided in your rescue kernel image installer to my K3. But then: How do I make it export the full MMC? Pressing "E" in the rescue menu just exports the user partition, like the original kernel does. So how am I supposed to trigger the full export?

And then I have a simple request: Could you provide this rescue kernel as pure uImage, too? (preferable named as "k3-rescue-kernel-uimage.bin" - ATK will deal better if the file is suffixed with ".bin")

[knc1]

Originally Posted by hawhill

The "dumping" process is to make dumps, probably useful as backups of original data. Thinking of it, dumping the first ~32MB is probably a good idea in any case. It also serves as a quick test of the connection to the Kindle.

Currently, it's mainly partition images for the root partition and kernels what's floating around. We probably need partition table, eink data, uboot and some other stuff, too. However, in the first few sectors there's also a device identifier, I think. This should probably remain untouched for general-purpose recovery.

A quick and simple view:

core2quad embed $ fdisk -l kindle-hawhill-0x00000000-0x02000000.img

Disk kindle-hawhill-0x00000000-0x02000000.img: 33 MB, 33554432 bytes
4 heads, 16 sectors/track, 1024 cylinders, total 65536 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x489339d6

                                   Device Boot      Start         End      Blocks   Id  System
kindle-hawhill-0x00000000-0x02000000.img1   *        7688     1338943      665628   83  Linux
kindle-hawhill-0x00000000-0x02000000.img2         1338944     1388095       24576   83  Linux
kindle-hawhill-0x00000000-0x02000000.img3         1388096     1404479        8192   83  Linux
kindle-hawhill-0x00000000-0x02000000.img4         1404480     7815167     3205344    b  W95 FAT32

It is a "standard" x86 style, ms-dos disk label at the default location.

What is not "standard" is the storage area between the end of the partition table and the start of the first partition.

Mapping the contents of that area will take a bit more work by someone.

Plus we are not (yet) diddling the eMMC control registers to get copies of the one or two reserved areas.
Details in the eMMC data sheet, plus there is a mmc-util program, that with only a little bit of work to include this eMMC device, will give us that information. (one of the driving reasons for DIY-KeK - I want to use it myself)