k3flasher, a USB download mode utility

[arooni]

Originally Posted by geekmaster

If the image is not a multiple of 512, it might be necessary to pad it with /dev/zero.

I know that I would do this with dd, but I'd love some help with the command to do it.

-rw-r--r-- 1 david david 2115008 Jun 6 2011 uImage

[geekmaster]

Originally Posted by arooni

I know that I would do this with dd, but I'd love some help with the command to do it.

-rw-r--r-- 1 david david 2115008 Jun 6 2011 uImage

Well, 2115008 is NOT a multiple of 512, so it DOES need some padding.

Using integer arithmetic:

(2115008+511)/512)*512-2115008 = 64

So you need to append another 64 bytes to your uImage file:

dd if=/dev/zero bs=64 count=1 >> uImage

Then try flashing that...

@hawhill: How about having k3flasher append zeros to the next 512 byte boundary to avoid this problem?

[arooni]

Originally Posted by geekmaster

Well, 2115008 is NOT a multiple of 512, so it DOES need some padding.

Using integer arithmetic:

(2115008+511)/512)*512-2115008 = 64

So you need to append another 64 bytes to your uImage file:

dd if=/dev/zero bs=64 count=1 >> uImage

Then try flashing that...

@hawhill: How about having k3flasher append zeros to the next 512 byte boundary to avoid this problem?

Thanks for the help. I'm not super comfy with dd. I tried this method and arrived at a multiple of 512bytes, but still got the same errors:

LilArooni ~/development/k3flasher: sudo ./k3flasher mx35to2_mmc.bin program 0x00041000 uImage
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.
LilArooni ~/development/k3flasher

[geekmaster]

Originally Posted by arooni

Thanks for the help. I'm not super comfy with dd. I tried this method and arrived at a multiple of 512bytes, but still got the same errors:

LilArooni ~/development/k3flasher: sudo ./k3flasher mx35to2_mmc.bin program 0x00041000 uImage
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.
LilArooni ~/development/k3flasher

NOT the SAME results. It is now missing the "I: size is not a multiple of 512" line shown in your previous post. So at least ONE of the problems has been solved.

I do not know the cause of the second "wrong transfer length" message. I do not have time to study the code now. Perhaps somebody else can help you with that one...

EDIT: If the "I" means "information" and the "E" means "error", then it was probably not required to pad the uImage out to 512 (but did not hurt either, just in case it CAUSED the next error). The REAL error is the "wrong transfer length" problem.

[hawhill]

Sorry, the message about the wrong length is misleading, I think. I've not appended anything to the kernel and it worked. It's just a not-really-tested path, but I think only addresses must fit to 512 byte boundaries. For lengths it does not matter.

The real problem are the last both lines, indicating ... well, I don't know. Could it be that the RAM kernel image got somehow corrupted? It seems that the ROM kernel is answering (4-byte replies) when the RAM kernel (8-byte replies) should. Somehow it seems the RAM kernel wasn't started.

I suggest to reset the device if you haven't already. Just pull power slider for >15secs, remember to keep Vol- pressed when you release the slider. Personally, I use "watch lsusb" in a terminal on the host machine to monitor the reboot.

I'll upload another version of the software in a minute, but there weren't related bugs in the old version, so it would not fix this, I think. It's mainly new features.

[hawhill]

I've just published v05. It has quite experimental, but quite useful new features:

The first is a simple thing: The "info" command will now also display the serial number of the Kindle plus the Wifi MAC address. Can probably also be a bit expanded. This can serve as an indicator if the memory in question has been overwritten with other stuff, too.

The other thing is complex, but veeeery useful. It's a built-in NBD (network block device) server. It will listen on localhost:12345 by default. You start it with the "nbd" command.
If successfully connected to the device, you can start "nbd-client" on your host machine (make sure you have the "nbd" package installed). You may need to modprobe the "nbd" kernel module on the host before nbd-client would work.

Example:
session1:

root# ./k3flasher mx35to2_mmc.bin nbd

session2:

root# modprobe nbd max_part=10
root# nbd-client localhost 12345 /dev/nbd0 -t 120
...use devices...
root# nbd-client -d /dev/nbd0

This will present the Kindle's flash as device(s) /dev/nbd0(p1,p2,p3,p4).

I've successfully tested reading (slow), writing (slower) and mounting (well, slow), even read/write. Works a treat. Some day, we might use this to fix filesystems on the Kindle.

Oh, and I've updated the code documentation quite a bit. I'll probably leave it this way, except for bugfixes.

[geekmaster]

I like nbd. I used to use it in the other direction on a WRT54G wireless router, so I could do large compiles in my OpenWRT router using nbd swap space on a host PC mounted over wifi. It worked amazingly well for gcc compiles that would otherwise fail from not enough memory. It was far more robust and dependable than NFS over wifi.

It will MOST DEFINATELY come in handy for future debricking sessions (and other uses). Perhaps android on a K3 (with a serial mouse)?

[hawhill]

NBD has a so simple protocol, hard to get it wrong. A short note for those who dare to try it out: The 4th partition is the user store *but* it is laid out as a full device, i.e. it has a partition table prepended. They did it to export the 4th partition via USB and it would present as a new "full" device with one partition.

That is implemented in /etc/init.d/userstore in the root file system. It checks the partition table within the partition and if it is invalid / zero, the user store will be reformatted. This is the reformatting taking place when you write some zeroes to the start of the userstore. If you want to mount the userstore, you need to specify an offset, just as /etc/init.d/userstore does. On my kindle, the actual partition (within the 4th partition of the flash device) starts at offset=8192. The command to mount it would be

root# mount -o offset=8192 /dev/nbd0p4 /mnt/kindle-userstore

[arooni]

Hi folks:

I compiled the latest version and I see:

LilArooni ~/development/k3flasher: sudo ./k3flasher mx35to2_mmc.bin program 0x00041000 uImage
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.
LilArooni ~/development/k3flasher: sudo ./k3flasher mx35to2_mmc.bin program 0x00041000 uImage
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.
I: flashing 0x00204600 (=2115072) bytes
LilArooni ~/development/k3flasher: ls -l

So not sure if that was "success" or not. And still not sure what I need to do to get the Kindle working. It's still happily frozen on the library screen. I'm wondering if it would just be better to give up on this and wait for the broken screen kindle and swap the internals out.

[hawhill]

That should be it. You would need to reset the device, i.e. again hold power slider for >15secs and *not* keeping Vol- pressed. It should start up now, at least it should run the kernel. The power led should at least blink green for a short moment, screen should be reset.

However, if your Kindle didn't have a broken kernel in the first place - and I'm not sure you ever indicated that it definitely had - you now just fixed what got broke earlier, but not the main culprit (which might be broken partition table, broken uboot, broken whatever else there is).

The latest version at least also checks the serial number (with "info" command), indicating if that section got corrupted. But there is more that can be broken. And I'm not yet aware of backup images for those parts. I guess those will be coming up in the near future, though. The new "nbd" server feature might also help when further examining the device. But without any "known good" backup images it's hard for you to compare and analyse. So I suggest to wait a bit.

[arooni]

Tried re-setting. No green light comes on. I'm thinking it's probably easier to swap parts (< 20 minutes) then try to debug this thing... only thing is I won't have the broken kindle to swap parts for the next month while waiting on slow shipping here in Colombia ....

I tried the info command:

LilArooni ~/development/k3flasher: sudo ./k3flasher mx35to2_mmc.bin info
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.
I: read info
I: got size 1048576 (probably wrong)
I: downloading 0x00000200 (=512) bytes, starting at 0x00040c00
I: got device serial number <123450A003420B0B>
I: got device Wifi MAC <28EF01312345>

[geekmaster]

In your post above, you should obfuscate part of the serial number and MAC (replace trailing digits with XXXX).

[arooni]

Originally Posted by geekmaster

In your post above, you should obfuscate part of the serial number and MAC (replace trailing digits with XXXX).

The serial # I gave above isn't real. I would never give my actual serial on a public board.

[hawhill]

Good point. I've added a reminder to the output of the "info" command.

arooni: I take it the serial no starts with "B00x", right? Then it would be unharmed. I'm attaching a (compressed, you need to gunzip it before applying) image of my flash from 0x0, up and including the boot loader (uboot). It's all open source or simple non-copyrighted data. You could try and flash it to 0x0 (no guarantees!). This, plus the kernel, should make for a clean boot up until the kernel stage. If still nothing changes, chances are there's a hardware defect.

[knc1]

Originally Posted by hawhill

arooni: I take it the serial no starts with "B00x", right?

His serial number starts with: B006
Or it did before he edited it.