Unbriking Kindle DX

[knc1]

Originally Posted by geekmaster

And the DX backup in the pastebin has 16 image files, including those MTD parts... Good luck making a noob guide for that.

Just publishing the command sequence that dump'd those 16 image files is still on our "to do" list.
Done, page down a bit.

What to do with them, and what they contain, are still part of a "student exercise".

And for those folks not Linux kernel VFS driver gurus -
There is a driver that can emulate an mtd device using those mtd file images.
And everyone already knows how to handle the mmc file images.

Note: the "hidden 1" image **should** have that i.ROM data block in it. The "hidden 2" image **should** have the FAT32 partition table (and MBR area) in it.

As I recall, we dump'd the storage in blocks of 1024 bytes, so that we would hit all of the physical address boundaries, and made sure the (1024 byte) block counts added up to the known starting point of "user storage device" partition (which is the 17th image, not present in the set).

But we really need to bring up the i.ROM code in that DX that was the source of those files and "peek" the absolute addresses at the start of each image file to ensure that the image files and the absolute addresses did, in fact, end up in alignment.
(That needs to be done before using the images to re-initialize a DX that does not have a running kernel to do the image-start to absolute address translation for us.)
Part of the hold-up on writing that noob's guide for the DX.

[twobob]

Originally Posted by

Originally Posted by knc1

The sum of the mmcblk0 partitions is 8 blocks less than the raw device.
So assume that un-partitioned space is at the front of the device.

The units of /proc/partitions is 1024 bytes.
The (default) units of dd is 512 bytes.

dd if=/dev/mmcblk0 of=/mnt/base-us/hidden1.bin bs=1024 count=8
dd if=/dev/mmcblk0p1 of=/mnt/base-us/part1.bin bs=1024
dd if=/dev/mmcblk0p2 of=/mnt/base-us/part2.bin bs=1024
dd if=/dev/mmcblk0p3 of=/mnt/base-us/part3.bin bs=1024

You are writing to the file system that is backed by the storage device /dev/mmcblk0p4 so you don't need to copy that but there is (**should be**) 16 sectors outside of the fat partition that may hold something interesting.
dd if=/dev/mmcblk0p4 of=/mnt/base-us/hidden2.bin bs=512 count=16

Ignore /dev/loop/0 (/dev/loop0) that is also part of the user storage layers.

The mtdblock devices are none of the above, so copy out those also
dd if=/dev/mtdblock0 of=/mnt/base-us/mtd_0.bin bs=1024
Repeat eight times, changing only the names.

So full disclosure would be

[root@kindle root]# cat /proc/partitions
major minor #blocks name

7 0 3510232 loop0
31 0 128 mtdblock0
31 1 3584 mtdblock1
31 2 32 mtdblock2
31 3 128 mtdblock3
31 4 3584 mtdblock4
31 5 64 mtdblock5
31 6 128 mtdblock6
31 7 24 mtdblock7
31 8 64 mtdblock8
179 0 3952640 mmcblk0
179 1 409624 mmcblk0p1
179 2 24576 mmcblk0p2
179 3 8192 mmcblk0p3
179 4 3510240 mmcblk0p4

then:

[root@kindle root]# dd if=/dev/mmcblk0 of=/mnt/base-us/hidden1.bin bs=1024 count=8
8+0 records in
8+0 records out
[root@kindle root]# dd if=/dev/mmcblk0p1 of=/mnt/base-us/part1.bin bs=1024
409624+0 records in
409624+0 records out

[root@kindle root]# dd if=/dev/mmcblk0p2 of=/mnt/base-us/part2.bin bs=1024
24576+0 records in
24576+0 records out
[root@kindle root]# dd if=/dev/mmcblk0p3 of=/mnt/base-us/part3.bin bs=1024
8192+0 records in
8192+0 records out
[root@kindle root]# dd if=/dev/mmcblk0p4 of=/mnt/base-us/hidden2.bin bs=512 count=16
16+0 records in
16+0 records out

And:

[root@kindle root]# dd if=/dev/mtdblock/0 of=/mnt/base-us/mtd_0.bin bs=1024
128+0 records in
128+0 records out
[root@kindle root]# dd if=/dev/mtdblock/1 of=/mnt/base-us/mtd_1.bin bs=1024
3584+0 records in
3584+0 records out
[root@kindle root]# dd if=/dev/mtdblock/2 of=/mnt/base-us/mtd_2.bin bs=1024
32+0 records in
32+0 records out
[root@kindle root]# dd if=/dev/mtdblock/3 of=/mnt/base-us/mtd_3.bin bs=1024
128+0 records in
128+0 records out
[root@kindle root]# dd if=/dev/mtdblock/4 of=/mnt/base-us/mtd_4.bin bs=1024
3584+0 records in
3584+0 records out
[root@kindle root]# dd if=/dev/mtdblock/5 of=/mnt/base-us/mtd_5.bin bs=1024
64+0 records in
64+0 records out
[root@kindle root]# dd if=/dev/mtdblock/6 of=/mnt/base-us/mtd_6.bin bs=1024
128+0 records in
128+0 records out
[root@kindle root]# dd if=/dev/mtdblock/7 of=/mnt/base-us/mtd_7.bin bs=1024
24+0 records in
24+0 records out
[root@kindle root]# dd if=/dev/mtdblock/8 of=/mnt/base-us/mtd_8.bin bs=1024
64+0 records in
64+0 records out

which gives you a better sense of what you might be dealing with.

[knc1]

Which I can see now may be 8 (1024 byte) blocks too many.
A little bit of hex dumping the starting 512 bytes of the images and comparing them should tell the story.

If too many, I would expect the "hidden 1" to be a duplicate of those blocks at the start of the mmcblk0p1 image.
An easy thing to check for before we turn those loose on the world.

I.E: When I wrote that the total was 8 (1024 byte) blocks too short, I hadn't accounted for the FAT32 MBR&Partiton area of (16 512 byte, 8 1024 byte) blocks which does not show up in the /cat/partitions output.

Ah, well, better too much than too little.

[geekmaster]

Originally Posted by knc1

...
Ah, well, better too much than too little.

Yeah... Tell that to the guy who wrote the "getkernels" scripts.

[twobob]

wouldn't hurt to use em, wouldn't hurt to fix em. : )

[geekmaster]

Originally Posted by twobob

wouldn't hurt to use em, wouldn't hurt to fix em. : )

The getkernels-1.4 script was fixed awhile ago, after ixtab figured out that they had a problem when the image filled a block leaving no room for the 64-byte flash header. That was not a known problem until recent firmware versions, but it is fixed now even for newer firmware versions.

[twobob]

I meant the systems images but yes indeed, those tools as well : )

[knc1]

Originally Posted by twobob

I meant the systems images but yes indeed, those tools as well : )

It is near the end of my useful part of the day here . . . .

Since I am the one that (may) have made the original mistake, I'll download those things and hexdump them for duplications.

Might even get lucky and be able to ID the purpose of some of them.

[knc1]

The first step in dealing with unknown content binaries:

core2quad DXBACKUP $ file *
hidden1.bin: x86 boot sector; partition 1: ID=0x83, active, starthead 1, startsector 16, 819248 sectors; partition 2: ID=0x83, starthead 3, startsector 819264, 49152 sectors; partition 3: ID=0x83, starthead 3, startsector 868416, 16384 sectors; partition 4: ID=0xb, starthead 3, startsector 884800, 7020480 sectors, code offset 0x0
hidden2.bin: x86 boot sector; partition 1: ID=0xb, starthead 1, startsector 16, 7020464 sectors, extended partition table (last)\011, code offset 0x0
mtd_0.bin:   data
mtd_1.bin:   u-boot legacy uImage, s055537-1101131756-TNM0.9~2.6.2, Linux/ARM, OS Kernel Image (Not compressed), 1909000 bytes, Thu Jan 13 20:13:23 2011, Load Address: 0x80008000, Entry Point: 0x80008000, Header CRC: 0x9F3FB4DC, Data CRC: 0x19D80CB2
mtd_2.bin:   data
mtd_3.bin:   data
mtd_4.bin:   u-boot legacy uImage, s055537-1101131756-TNM0.9~2.6.2, Linux/ARM, OS Kernel Image (Not compressed), 1909000 bytes, Thu Jan 13 20:13:23 2011, Load Address: 0x80008000, Entry Point: 0x80008000, Header CRC: 0x9F3FB4DC, Data CRC: 0x19D80CB2
mtd_5.bin:   data
mtd_6.bin:   ISO-8859 text, with very long lines, with no line terminators
mtd_7.bin:   data
mtd_8.bin:   data
part1.bin:   Linux rev 1.0 ext3 filesystem data, UUID=51146397-cf15-41fc-bd6a-7e94c87cf04b
part2.bin:   Linux rev 1.0 ext3 filesystem data, UUID=11e96b35-caa6-47c5-92a6-ecb0ba364606, volume name "LocalVars" (needs journal recovery)
part3.bin:   data
core2quad DXBACKUP $

The "file" utility does a "best guess" when it checks a file and it can make mistakes, but that gives some initial direction to further study.

And the "first look" makes it appear that I **did not** have twobob duplicate anything.

To that information, add the file size information:

core2quad DXBACKUP $ ls -lh
total 441M
-rw-rw-r-- 1 mszick mszick 8.0K 2012-09-14 18:40 hidden1.bin
-rw-rw-r-- 1 mszick mszick 8.0K 2012-09-14 18:59 hidden2.bin
-rw-rw-r-- 1 mszick mszick 128K 2012-09-14 19:03 mtd_0.bin
-rw-rw-r-- 1 mszick mszick 3.5M 2012-09-14 19:04 mtd_1.bin
-rw-rw-r-- 1 mszick mszick  32K 2012-09-14 19:04 mtd_2.bin
-rw-rw-r-- 1 mszick mszick 128K 2012-09-14 19:04 mtd_3.bin
-rw-rw-r-- 1 mszick mszick 3.5M 2012-09-14 19:04 mtd_4.bin
-rw-rw-r-- 1 mszick mszick  64K 2012-09-14 19:04 mtd_5.bin
-rw-rw-r-- 1 mszick mszick 128K 2012-09-14 19:04 mtd_6.bin
-rw-rw-r-- 1 mszick mszick  24K 2012-09-14 19:04 mtd_7.bin
-rw-rw-r-- 1 mszick mszick  64K 2012-09-14 19:04 mtd_8.bin
-rw-rw-r-- 1 mszick mszick 401M 2012-09-14 18:45 part1.bin
-rw-rw-r-- 1 mszick mszick  24M 2012-09-14 18:59 part2.bin
-rw-rw-r-- 1 mszick mszick 8.0M 2012-09-14 18:59 part3.bin

Which seems to have a pattern to it of:
(for mtdblock partitions)
i.RAM binary
U-Boot (or other boot monitor)
Application code

And the kernel must be ... ? ?
Perhaps in the / system image file - more looking required.

Grab the low hanging fruit:

core2quad DXBACKUP $ sudo mkdir /mnt/part1 /mnt/part2
core2quad DXBACKUP $ sudo mount part1.bin /mnt/part1
core2quad DXBACKUP $ ls /mnt/part1
bin  etc  linuxrc     mnt  proc  sys   tmp  var
dev  lib  lost+found  opt  sbin  test  usr
core2quad DXBACKUP $ sudo mount part2.bin /mnt/part2
core2quad DXBACKUP $ ls /mnt/part2
audio  eink  java  log  run  system  wan

Which all looks familiar.

Since the first 8K of the eMMC has a "dos disk label" - now see if the partition descriptions and our eMMC images correspond.
Checking carefully for areas "outside" of those described by the "disk label".

The "dos disk label" in hidden1.bin (from base 0 of the eMMC):

core2quad DXBACKUP $ fdisk -l hidden1.bin
You must set cylinders.
You can do this from the extra functions menu.

Disk hidden1.bin: 0 MB, 8192 bytes
4 heads, 16 sectors/track, 0 cylinders, total 16 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
hidden1.bin1   *          16      819263      409624   83  Linux
hidden1.bin2          819264      868415       24576   83  Linux
hidden1.bin3          868416      884799        8192   83  Linux
hidden1.bin4          884800     7905279     3510240    b  W95 FAT32

Still need to check for "code" or "other data" inside the "MBR area" of hidden1.bin, before the partition table (which is at the end of the 8K block) but nothing too surprising (yet).

hidden1.bin1   *          16      819263      409624   83  Linux
hidden1.bin2          819264      868415       24576   83  Linux
hidden1.bin3          868416      884799        8192   83  Linux
hidden1.bin4          884800     7905279     3510240    b  W95 FAT32

[root@kindle root]# dd if=/dev/mmcblk0p1 of=/mnt/base-us/part1.bin bs=1024
409624+0 records in
409624+0 records out
[root@kindle root]# dd if=/dev/mmcblk0p2 of=/mnt/base-us/part2.bin bs=1024
24576+0 records in
24576+0 records out
[root@kindle root]# dd if=/dev/mmcblk0p3 of=/mnt/base-us/part3.bin bs=1024
8192+0 records in
8192+0 records out

Which looks reasonable.

And (which is needed to re-write the eMMC with U-boot that accepts write addresses) the eMMC storage looks to be mapped one-to-one with the images we made (the intended result).

I.E:
address 0:
hidden1.bin
part1.bin
part2.bin
part3.bin
and then mkdos fat32 on part4 (mmcblk0p4) for the user storage partition.

Still need to find the kernel(s) but they are probably in the mtd device since that is where the U-Boot applications are at.
Wrong, all ready found them, labeled "uimage" in the above.
Also found somebody's serial number and board ID (oops).

Note this image can do both, network load/write flash and network boot,
Or boot from mtd and mount an NFS exported root file system.

In terms of evolution from a manufacturer's development board into a commercial product, this DX image looks still very close to a development board system.

Somebody eyeball the DX(G) U-boot code sources - that will tell more of the story.

[cavorite]

You guys are in the black diamond area and I'm off in the weeds somewhere. Nevertheless, I do have my crippled DX with a functional serial interface, and offer it for any testing (short of destructive) that may be useful in finding answers.

[knc1]

Originally Posted by cavorite

You guys are in the black diamond area and I'm off in the weeds somewhere. Nevertheless, I do have my crippled DX with a functional serial interface, and offer it for any testing (short of destructive) that may be useful in finding answers.

Hey, you asked "What do I write with U-Boot and to what address?"

So just hang in here, we are trying to answer the question.
I am about dead for this work-shift, but we have system's knowledgeable people scattered around the world's time zones.
Somebody else will be coming on-shift soon.

[geekmaster]

Originally Posted by knc1

T...
Still need to find the kernel(s) but they are probably in the mtd device since that is where the U-Boot applications are at.
...

Just grep for "Linux-" in the images...

[twobob]

Bah thought I'd stripped my board and serial. (I did do it in several places), where the heck was it squirrelled away now? *reads up* don't see a clue.

You wan't me to pull the lot - or just cleanup one of the exports?
Ho hum. An exercise to the really dedicated student perhaps...
Come stamp on a stranger for helping today!



Thanks for the walk-through Knc1. I learned about 15 new things as usual.
Perhaps a how-to is not actually out of reach after all.

[knc1]

Originally Posted by twobob

Bah thought I'd stripped my board and serial. (I did do it in several places), where the heck was it squirrelled away now? *reads up* don't see a clue.

You wan't me to pull the lot - or just cleanup one of the exports?
Ho hum. An exercise to the really dedicated student perhaps...
Come stamp on a stranger for helping today!



Thanks for the walk-through Knc1. I learned about 15 new things as usual.
Perhaps a how-to is not actually out of reach after all.

I was not keeping good notes yesterday, but I do recall in general what I was doing, will go looking for it again.

Almost done here, just need to associate the images as seen via the kernel drivers vs their address as seen while in U-Boot.

Then we can give directions of the sort:
Using U-Boot command abc, write file gfh at address xyz
A few of those, and the DX(G) of the topic here will be restored to operation.

Would be nice at this point to have a serial port connection on a **working** DX(G) but I think it will be possible with what we do have available to associate images with addresses as seen by U-Boot.

I just need to post a request for more information from the broken one.

[knc1]

Originally Posted by cavorite

You guys are in the black diamond area and I'm off in the weeds somewhere. Nevertheless, I do have my crippled DX with a functional serial interface, and offer it for any testing (short of destructive) that may be useful in finding answers.

I want to get some more information from your machine.

So lets use that functional serial interface port and whatever terminal emulator you have.

Get your communications all setup with the serial port, Kindle, terminal emulator, etc.

Enable the emulator's capture to file feature.
In (Linux) minicom it is in the configuration panels as "Capture File"
In (Windows) ??? I am not sure, it will depend on the application but should be somewhere - perhaps in configuration - session - logging.
Sorry, knowing what you may be using under Windows would not help me, I would have to look up that application's docs - I don't know windows.

This may give what is required at this point:

• You have communications established over the serial port ;
• You have set up recording the communications to a (capture, log, transcript, whatever) file ;
• Use the: "Hold power switch forever" method of getting the Kindle to do a complete restart ;
• Save the recorded result file ;
• Start another recording file ;
• Repeat the complete restart.

Twice? In two capture files?
Yes.
Because I think the DX is one of the machines which alternates between the two boot image files on the machine with each hard re-start.


The image files look as if they have two (2) complete sets of U-Boot environment and kernel images.
All stored in a device physically different than the device that has your broken system image.


zip or tar/gzip the two files, attach to post.
I expect they will tell me what to either do next or what to ask for next.