Kindle Touch bricked without USB

[geekmaster]

Originally Posted by yifanlu

Uboot is on the mmc along with the kernel, serial/Mac address, and root partition. They can all be flashed from within Uboot and USB download mode.

I want to understand the kindle boot process so I can execute some code in RAM from USB/HID mode in my bricked K4NT.

The CPU in the new kindles contains a 96KB internal boot ROM (more info here): http://cache.freescale.com/files/32b...t/IMX50CEC.pdf

The boot code in this internal boot ROM is what initializes and mounts the external MMC, from which the linux kernel is loaded. This internal ROM is the same size as u-boot, as shown in this typical example taken from the "Das U-Boot" web page:

u-boot # tftp 8000 u-boot.bin
From server 10.0.0.1; our IP address is 10.0.0.11
Filename 'u-boot.bin'.
Load address: 0x8000
Loading: ###################
done
Bytes transferred = 95032 (17338 hex)

U-boot knows how to flash this internal flash boot ROM, as well as multiple kinds of external flash memory, including MMC. The MMC in the kindle begins with a partition table, and all four partitions are dedicated to other uses.

If u-boot were in the MMC, where would it go, and what code would then be in the "u-boot sized" Rflash ROM inside the CPU chip? The internal boot loader would have to include much of u-boots functionality just to initialize MMC and "boot" u-boot from MMC, so it might just as well boot the linux kernel directly.

If u-boot is in MMC as you say, could you please point me to some documentation that shows how and where u-boot *can* be loaded from MMC? Thanks.

[eureka]

I suppose that in Kindle Touch u-boot is in serial flash chip shown by "Cracking open ..." article. I've made full dump of MMC (/dev/mmcblk0) and didn't found any traces of u-boot. But dump file is of 3959422976 bytes long, so it isn't exactly 4G, so it leaves Yifan Lu's theory possibly valid (maybe part of MMC where u-boot is located is hidden from Linux kernel). But, on other side, there is low-level eMMC initialization code in u-boot sources of KT, so it looks like u-boot is loaded not from eMMC...

[geekmaster]

Originally Posted by eureka

I suppose that in Kindle Touch u-boot is in serial flash chip shown by "Cracking open ..." article..
...

That flash chip is on the eInk display flex cable. On the k4nt teardown, it was dumped and contained no code. It was speculated that because is contains only "numbers" and it is attached to the replaceable display, it contains eInk calibration data.

Because the Freescale iMX50 CPU chip contains in internal flash boot ROM that is the same size as a typical uboot.bin file, it makes much more sense that u-boot is in the internal flash ROM in the CPU package.

Thanks for confirming that u-boot is not in MMC. This provides one more step on my path of discovery to writing some raw code to inject into kindle RAM and execute with USB/HID mode.

[eureka]

Originally Posted by geekmaster

Because the Freescale iMX50 CPU chip contains in internal flash boot ROM that is the same size as a typical uboot.bin file, it makes much more sense that u-boot is in the internal flash ROM in the CPU package.

Thanks for confirming that u-boot is not in MMC. This provides one more step on my path of discovery to writing some raw code to inject into kindle RAM and execute with USB/HID mode.

Well, I didn't confirmed that u-boot isn't at MMC. And I'm not confirming it now. I've just provided one relevant fact.

Also, I think that i.MX50 boot ROM couldn't be reprogrammed. It's a ROM. And I didn't found anything about boot ROM reprogramming at i.MX50 Reference Manual. Boot ROM supports ROM patching, but it's a runtime mechanism, not one-time reprogramming.

Besides, Kindle u-boot size could be not the same as typical u-boot size.

[PoP]

Originally Posted by yifanlu

Uboot is on the mmc along with the kernel, serial/Mac address, and root partition. They can all be flashed from within Uboot and USB download mode.

I concurr.

I don't have a KTouch or KindleNonTouch which might be different, but in this old Kindle3 post https://www.mobileread.com/forums/sho...7&postcount=10

You can see that the first partition on my Kindle3 starts at block 7688 of the mmc.
Inspecting the blocks prior to the first partition with a hex editor also showed interesting pieces of information, including what appears to be the bootloader.

Offset:
00012F20 U-BOOT 1.3.0-rc3-lab126 [Boot Loader Id]
00040C00 B0A8XXXXXXXXXXXX [Serial Number]
00040C58 28EF01XXXXXX [MAC Address]
00040C64 A0036XXXXXXXX [PCB ID]
00040C80 OH40TWXXXXXXXXXXXXXX [Manufacturer Code]
00041040 Linux-2.6.26-rt-lab126 [Kernel Id]

[geekmaster]

How is ROM patching different from flashing?

What size is the Kindle U-Boot image (after stripping)?

Wherever U-Boot loads from, it is running when USB/HID mode is active. It also has initialized serial I/O and MMC. I would like to be able to call it to output to the serial port, and to access wherever idme stores the board ID and serial number.

So perhaps u-boot lives in the boot record in the partition table then, just like a bootable hard drive contains a boot loader starting on sector zero that interprets the partition table (if it finds one) and loads and executes another boot loader from the primary bootable partition.

Then the code in the CPU must just be to find and load u-boot on whichever supported device contains it, including MMC.

If u-boot lives in sector zero of the partition table, it would start at address zero of the MMC.

I thought eureka examined all of mmc0 and did not see the u-boot information given by PoP.

Still confused, more or less...

[eureka]

Originally Posted by PoP

I don't have a KTouch or KindleNonTouch which might be different, but in this old Kindle3 post https://www.mobileread.com/forums/sho...7&postcount=10

You can see that the first partition on my Kindle3 starts at block 7688 of the mmc.
Inspecting the blocks prior to the first partition with a hex editor also showed interesting pieces of information, including what appears to be the bootloader.

Offset:
00012F20 U-BOOT 1.3.0-rc3-lab126 [Boot Loader Id]
00040C00 B0A8XXXXXXXXXXXX [Serial Number]
00040C58 28EF01XXXXXX [MAC Address]
00040C64 A0036XXXXXXXX [PCB ID]
00040C80 OH40TWXXXXXXXXXXXXXX [Manufacturer Code]
00041040 Linux-2.6.26-rt-lab126 [Kernel Id]

Data from Kindle Touch:

[root@kindle root]# fdisk -l -u /dev/mmcblk0

Disk /dev/mmcblk0: 3959 MB, 3959422976 bytes
4 heads, 16 sectors/track, 120832 cylinders, total 7733248 sectors
Units = sectors of 1 * 512 = 512 bytes

        Device Boot      Start         End      Blocks  Id System
/dev/mmcblk0p1   *       65536      782335      358400  83 Linux
/dev/mmcblk0p2          782336      913407       65536  83 Linux
/dev/mmcblk0p3          913408      978943       32768  83 Linux
/dev/mmcblk0p4          978944     7733247     3377152   b Win95 FAT32

Still, I can't find any traces of u-boot code in dump of /dev/mmcblk0. (Though, kernel is definitely there, Kernel Id is somewhere near address given by you). I've searched for 'u-boot' and didn't found any Boot Loader Id.

[eureka]

Originally Posted by geekmaster

How is ROM patching different from flashing?

ROM patching intercepts access to given memory address in runtime. And, I believe, it should be setup in runtime too. Is it different from flashing? If you are curious, you should look into i.MX50 Reference Manual for further information.

Originally Posted by geekmaster

What size is the Kindle U-Boot image (after stripping)?

I don't know. Did you measured it's size? If not, why it couldn't be more than 96KB? I think it's possible. So, I've said it without rhethorical questions.

[yifanlu]

Originally Posted by eureka

Data from Kindle Touch:

[root@kindle root]# fdisk -l -u /dev/mmcblk0

Disk /dev/mmcblk0: 3959 MB, 3959422976 bytes
4 heads, 16 sectors/track, 120832 cylinders, total 7733248 sectors
Units = sectors of 1 * 512 = 512 bytes

        Device Boot      Start         End      Blocks  Id System
/dev/mmcblk0p1   *       65536      782335      358400  83 Linux
/dev/mmcblk0p2          782336      913407       65536  83 Linux
/dev/mmcblk0p3          913408      978943       32768  83 Linux
/dev/mmcblk0p4          978944     7733247     3377152   b Win95 FAT32

Still, I can't find any traces of u-boot code in dump of /dev/mmcblk0. (Though, kernel is definitely there, Kernel Id is somewhere near address given by you). I've searched for 'u-boot' and didn't found any Boot Loader Id.

This is just my prediction, but it may be that in Linux, there is no read (and maybe no write) access to some parts of the mmc. For example, I took the Uboot offset for the kernel and dumped that part of /dev/mmcblk0 and got the kernel. System too. But when attempting to dump the serial & boardid information as defined by the offsets in Uboot source, I get all zeros. Maybe it's to protect the device from a virus or something?

I also do know that by dumping the mmc from Uboot on my kindle 2, I get the serial number information, Uboot, and other stuff (eink calibration data). That's where my information came from. I have yet confirmed if it is the same on k4/kt.

[eureka]

I've found that eMMC could have "hardware" boot partitions. Which aren't overlapped with user accessible area. (some info)

I've also found path /sys/block/mmcblk0/device/boot_config somewhere in MMC dump, before even start of first partition. Near of this path are strings about update etc., so it should be used by the code from kernel that handles "recovery" updates.

Now, looking at drivers/mmc/core/mmc.c at KT kernel sources, this boot_config file is write-only. And writing to it configures boot partitions. Don't mess with it by writing random values. It could be dangerous.

There is also /sys/block/mmcblk0/device/boot_info which is safe to read. Information from it could be interpreted somehow through reading of mmc.c.

Linux eMMC driver, used in KT, doesn't see boot paritions. So it's possible that u-boot is stored on it. (BTW, recent eMMC drivers could see these partitions as separate /dev/mmcblk0bootX, as patch has been provided.)

EDIT: there are some suspicious comments in mmc.c:

	/* switch the partitions that used to be accessed in OS layer */
	/* partition must be -
	 * 0 - user area
	 * 1 - boot partition 1
	 * 2 - boot partition 2
	 */

	/* Send SWITCH command to change partition for access */

UPD: and according to i.MX50 MCU Reference Manual, it can boot from such the boot partition.

[geekmaster]

I wonder how idme is able to read and write that information if it is hidden.

[yifanlu]

Originally Posted by geekmaster

I wonder how idme is able to read and write that information if it is hidden.

That's why I believe it may be write only. Because idme's code uses /proc/serial and stuff to read and fwrite() to write vars to the mmc. The /proc entries could be exported by the kernel, because otherwise, why not just fread() the mmc.

[eureka]

Just a note: /proc entries used by idme are set by kernel at arch/arm/mach-mx5/boardid.c. There is a comment for init procedure: "copy the serial numbers from the special area of memory into the kernel". And these /proc files are read-only.