Finding a recovery path with Freescale's Advanced Toolkit

[hawhill]

I wanted to write much more and how I'm dissecting the K3's SoC-based USB downloader mode. I'll do that later in this thread, but just wanted to write a big correction to what I always wrote up to now: That it would not work to use Advanced Toolkit from Freescale out-of-the-box.

Instead, I just proved myself wrong there and successfully dumped (not yet: wrote!) the first 16MByte of my Kindle's flash.

For those who want to join the party: The relevant settings for ATK are: "TO2" model, MDDR RAM. I think it was a bit flakey here in the past because after sucessfully switching from the "ROM Kernel" over to the "RAM Kernel" the USB connection is reset, which irritated my VirtualBox'ed WinXP.

Now comes the harder part: Deciding to try to use it to actually flash something. I think I'll go and try and try with a big "marker" file on the VFAT partition...

[knc1]

Originally Posted by hawhill

I wanted to write much more and how I'm dissecting the K3's SoC-based USB downloader mode. I'll do that later in this thread, but just wanted to write a big correction to what I always wrote up to now: That it would not work to use Advanced Toolkit from Freescale out-of-the-box.

Instead, I just proved myself wrong there and successfully dumped (not yet: wrote!) the first 16MByte of my Kindle's flash.

For those who want to join the party: The relevant settings for ATK are: "TO2" model, MDDR RAM. I think it was a bit flakey here in the past because after sucessfully switching from the "ROM Kernel" over to the "RAM Kernel" the USB connection is reset, which irritated my VirtualBox'ed WinXP.

Now comes the harder part: Deciding to try to use it to actually flash something. I think I'll go and try and try with a big "marker" file on the VFAT partition...

Keep in mind that tool probably only understands the storage media, not the file system riding on top of it.
I.E: You will have to update the file system FAT-32 file allocation table + put the data on the correct clusters.
That might be a bit tricky if your DOS disk edit skills are as rusty as mine are.

Maybe like this?
Dump all of mmcblk0p4;
Keep in mind there is an 8,096 byte offset to the start of the file allocation table;
As USB storage, write your marker file;
Dump all of mmcblk0p4;
Compare first and second dump - noting the file allocation table clusters used, and the location in the media of the data you wrote.

This process lets the USB storage system do all the math about converting "next directory location" and "next cluster(s)" into physical offset addresses.
Once you have the physical address on the media of your marker file, then it is simply one addition to add in the offset from the start of the device to the start of p4.
The copy of the partition table in the dumps can give you that information.

To turn one of the dumps into a usable file system -
losetup -f
(returns first available device - the X below)
losetup -o 8096 /dev/loopX dumpfile.img
Now you can use fdisk (or whatever) on /dev/loopX to get the partition information.
mount -t vfat /dev/loopX /mnt/my_mount_point
Now you can read/write the marker file.

Got all your file system to physical storage location stuff figured out?
Now use the toolkit gui to alter the contents of the physical location of the file.

Repeat as required.
Use that "erase all" feature only as a last resort.

[hawhill]

I've just dumped a 512MByte file containing a certain byte sequence. Now I'll just search for 4MByte (erase size?) continuous patterns of that sequence on the /dev/mmcblk0 device (as far as I could see from dumping, its first 16 MByte were completely identical to the contents seen from a running system). Then I use ATK again to see if I get the expected sequence and then, if I feel lucky, try to flash something else to that location. I'll keep this thread informed.

[knc1]

Flash isn't that BIG (not yet) - 4096 byte erase blocks (4K).

An erased flash block is all 1s not all 0s in case that helps any.

[geekmaster]

I am quite excited about the progress here! I can't wait to get back where I can play with this stuff.

[hawhill]

Flashing works, too. I think I'll go and try to flash seaniko's kernel - that would probably very much the "real world application" of a tool like this. Whoohoo, easy K3 recovery path coming up. In fact, it seems robust enough even in VirtualBox that this could be used to write uboot, kernel+initramfs, settings vfat _and_ rootfs. Plus, we can easily use it to make backup dumps. Which I'll do now before doing anything else.

Edit: I verified that the data was written to the right place. And I'm using ATK 1.67, BTW.

[hawhill]

When flashing less than 512 bytes, the content will be flashed, but the remaining bytes of that block on target storage will have undefined (or rather: whatever is in that RAM buffer of the rescue ram kernel) content. So we can only reliable flash 512byte blocks. Also, offsets are truncated to allow only 512 byte (0x200) steps.

[knc1]

Tool must be written to support some very small flash devices, 512 byte erase block sizes are rare these days. That is 20th century flash sizes.

Oh, well, as long as it works ...

[hawhill]

I just successfully flashed seanikos kernel from this posting: https://www.mobileread.com/forums/sho...75602&langid=2
I had to extract it from the update package.

So in principle, we're set to flash backup dumps onto the K3 via USB only, simply using ATK. I'm tempted to write a libusb-based version that does the same, however, it doesn't make much sense since I cannot distribute the RAM kernel (included in ATK).

This is probably the end of serial K3 rescue.
I should probably make a proper How-To.

[geekmaster]

Originally Posted by hawhill

I just successfully flashed seanikos kernel from this posting: https://www.mobileread.com/forums/sho...75602&langid=2
I had to extract it from the update package.

So in principle, we're set to flash backup dumps onto the K3 via USB only, simply using ATK. I'm tempted to write a libusb-based version that does the same, however, it doesn't make much sense since I cannot distribute the RAM kernel (included in ATK).

This is probably the end of serial K3 rescue.
I should probably make a proper How-To.

We can add the K3 kernel (or whole package including it) to a "foreign" server and add it to the "simple debricking forensics pastebin". This keeps us safe with the MR "no direct links to firmware images" rule, and adds a step that at least requires noobs to know enough to copy/paste a URL, and amazon techs told me that it "should be okay" to distribute firmware images with a "repair tool" (but the amazon legal staff did not follow that up with written permission that I had requested). The amazon legal staff DOES know we are providing these images, and as long as we help them (with debricking their customer's kindles) more than we annoy them, we should be safe. In that regard, complaining TOO MUCH about crappy 5.1.x firmware MIGHT change the balance and make them decide to send takedown notices. We need to keep the balance on the positive side.

Then of course, we can build a kernel from GPL source, but we may have to recreate any non-GPL code in the included initrd...

Summary: If you DO create a package with RAM kernel image, we can add it to the forensics downloads (for now, IMHO).

[geekmaster]

When this is done, we can add firmware flashing to new MfgTool profiles, for K4/K5. Right?

I plan to expand the "simple debricking" sticky thread to include your K3 USB "simple debricking" package. In that context, the kernel image does not really need to be distributed with it. There are been a lot of success keeping the firmware images separate.

[hawhill]

Just flashed a full rootfs (the image from dasmover). It took about 2.5 hours for the full 700MByte. And I can report that the k3g image works well on my k3w. Rootfs start address is 0x003C1000. I'm hesitating to go back to my backup - would be another 2.5 hours... There are clearly differences in partition 2, though: I kept mine. I guess the rootfs images in partition 1 are pretty much alike between the models.

[geekmaster]

Originally Posted by hawhill

Just flashed a full rootfs (the image from dasmover). It took about 2.5 hours for the full 700MByte. And I can report that the k3g image works well on my k3w. Rootfs start address is 0x003C1000. I'm hesitating to go back to my backup - would be another 2.5 hours... There are clearly differences in partition 2, though: I kept mine. I guess the rootfs images in partition 1 are pretty much alike between the models.

On a K3, there is no diags partition. Diags is just a program that runs in main. Isn't partition 2 just the persistent user store partition (/var/local/), which is partition 3 on K4/K5?

EDIT: You can just zero that partition (or the first 1K of it) and the kindle will rebuild it on next reboot. I verified that /dev/mmcblk0p2 on a K3 is the /var/local partition.

[knc1]

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

[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).