Kindle Touch bricked without USB

[rastik]

I think that the correct steps after my unlucky MMC0 erase were:

- attach serial cable
- boot
- during boot enter recovery menu
- there select "I. Initialize Partition Table (fdisk) and format FAT"
- reboot
- immediately after restart enter any key to stop autoboot
- enter "bist" and then "fastboot"
- via fastboot tool flash diags and data partitions using backed-up data
- reboot
- immediately after restart enter any key to stop autoboot
- boot into diags (run bootargs_diags ; bootm 0xE41000)
- in system diags menu export USB storage (menu "U) USB device mode")
- mount USB storage, copy system partition backup file to it and correctly unmount
- quit USB storage mode (menu "Q ~ to continue")
- get login prompy (menu "D) Exit, Reboot or Disable Diags" and then "L) Exit to login prompt")
- login as root (default password can be calculated but you may as well update your backup to alter it prior fastboot flash)
- flash system partition (dd if=/mnt/base-us/mmcblk0p1.bin of=/dev/mmcblk0p1 bs=16384)
- reboot

I'll try to write some step in more detail on wiki, including "screenshots" of individual menus.

[geekmaster]

Originally Posted by rastik

While I was trying that again and again I accidentaly entered 4 and I lost all partitions. I'm soooo stupid.

Originally Posted by rastik

I think that the correct steps after my unlucky MMC0 erase were...

I see that you upgraded "stupid" to "unlucky". "Unlucky is as unlucky does", to misquote a line from a famous feature film.

We have now graduated from kindle touch brick recovery using the internal serial port, to debricking with the tar bug, to fastboot recovery. It is excellent to have multiple debricking options. I think we can call that serious progress.

I am looking forward to seeing this in the wiki.

[yifanlu]

Originally Posted by rastik

I think that the correct steps after my unlucky MMC0 erase were:

- attach serial cable
- boot
- during boot enter recovery menu
- there select "I. Initialize Partition Table (fdisk) and format FAT"
- reboot
- immediately after restart enter any key to stop autoboot
- enter "bist" and then "fastboot"
- via fastboot tool flash diags and data partitions using backed-up data
- reboot
- immediately after restart enter any key to stop autoboot
- boot into diags (run bootargs_diags ; bootm 0xE41000)
- in system diags menu export USB storage (menu "U) USB device mode")
- mount USB storage, copy system partition backup file to it and correctly unmount
- quit USB storage mode (menu "Q ~ to continue")
- get login prompy (menu "D) Exit, Reboot or Disable Diags" and then "L) Exit to login prompt")
- login as root (default password can be calculated but you may as well update your backup to alter it prior fastboot flash)
- flash system partition (dd if=/mnt/base-us/mmcblk0p1.bin of=/dev/mmcblk0p1 bs=16384)
- reboot

I'll try to write some step in more detail on wiki, including "screenshots" of individual menus.

Hmm, "bist". I'm curious if that's the thing that made it work. I know it's asking too much, but if someone will try to flash diags without first going to "bist" mode and then with and see if it didn't work before and worked afterwards.

[rastik]

Originally Posted by yifanlu

Hmm, "bist". I'm curious if that's the thing that made it work. I know it's asking too much, but if someone will try to flash diags without first going to "bist" mode and then with and see if it didn't work before and worked afterwards.

No, not really. I used bist just to activate fastboot. I could use idme to change bootmode and restart. I found bist useful so far only in activating fastboot and activating file storage mode (fstor) command. With that I was able to charge the device while in uboot. It seems that KT is charging only when in USB mass storage mode - either via fstor (where you cannot do anything else apart from restart) or when framework is booted, usbnet is not active and KT is plugged to the computer.

uboot > ?
?       - alias for 'help'
bist    - start Built In Self Test
boot    - boot default, i.e., run 'bootcmd'
bootd   - boot default, i.e., run 'bootcmd'
bootm   - boot application image from memory
go      - start application at address 'addr'
help    - print online help
idme    - idme    - Set nv ram variables
log     - manipulate logbuffer
printenv- print environment variables
reset   - Perform RESET of the CPU
run     - run commands in an environment variable
setenv  - set environment variables
version - print monitor version

bist offers quite a lot of functionality:

bist > help
?       - alias for 'help'
autoscr - DEPRECATED - use "source" command instead
base    - print or set address offset
boot    - boot default, i.e., run 'bootcmd'
bootd   - boot default, i.e., run 'bootcmd'
bootm   - boot application image from memory
check   - perform MMC CRC32 check
cmp     - memory compare
coninfo - print console devices and information
cp      - memory copy
crc32   - checksum calculation
diag    - perform board diagnostics
echo    - echo args to console
fail    - fail blink fail pattern on LED
fastboot- Fastboot
fstor   - File Storage
go      - start application at address 'addr'
halt    - halt board
help    - print online help
i2c     - I2C sub-system
idme    - idme    - Set nv ram variables
iminfo  - print header information for application image
itest   - return true/false on integer compare
loadb   - load binary file over serial line (kermit mode)
loads   - load S-Record file over serial line
loady   - load binary file over serial line (ymodem mode)
loop    - infinite loop on address range
loopw   - infinite write loop on address range
md      - memory display
mm      - memory modify (auto-incrementing address)
mmc     - MMC sub system
mmcinfo - mmcinfo <dev num>-- display MMC info
mtest   - simple RAM read/write test
mw      - memory write (fill)
nm      - memory modify (constant address)
ocotp   - OCOTP sub system
panic   - panic halt
pass    - pass blink pass pattern on LED
pmic    - pmic    - PMIC utility commands
printenv- print environment variables
reset   - Perform RESET of the CPU
run     - run commands in an environment variable
setenv  - set environment variables
sleep   - delay execution for some time
source  - run script from memory
sspi    - SPI utility commands
version - print monitor version

[geekmaster]

Originally Posted by rastik

It seems that KT is charging only when in USB mass storage mode ...

I agree. There was a discussion about this on the IRC channel.

I thought my kindle touch was bricked, when really the battery went totally dead with the green LED still on while connected to usbnet. After unplugging, it would not start, and would not show up as usbnet or usbdrive. It had to charge for hours before the led would even flicker when trying to turn it on. It took 14 hours to reach full charge. That cannot be good for the battery. I can leave my other kindles attached to usbnet for weeks at a time while they remain accessible.

Discharging a lithium battery that far can severely shorten its lifespan.

The usbnet code must be modified to activate the battery charge, or it will cause destroyed batteries.

[eureka]

@rastik Sorry for hijacking thread, but I'm wondering what is showed on serial console while booting in "USB download" mode (booting with pressed Home button). And you has a serial cable right under hand, right? I'm interested, does entering into "USB download" mode handled completely by hardware (even before u-boot is started), or by u-boot, or by kernel, or by what? Could you please check this?

[yifanlu]

Originally Posted by rastik

No, not really. I used bist just to activate fastboot. I could use idme to change bootmode and restart. I found bist useful so far only in activating fastboot and activating file storage mode (fstor) command. With that I was able to charge the device while in uboot. It seems that KT is charging only when in USB mass storage mode - either via fstor (where you cannot do anything else apart from restart) or when framework is booted, usbnet is not active and KT is plugged to the computer.

uboot > ?
?       - alias for 'help'
bist    - start Built In Self Test
boot    - boot default, i.e., run 'bootcmd'
bootd   - boot default, i.e., run 'bootcmd'
bootm   - boot application image from memory
go      - start application at address 'addr'
help    - print online help
idme    - idme    - Set nv ram variables
log     - manipulate logbuffer
printenv- print environment variables
reset   - Perform RESET of the CPU
run     - run commands in an environment variable
setenv  - set environment variables
version - print monitor version

bist offers quite a lot of functionality:

bist > help
?       - alias for 'help'
autoscr - DEPRECATED - use "source" command instead
base    - print or set address offset
boot    - boot default, i.e., run 'bootcmd'
bootd   - boot default, i.e., run 'bootcmd'
bootm   - boot application image from memory
check   - perform MMC CRC32 check
cmp     - memory compare
coninfo - print console devices and information
cp      - memory copy
crc32   - checksum calculation
diag    - perform board diagnostics
echo    - echo args to console
fail    - fail blink fail pattern on LED
fastboot- Fastboot
fstor   - File Storage
go      - start application at address 'addr'
halt    - halt board
help    - print online help
i2c     - I2C sub-system
idme    - idme    - Set nv ram variables
iminfo  - print header information for application image
itest   - return true/false on integer compare
loadb   - load binary file over serial line (kermit mode)
loads   - load S-Record file over serial line
loady   - load binary file over serial line (ymodem mode)
loop    - infinite loop on address range
loopw   - infinite write loop on address range
md      - memory display
mm      - memory modify (auto-incrementing address)
mmc     - MMC sub system
mmcinfo - mmcinfo <dev num>-- display MMC info
mtest   - simple RAM read/write test
mw      - memory write (fill)
nm      - memory modify (constant address)
ocotp   - OCOTP sub system
panic   - panic halt
pass    - pass blink pass pattern on LED
pmic    - pmic    - PMIC utility commands
printenv- print environment variables
reset   - Perform RESET of the CPU
run     - run commands in an environment variable
setenv  - set environment variables
sleep   - delay execution for some time
source  - run script from memory
sspi    - SPI utility commands
version - print monitor version

Wow! Thanks for this. Now I know it is possible to reflash the kernel/bl from uboot.

[rastik]

Originally Posted by yifanlu

Wow! Thanks for this. Now I know it is possible to reflash the kernel/bl from uboot.

Yes, it should be. Excellent idea! fastboot allows to access those partitions and KT uboot sources specify addresses. But I've never tried that.
I've already made a backup of first 32M of /dev/mmcblk0. It's good to have two kernels there so when your main is not working you can boot diags kernel and rewrite everything back.

[rastik]

Originally Posted by eureka

@rastik Sorry for hijacking thread, but I'm wondering what is showed on serial console while booting in "USB download" mode (booting with pressed Home button). And you has a serial cable right under hand, right? I'm interested, does entering into "USB download" mode handled completely by hardware (even before u-boot is started), or by u-boot, or by kernel, or by what? Could you please check this?

Hi, console showed nothing. It seems that it is intercepted by HW and when it detects Home button pressed during boot up it will not load uboot. And whatever is responsible for USB/HID download mode, it does not output anything to console.
Thinking of it that makes sense. This mode is wired in the i.MX50 chip and the chip is not aware of the console. Only apps are.

[yifanlu]

Yes. I love how the device is physically brick proof. Well, brick proof from software.

[eureka]

Originally Posted by rastik

Hi, console showed nothing. It seems that it is intercepted by HW and when it detects Home button pressed during boot up it will not load uboot. And whatever is responsible for USB/HID download mode, it does not output anything to console.
Thinking of it that makes sense. This mode is wired in the i.MX50 chip and the chip is not aware of the console. Only apps are.

Wonderful! Thanks!

Yes, mode is wired in chip but it can initiated either by hardware (with setting of "boot mode" pins), or by software (with calling into USB downloader code from running program). I was unsure, which method is used in KT, but now it seems that Home button is connected to "boot mode" pin(s) and USB downloader mode is initiated by hardware even before U-Boot loading.

[geekmaster]

Originally Posted by eureka

Wonderful! Thanks!

Yes, mode is wired in chip but it can initiated either by hardware (with setting of "boot mode" pins), or by software (with calling into USB downloader code from running program). I was unsure, which method is used in KT, but now it seems that Home button is connected to "boot mode" pin(s) and USB downloader mode is initiated by hardware even before U-Boot loading.

If correct, it would be safe to customize U-Boot or replace it with a different boot loader. That would require using SPI (or possibly i2c) to write to the serial memory chip containing the boot loader. Any errors and you could recover with USB downloader boot mode. At least you could replace the missing or disabled functions in the touch U-Boot.

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

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

If uboot is in mmc then mmc0 must start at some offset in the mmc device. Many devices with uboot load it from a serial memory device (SPI or i2c). The kindle must be different in how it boots up. I thought it was uboot that initialized and mounted the mmc device.

Of course you probably actually read the uboot source code from amazon. I was just going by how other uboot devices operate.

[geekmaster]

Originally Posted by rastik

Hi, console showed nothing. It seems that it is intercepted by HW and when it detects Home button pressed during boot up it will not load uboot. And whatever is responsible for USB/HID download mode, it does not output anything to console.
Thinking of it that makes sense. This mode is wired in the i.MX50 chip and the chip is not aware of the console. Only apps are.

My K4NT is stuck in USB HID mode from holding the select button during reset.

Unlike your touch, my K4NT sends this out the serial port:

U-Boot 2009.08-lab126 (Sep 02 2011 - 22:45:17)

CPU:   Freescale i.MX50 family 1.1V at 800 MHz
mx50 pll1: 800MHz
mx50 pll2: 400MHz
mx50 pll3: 216MHz
ipg clock     : 50000000Hz
ipg per clock : 50000000Hz
uart clock    : 24000000Hz
ahb clock     : 100000000Hz
axi_a clock   : 400000000Hz
axi_b clock   : 200000000Hz
weim_clock    : 100000000Hz
ddr clock     : 800000000Hz
esdhc1 clock  : 80000000Hz
esdhc2 clock  : 80000000Hz
esdhc3 clock  : 80000000Hz
esdhc4 clock  : 80000000Hz
MMC:  FSL_ESDHC: 0, FSL_ESDHC: 1
Board: Unknown
Boot Reason: [POR]
Boot Device: MMC
Board Id: 1
S/N: 1
Invalid board id!  Can't determine system type for RAM init.. bailing!
DRAM:   0 kB
Using default environment

This seems rather odd -- is that normal for USB HID mode?

Using the freescale tool, I tried sending "random" code (the sb_loader.exe renamed to default filename firmware.sb, actually). Here is what I did and the results:

D:\freescale\sb_loader.v1.1-g63b47f0>sb_loader -trans
Succeeded to download  to the device.

D:\freescale\sb_loader.v1.1-g63b47f0>sb_loader -exec
Jump to RAM successfully.

D:\freescale\sb_loader.v1.1-g63b47f0>sb_loader -tss
  Failed to run plugin  to the device.

So it seems to communicate of usb hid mode. but the usb bus resets after the -exec. Not surprising because it probably crashed on random code.

What I really want to do is get out of HID mode.

P.S. I posted this here even though not touch because relevant to rastik's post quoted above.