MobileRead Forums - View Single Post

GlutinFreeMan · 10-28-2011, 09:15 AM

Hi -- I'm late to the party, but have essentially the same problem.

Mine's slightly different in that it boots and runs properly, but simply won't update. I made a serial cable and am getting the same kernel panic that vicinc and perldude69 are reporting when I try "run boot_user".

Here's my understanding of the root cause (may be wrong, but it makes sense to me):
There are (at least) two boot images stored in flash. One is used for normal operation and runs out of flash. The other is only used for maintenance and reflashing. The reflashing kernel is copied into RAM and runs from there. The reason it runs out of RAM is because it's not possible to flash the device the OS is running on (that way lies madness).

The problem we're all seeing is that the reflashing kernel has become corrupt for some reason, so it can't run out of RAM after copying it there (it won't unzip). When that happens, the PE then reboots from the normal kernel, and runs from flash. That's fine, except that it won't allow us to reflash ANYTHING.

To fix it we need to either:
1) boot a kernel from another device than onboard flash. An external SD card, USB drive, or network drive should all work.
2) fix the corrupted image, so that it can then be copied to RAM, unzipped, and executed there, so we can then proceed with reflashing.

It sounds like perldude69 is on the right path, trying to rewrite the nand memory. I don't know whether tftp is required though - he should be able to get the same files from the SD card or USB drive (it might be easier that way).

Last night, I tried "run boot_maintsd" from the serial port, and it hung up waiting for the SD card. I didn't have a boot image available on the card at the time. Tonight I think I'll try it again, with a copy of ramdisk.android.gz.crc on the SD card, and see if I can get it to boot. I think if we can a kernel running outside of normal flash, we should be able to repair the corrupted image.

I think we're close.

10-28-2011, 09:15 AM	#34
GlutinFreeMan Junior Member Posts: 8 Karma: 10 Join Date: Oct 2011 Location: Detroit, MI Device: Entourage Pocket Edge	Hi -- I'm late to the party, but have essentially the same problem. Mine's slightly different in that it boots and runs properly, but simply won't update. I made a serial cable and am getting the same kernel panic that vicinc and perldude69 are reporting when I try "run boot_user". Here's my understanding of the root cause (may be wrong, but it makes sense to me): There are (at least) two boot images stored in flash. One is used for normal operation and runs out of flash. The other is only used for maintenance and reflashing. The reflashing kernel is copied into RAM and runs from there. The reason it runs out of RAM is because it's not possible to flash the device the OS is running on (that way lies madness). The problem we're all seeing is that the reflashing kernel has become corrupt for some reason, so it can't run out of RAM after copying it there (it won't unzip). When that happens, the PE then reboots from the normal kernel, and runs from flash. That's fine, except that it won't allow us to reflash ANYTHING. To fix it we need to either: 1) boot a kernel from another device than onboard flash. An external SD card, USB drive, or network drive should all work. 2) fix the corrupted image, so that it can then be copied to RAM, unzipped, and executed there, so we can then proceed with reflashing. It sounds like perldude69 is on the right path, trying to rewrite the nand memory. I don't know whether tftp is required though - he should be able to get the same files from the SD card or USB drive (it might be easier that way). Last night, I tried "run boot_maintsd" from the serial port, and it hung up waiting for the SD card. I didn't have a boot image available on the card at the time. Tonight I think I'll try it again, with a copy of ramdisk.android.gz.crc on the SD card, and see if I can get it to boot. I think if we can a kernel running outside of normal flash, we should be able to repair the corrupted image. I think we're close.