Bricked

From Openmoko

Revision as of 10:10, 12 August 2007 by ScaredyCat (Talk | contribs)

Jump to: navigation, search

Contents

Notes on a 'bricked' Neo

I've just spent a very long time, with the help of a few people on irc (who I now owe drinks to), trying to recover my Neo. This page is the result and is supposed to act as a collection of information to help owners with bricked or semi-bricked devices.


The Problem defined

A typing error in the splashimage environment variable resulted in the splash image being read into the memory starting at 0x200000 rather than 0x32000000. The change was written, with the error being unnoticed, using saveenv. As a result it was not possible to connect the device to usb until it had booted fully. Any attempt to either start with usb plugged in or plugging it in at the u-boot prompt resulted in a locked up device. Looking at dmesg on the host the following errors were reported

usb 3-1: new full speed USB device using uhci_hcd and address 21
usb 3-1: device not accepting address 21, error -110

(the address number will change).

So the problem was that although the device could now boot there was no way to flash it with dfu.

The Solution

The solution was to try and prevent the splashimage environment variable from being looked at, thus preventing the write to the wrong area of memory.

Attempt 1

The idea was to dump mtdblock1 to a file, scp the file to a PC, hex edit it scp the file back to the phone and then dd the result into the mtdblock.

On the Neo

dd if=/dev/mtdblock1 of=mtdblock1.bin

Rebooting was required because of the i/o errors. The i/o error problem has been reported as bug 567


Discoveries

1. You can use dd to extract and overwrite your mtd partitions. This works particularly well for u-boot-env and splash providing the source device has a similar partition layout. Doing this on the u-boot partition was not tested. However, after you have used dd on the mtdblock devices as either the if= or of= you get i/o errors with even basic commands. The only way to get round this is to 'reboot' by removing the battery.


2. Hex editing the extracted mtd partition (u-boot-env) and trying to dd that works but the results are not what is expected. It appears that if one of the boot env parameters is missing, in this case splashimage, the u-boot-env parameters are all treated as if they were blank and the device uses default settings.


3. QEMU is very useful for testing out your theories before actually doing them on a real device. Most of the things we tried were tried on qemu first. Sadly QEMU's sd card emulation appears to be broken.

Useful information

On your Neo:

cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00040000 00004000 "u-boot"
mtd1: 00004000 00004000 "u-boot_env"
mtd2: 00200000 00004000 "kernel"
mtd3: 000a0000 00004000 "splash"
mtd4: 03d1c000 00004000 "rootfs
Personal tools

Notes on a 'bricked' Neo

I've just spent a very long time, with the help of a few people on irc (who I now owe drinks to), trying to recover my Neo. This page is the result and is supposed to act as a collection of information to help owners with bricked or semi-bricked devices.


The Problem defined

A typing error in the splashimage environment variable resulted in the splash image being read into the memory starting at 0x200000 rather than 0x32000000. The change was written, with the error being unnoticed, using saveenv. As a result it was not possible to connect the device to usb until it had booted fully. Any attempt to either start with usb plugged in or plugging it in at the u-boot prompt resulted in a locked up device. Looking at dmesg on the host the following errors were reported

usb 3-1: new full speed USB device using uhci_hcd and address 21
usb 3-1: device not accepting address 21, error -110

(the address number will change).

So the problem was that although the device could now boot there was no way to flash it with dfu.

The Solution

The solution was to try and prevent the splashimage environment variable from being looked at, thus preventing the write to the wrong area of memory.

Attempt 1

The idea was to dump mtdblock1 to a file, scp the file to a PC, hex edit it scp the file back to the phone and then dd the result into the mtdblock.

On the Neo

dd if=/dev/mtdblock1 of=mtdblock1.bin

Rebooting was required because of the i/o errors. The i/o error problem has been reported as bug 567


Discoveries

1. You can use dd to extract and overwrite your mtd partitions. This works particularly well for u-boot-env and splash providing the source device has a similar partition layout. Doing this on the u-boot partition was not tested. However, after you have used dd on the mtdblock devices as either the if= or of= you get i/o errors with even basic commands. The only way to get round this is to 'reboot' by removing the battery.


2. Hex editing the extracted mtd partition (u-boot-env) and trying to dd that works but the results are not what is expected. It appears that if one of the boot env parameters is missing, in this case splashimage, the u-boot-env parameters are all treated as if they were blank and the device uses default settings.


3. QEMU is very useful for testing out your theories before actually doing them on a real device. Most of the things we tried were tried on qemu first. Sadly QEMU's sd card emulation appears to be broken.

Useful information

On your Neo:

cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00040000 00004000 "u-boot"
mtd1: 00004000 00004000 "u-boot_env"
mtd2: 00200000 00004000 "kernel"
mtd3: 000a0000 00004000 "splash"
mtd4: 03d1c000 00004000 "rootfs