[Q] semi-Bricked?? fix?

fastboot will do nothing useful for you if you have the 1.49.0000 S-ON bootloader.

The basic definition of a brick for the Eris is this:

1.49.0000 S-ON bootloader + no recovery + non-booting OS = brick


So, let's review.

1) You have 1.49.0000 S-ON. There is no PB00IMG.zip available to you that can change that using Hboot (without performing some magic with a custom recovery first), and fastboot is worthless with S-ON. So, no go there.

2) You didn't mention (or your description was lacking detail) what happens when you try to go into the Hboot menu (cold start with Vol-Down+End). From there you might be able use the menu to try to launch the recovery boot, to see whether (a) it is the stock recovery, (b) it is a custom recovery, or (c) it fails to start. You should try that next.

If that doesn't work, try a cold start with Vol-Up + End. (You need to keep holding both the buttons down until the screen lights up). That is an alternate way to get to the recovery (when a 1.49.xxxx bootloader is on the phone).

If you have a "stock" recovery, you will see a splash screen with an image of the phone and a triangle with an exclamation point in it. (Pressing Vol-Up+End after you see that splash screen will show a blue menu). If you have Amon_RA's custom recovery, you will see a green menu.


3) If your kernel boots, but the OS is "hanging", there is a remote possibility that you can initiate a factory reset from the "hung" OS. This is a long shot, but you power up the phone normally and then press together Vol-Up+Send+End after waiting a couple of minutes. This might make it bootable. (As I said, "long shot". The fact that you have 1.49.0000 on the phone suggests that the prior owner tried some things - and apparently failed at it.)


bftb0

SoSicWiTiT said:

thanks for the response

i tried all of that just now and all i get is a black backlit screen unless i connect usb which gives me a black screen with HTC n four exclamation point triangles in the corners. and there isnt anything i can do from that screen and its bricked huh?

Click to expand...

Click to collapse

That's not a very good sign. I will say, however, that it is very strange that you can get the phone into RUU mode but not have a working bootloader - those two observations are mutually exclusive.

For grins, you could check to see if perhaps your Vol-Up/Vol-Down keys are broken by doing the following:

- Cold start the phone by pressing Send + End simultaneously (make sure to press Send first so that you are not initiating a normal boot; hold both keys down until the screen lights up). Make sure you pull the battery and have the USB cable disconnected when you pull the battery before you try this (to insure that the phone is "really" off).

If that works, the phone will be in Fastboot mode. You might be able to get into Hboot (but not recovery if your Vol-Up/Vol-down keys are broken) at that point with the command
from a USB-connected PC.

Under normal circumstances, you can navigate from Fastboot Mode to Hboot and then from there to the Recovery boot - but this requires working Vol-Up or Vol-Down keys.

There is a very, very slim chance that if you can get Hboot launched this way (that is "fastboot reboot-bootloader")... and try to apply the Leak-V3 "PB00IMG.zip" file. If I recall correctly, you don't need Vol-Up/Vol-Down to apply an HTC PB00IMG.zip file - just the trackball press.

I'm not optimistic though - I think that the Leak-V3 (and all other Leak PB00IMG.zip) files probably will just fail with "Main Version is Older Messages".


As for other avenues of approach, there are no publicly known exploits of the RUU mode (= oem-78 mode).


Good luck

Hmmm, interesting.

Whether or not that qualifies as new behavior sort of depends on what your "friend" did to the phone prior to getting it into the nearly bricked state. If they had previously run the jcase "Flash any RUU" method, then the Root ROM would have "taken" with the Hboot method... although in your case, since you "couldn't get there from here", my hat's off to you for a clever way of making the best of what you have!

Since you have the S-off bootloader, you might be tempted to direct-boot Amon_Ra without even bothering to flash it:


to see if your phone springs to life... congrats if you see a menu!

I have a couple ideas (still typing them up) ... in the meantime, if you boot Amon_RA and then open up a shell from the PC ("adb shell") and then

- check the output of "dmesg" to insure that the MTD partition table is still intact; you should see something like this towards the beginning of the boot log:


- try mounting (in turn) each of /system, /data, /sdcard, e.g.:

/cache should already be mounted.

Which mounts fail?


bftb0

The scenario you describe has come up before - or at least very similar symptoms.

Note that Nandroid restore will fail because it uses standard Unix tools such as "rm" to clear filesystems, so if a partition will not mount because of a corruption issue, nandroid will fail. I suppose that the same thing is true of the /sbin/recovery utility running underneath the booted recovery kernel (but I have not read the source code to verify that it is attempting to "mount" the filesystems first - if it didn't do that, it would need to understand the raw format details of yaffs2, and I think that is a stretch).

Unfortunately the filesystem formatting tools provided by Amon_RA do not include tools for repairing the mtd (NAND flash) - they are for the SD card/ extN filesystems. It is my impression, however, that the "yaffs2" filesystem is "format free" - meaning that a clean (Flash memory) "yaffs2" filesystem is simply a bunch of zero'ed pages - no superblocks, or Inode lists, - none of that. This suggests that the equivalent of "dd if=/dev/zero of=/dev/mtd/mtdNNN bs=..." could "repair" a yaffs2 file system by simply wiping it... but let's try something a little less crude than that (see below).


I had one of the file systems in my phone in this state at one time and I was able to repair the problem by reflashing the Root ROM - otoh, XDA user "stick" tried this and it seemed to produce a permanent brick in his case, so I am reluctant to recommend you do that. (You might, however, want to perform the jcase "Flash any RUU" hack to the "misc" partition so that you have flexibility to apply any PB00IMG.zip file)

Because the "flash_image" tool (in /sbin/flash_image in Amon_RA) writes both boot images and yaffs2 image files to arbitrary mtd partitions (and raw binary files to "misc"!), there is a chance that it is merely the equivalent of "dd for the MTD device" - so that you could "repair" a corrupted yaffs2 filesystem by simply overwriting it with a valid yaffs2 image file. The repair strategy here would be to:

- Unpack any PB00IMG.zip file and move the contents to a folder on the SD card. (Verify the md5sums of the files on the SD card before you use them - use this reference)

- Use "flash_image" from Amon_RA to flash the corresponding image file for the offending ("won't mount") partition, e.g.


If this succeeds, see if you can "mount /system".


bftb0


PS Don't try flashing "system.img" using fastboot. However it is engineered (by the HTC bootloader) it will fail due to space issues. It is possible that the HTC bootloader uses the /cache partition to temporarily stage the file, which is only 130 MB compared to 159.5 MB for the /system partition - but whatever the explanation, the experimental result is that that on the Eris, you can not flash /system from fastboot. All the other partitions, no problem - but not the /system partition.

SoSicWiTiT said:

thanks,

i tried what you suggested and it let me mount all 3 of those partitions, and i tried using flash_image to flash the system.img i extracted and in return got a million and one errors..

starting with mtd: ECC error soft 0 hard 1 (continuing until about a hundred something)
then

mtd: not writing bad block at (basically the entire /system hex range)

then finally

error writing system: no space left on device

Click to expand...

Click to collapse

Was the partition table information correct? (I have seen innocuous "write error" messages on my phone, but they only occurred on regular block boundaries - not for every page; but in that case I don't think I ever saw an "out of space" message. Assuming everything was performed correctly, your phone is behaving as if large blocks of flash memory are being skipped due to "bad blocks")

Did you unmount the filesystems prior to doing the writes?

That is very mystifying.

If you can mount /system, or /data, what happens when you go in and do a


If those succeed, unmount everything


Run an Amon_RA "wipe data/factory reset", and try and flash a ROM.

???


bftb0

One other thing you could try - I have never used it, so I don't know what effect it will have - is to use fastboot mode to erase the "system" and "data" partitions, and see if that has any effect on your ability to flash a ROM.

In fastboot (boot w/ Send+End) mode:

And then afterward boot into Amon_RA and try flashing a ROM.

I suppose you could also erase the boot partition this way, but you probably ought to do them one at a time just to minimize erase operations - and then if an operation fails in Amon_RA, examine the log file at


to see if it provides further elaboration on the nature of the error(s).


bftb0

Something else to try:

The symptoms you have (esp. since it appears that /system and /data will mount correctly) appear as if you "run out of space" when flashing ROMs to NAND. I suppose that could occur if somehow a bunch of pages in flash memory got (erroneously) marked invalid. Unless there is some means to clear flash memory so that bad page indicators are cleared, there is no way to reclaim those pages. (It is my impression that brand new NAND flash chips are already programmed with bad pages pre-marked)

It would be nice if the partition erase function of fastboot actually performed the page reclaim/retesting/re-marking operation - but there is no way to know whether that happens, as the HTC bootloader acts as the interpreter of "fastboot commands" passed over the wire (USB). It is free to implement whatever bad page management strategy that HTC desires - and frankly, a "never reclaim bad pages" policy is fairly reasonable when you consider that most consumer phones are flashed perhaps only 3 or 4 times in their lifetime - if that.

Something to try: if you perform a manual wipe of either /system or /data (after mounting them), do a "df" to see how much free space the kernel thinks they have - for a normal phone, that should be pretty darn close to the partition size. E.G.


If it seems "short" by a substantial amount, try installing a "small footprint" ROM, such as CELBFroyo 3.2 - it only uses about 100216 KB (97.9 MB).

Just a thought; I realize this is grasping at straws, but there is little for you to lose (which you knew right from the get-go).


bftb0

SoSicWiTiT said:

the system partition is 66% used (bad blocks im guessing) after a format leaving 59,648 useable

Click to expand...

Click to collapse

Holy crap!

For grins, could you do a "cat /proc/yaffs" and post up the section for the "system" partition? (You need /system to be mounted when you run that command).

Here's what mine looks like after performing an erase with fastboot, booting into Amon_RA, and then mounting it:


I wonder what your "nRetireBlocks" count is.

I only poked around in the HTC "msm_7k" kernel code a little while ago for some clues, so I'm no expert. There does not seem to be any useful knobs to turn by using mount options.

Because Flash filesystems have to deal with new bad pages as they develop, I'll bet the phone could be completely fixed if there was a way to clear the bad pages - ( if they were actually bad, then on the first write use the write would fail, the pages would be marked bad, and the FS driver would recover gracefully - just as normally happens).

But as you say, that would probably require a custom kernel at the minimum with patches to the mtd driver. I do wonder if the kernel driver for the MTD device exposes any hooks (ioctls, etc) that would let you write a (privileged) userspace app which could wipe the raw pages status info.

This YAFFs doc suggests that certain tuning operations can be performed by writing options to /proc/yaffs, including control of tracing. One of the things that seems possible to control is the number of write attempts per page.

I'll have a look at your URL; no promises, though.


bftb0

[ Edit ] PS - do you have any idea what your friend did to get the phone in this state? Maybe flashing a ROM with really, really low battery? It seems hard to believe that an actual hardware problem occurred - moreover, this is not the first phone where very similar symptoms were exhibited.

I'm wondering if a busybox with mtd-utils compiled in might be of some assistance; in particular the "flash_eraseall" tool. (Perhaps use it with the "-N" option?)

lookit recent versions of the "flash_erase.c" code (excerpted from above Git link):


(I don't have that version of busybox - I see references made to it in a few posts here on XDA, but I don't know it's origin or where to get it)


bftb0


[ Edit ] looked around for a bit and couldn't find anything pre-built; looks like you might have to build mtd-utils using the NDK for Android. Time for bed for me; here's the link to the mtd-utils project.

SoSicWiTiT said:

i found out that my friend installed rom manager n clockwork recovery and did a flash that failed then ran the 2.1 ruu thinking it would fix it. and that's how the phone got to the state i started with.

i actually got a rom to flash (kinda) with some info from that link i posted. i patched my recovery with files from that link which gave it a custom mtd (table) , i shrunk cache and used the extra space to make up for the bad blocks in system and bind mounted cache to and ext partition on my sd card... and all would be great BUT i realized that the boot partition is corrupt too.. ( which makes sense, since clockwork is known to corrupt both)

so my solution was to flash boot.img to recovery and just boot normally with volup+powerand use amon ra by "fastboot boot " if i need to.

but i cant flash the zip file that patches the kernel to boot using the custom mtd because it's script copies,unpacks,patches then repacks boot.img from /boot but my boot.img is on recovery so im either going to have to edit the .sh in the zip or have someone do the whole custom mtd thing and use the same mtdpartmap.txt and have them nandbackup then give me the boot.img from the backup folder so i can flash it to recovery.

OR have someone manually patch my boot.img file... but i highly doubt i'm going to be able to figure that out or find anyone todo it.

and i'll post the system section of that command in a second.

Click to expand...

Click to collapse

I was going to say, holy crap that's a lot of work - but then I've been struggling for a couple hours trying to build mtd-utils (or at least "flash_erase"). I've got all the Makefiles happy (by dropping non-essential parts of the build that require "libuuid"), but now I'm struggling with the linker/toolchain issues to try to avoid the hassles of dynamic link libraries for Amon_RA.

I still think that whatever it is that Clockwork does to get all those flash pages marked as if they are bad is a software error or some sort - so that if you can get

flash_eraseall -N

to do its thing on mtd3, you will recover all those "bad" pages in the system partition. (It is hard to believe that massive physical damage to eeprom would only show up in one or two logical partitions).

Cheers.


bftb0

FWIW,

SoSicWiTiT said:

OR have someone manually patch my boot.img file... but i highly doubt i'm going to be able to figure that out or find anyone todo it.

Click to expand...

Click to collapse

Have a look at this android-dls.com tutorial if you haven't already seen it. Use "split_bootimg.pl" to split apart the boot image into the kernel and compressed ramdisk, and then the ramdisk is just a gzipp'ed "cpio" archive.

The hardest bit about this is finding a verstion of "mkbootimg" - there are some floating around on XDA, or you can build it from the github sources.

It's not too bad, the only secret sauce is the load address for the Eris, which is 0x11200000

This is an excerpt from a shell script I use for repacking boot images - it's the essential part (everything else in the script is just glue).