09-26-2012, 11:58 AM | #46 | |
Going Viral
Posts: 17,212
Karma: 18210809
Join Date: Feb 2012
Location: Central Texas
Device: No K1, PW2, KV, KOA
|
Quote:
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. Last edited by knc1; 09-26-2012 at 01:29 PM. |
|
09-26-2012, 12:14 PM | #47 | ||||
( ͡° ͜ʖ ͡°){ʇlnɐɟ ƃǝs}Tır
Posts: 6,586
Karma: 6299991
Join Date: Jun 2012
Location: uti gratia usura (Yao ying da ying; Mo ying da yieng)
Device: PW-WIFI|K5-3G+WIFI| K4|K3-3G|DXG|K2| Rooted Nook Touch
|
Originally Posted by
Quote:
Quote:
Quote:
Quote:
Last edited by twobob; 09-26-2012 at 12:15 PM. Reason: boldieness |
||||
09-26-2012, 12:48 PM | #48 |
Going Viral
Posts: 17,212
Karma: 18210809
Join Date: Feb 2012
Location: Central Texas
Device: No K1, PW2, KV, KOA
|
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. Last edited by knc1; 09-26-2012 at 01:26 PM. |
09-26-2012, 01:20 PM | #49 |
Carpe diem, c'est la vie.
Posts: 6,433
Karma: 10773668
Join Date: Nov 2011
Location: Multiverse 6627A
Device: K1 to PW3
|
|
09-26-2012, 01:31 PM | #50 |
( ͡° ͜ʖ ͡°){ʇlnɐɟ ƃǝs}Tır
Posts: 6,586
Karma: 6299991
Join Date: Jun 2012
Location: uti gratia usura (Yao ying da ying; Mo ying da yieng)
Device: PW-WIFI|K5-3G+WIFI| K4|K3-3G|DXG|K2| Rooted Nook Touch
|
wouldn't hurt to use em, wouldn't hurt to fix em. : )
|
09-26-2012, 01:38 PM | #51 |
Carpe diem, c'est la vie.
Posts: 6,433
Karma: 10773668
Join Date: Nov 2011
Location: Multiverse 6627A
Device: K1 to PW3
|
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.
|
09-26-2012, 01:43 PM | #52 |
( ͡° ͜ʖ ͡°){ʇlnɐɟ ƃǝs}Tır
Posts: 6,586
Karma: 6299991
Join Date: Jun 2012
Location: uti gratia usura (Yao ying da ying; Mo ying da yieng)
Device: PW-WIFI|K5-3G+WIFI| K4|K3-3G|DXG|K2| Rooted Nook Touch
|
I meant the systems images but yes indeed, those tools as well : )
|
09-26-2012, 01:52 PM | #53 | |
Going Viral
Posts: 17,212
Karma: 18210809
Join Date: Feb 2012
Location: Central Texas
Device: No K1, PW2, KV, KOA
|
Quote:
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. |
|
09-26-2012, 02:29 PM | #54 |
Going Viral
Posts: 17,212
Karma: 18210809
Join Date: Feb 2012
Location: Central Texas
Device: No K1, PW2, KV, KOA
|
DX(G) images
The first step in dealing with unknown content binaries:
Code:
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 $ And the "first look" makes it appear that I **did not** have twobob duplicate anything. To that information, add the file size information: Code:
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 (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: Code:
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 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): Code:
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 Code:
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 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. Last edited by knc1; 09-26-2012 at 04:51 PM. |
09-26-2012, 02:50 PM | #55 |
Enthusiast
Posts: 42
Karma: 31420
Join Date: Sep 2006
Location: Milky Way galaxy, Orion-Cygnus arm, Sol-III, North America, USA, FL
Device: various iDevices
|
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.
|
09-26-2012, 03:24 PM | #56 | |
Going Viral
Posts: 17,212
Karma: 18210809
Join Date: Feb 2012
Location: Central Texas
Device: No K1, PW2, KV, KOA
|
Quote:
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. |
|
09-26-2012, 03:54 PM | #57 |
Carpe diem, c'est la vie.
Posts: 6,433
Karma: 10773668
Join Date: Nov 2011
Location: Multiverse 6627A
Device: K1 to PW3
|
|
09-27-2012, 07:55 AM | #58 |
( ͡° ͜ʖ ͡°){ʇlnɐɟ ƃǝs}Tır
Posts: 6,586
Karma: 6299991
Join Date: Jun 2012
Location: uti gratia usura (Yao ying da ying; Mo ying da yieng)
Device: PW-WIFI|K5-3G+WIFI| K4|K3-3G|DXG|K2| Rooted Nook Touch
|
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. |
09-27-2012, 09:42 AM | #59 | |
Going Viral
Posts: 17,212
Karma: 18210809
Join Date: Feb 2012
Location: Central Texas
Device: No K1, PW2, KV, KOA
|
Quote:
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. |
|
09-27-2012, 09:58 AM | #60 | |
Going Viral
Posts: 17,212
Karma: 18210809
Join Date: Feb 2012
Location: Central Texas
Device: No K1, PW2, KV, KOA
|
Quote:
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:
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. |
|
Thread Tools | Search this Thread |
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Kindle Touch unbriking troubles | aguzman | Kindle Developer's Corner | 9 | 09-06-2012 07:23 AM |
$0.01 in Kindle Store: Interactive Sudoku for Kindle 2 and Kindle DX - Volume 1 | Xia | Deals and Resources (No Self-Promotion or Affiliate Links) | 2 | 11-07-2009 10:06 AM |