yashsingh1/xdaforums huggingface dataset:
[Droid Eris Q&A, Help & Troubleshooting] bftb0:
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

mount /system
cd /system
rm -rf /system/*

mount /data
cd /data
rm -rf /data/*

cd /

If those succeed, unmount everything

cd /
for x in /system /data /sdcard ; do
umount $x
done

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

???

bftb0
[Droid Eris Q&A, Help & Troubleshooting] 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:

fastboot erase system
fastboot erase data

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

adb shell cat /cache/recovery/log

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

bftb0
[Droid Eris Q&A, Help & Troubleshooting] 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.

> adb shell
# mount /system
# df /system
# mount /data
# df /data
# umount /system
# umount /data
# exit
>

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
[Droid Eris Q&A, Help & Troubleshooting] SoSicWiTiT:
wow seriously i appreciate all the help you've provided , you need a donate button lol.

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

but the data partition is fine with 1% used. and 162,176 usable

but i havent lost all hope yet and this is entertaining me.

custom mtd maybe..swap /data to mtdblock3 (the bad one, system) and and /system to mtdblock5 (where data currently is).. or use a memory card idk?

here's where i got the idea

http://xdaforums.com/showthread.php?t=717874
[Droid Eris Q&A, Help & Troubleshooting] bftb0:
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:

Device 1 "system"
startBlock......... 0
endBlock........... 1359
totalBytesPerChunk. 2048
nDataBytesPerChunk. 2048
chunkGroupBits..... 0
chunkGroupSize..... 1
nErasedBlocks...... 1359
nReservedBlocks.... 5
blocksInCheckpoint. 0
nTnodesCreated..... 0
nFreeTnodes........ 0
nObjectsCreated.... 200
nFreeObjects....... 96
nFreeChunks........ 86976
nPageWrites........ 0
nPageReads......... 0
nBlockErasures..... 0
nGCCopies.......... 0
garbageCollections. 0
passiveGCs......... 0
nRetriedWrites..... 0
nShortOpCaches..... 10
nRetireBlocks...... 0
eccFixed........... 0
eccUnfixed......... 0
tagsEccFixed....... 0
tagsEccUnfixed..... 0
cacheHits.......... 0
nDeletedFiles...... 0
nUnlinkedFiles..... 0
nBackgroudDeletions 0
useNANDECC......... 1
isYaffs2........... 1
inbandTags......... 0

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.
[Droid Eris Q&A, Help & Troubleshooting] bftb0:
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):

static void display_help (void)
{
printf("Usage: %s [options] MTD_DEVICE <start block> <block count>\n"
"Erase blocks of the specified MTD device.\n"
"Specify a count of 0 to erase to end of device.\n"
"\n"
" -j, --jffs2 format the device for jffs2\n"
[COLOR=green][B]	" -N, --noskipbad don't skip bad blocks\n"[/B][/COLOR]
" -u, --unlock unlock sectors before erasing\n"
" -q, --quiet display progress messages\n"
" --silent same as --quiet\n"
" --help display this help and exit\n"
" --version output version information and exit\n",
PROGRAM_NAME);
}

(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.
[Droid Eris Q&A, Help & Troubleshooting] SoSicWiTiT:
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.
[Droid Eris Q&A, Help & Troubleshooting] bftb0:
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
[Droid Eris Q&A, Help & Troubleshooting] bftb0:
FWIW,

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

mkbootimg --kernel ${_KFIL} --ramdisk new-${_RAMDGZ} --cmdline 'no_console_suspend=1 console=null' --base 0x11200000 --output new-${_BNAM}
[Droid Eris Q&A, Help & Troubleshooting] SoSicWiTiT:
i edited the shell script thats supposed to patch it to the best of my abilities (changed all boot.img txt to recovery.img) and it has mkbootimg and everything it needs in the zip, so im going to replace the script in the zip and try flashing it...

and something weird just happened.. i forgot i put boot.img for my rom on /recovery . so in shell just now, i typed reboot recovery expecting amon RA and the phone booted into the os???

even though i patched amon ra with custom mtd to install the rom ( system :300,000 - enough to skip bad blocks, cache: 30,000 ) my boot.img is mtd is set to see 176,000 right?

EDIT

i think i flashed that zip with my version of the script earlier to see what happened and i guess it worked..

C:\droid\tools>adb shell
sh-3.2# df /system
df /system
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/block/mtdblock3 307200 229296 77904 75% /system
sh-3.2# df /cache
df /cache
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/block/mtdblock4 61440 36500 24940 59% /cache
sh-3.2# df /data
df /data
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/block/mtdblock5 101888 2608 99280 3% /data
sh-3.2#
[Droid Eris Q&A, Help & Troubleshooting] SoSicWiTiT:
here's that output u wanted

Device 0 "system"
startBlock......... 0
endBlock........... 2399
totalBytesPerChunk. 2048
nDataBytesPerChunk. 2048
chunkGroupBits..... 0
chunkGroupSize..... 1
nErasedBlocks...... 572
nReservedBlocks.... 5
blocksInCheckpoint. 2
nTnodesCreated..... 4700
nFreeTnodes........ 68
nObjectsCreated.... 1000
nFreeObjects....... 15
nFreeChunks........ 39465
nPageWrites........ 109
nPageReads......... 36332
nBlockErasures..... 1
nGCCopies.......... 0
garbageCollections. 0
passiveGCs......... 0
nRetriedWrites..... 0
nShortOpCaches..... 10
nRetireBlocks...... 0
eccFixed........... 0
eccUnfixed......... 54
tagsEccFixed....... 0
tagsEccUnfixed..... 0
cacheHits.......... 0
nDeletedFiles...... 0
nUnlinkedFiles..... 0
nBackgroudDeletions 0
useNANDECC......... 1
isYaffs2........... 1
inbandTags......... 0

i think that clockwork dosent erase all the files when you format using it.. and what ever it leaves is "stuck" on the part.. and in my case the RUU marked those "stuck" non empty spaces as "bad blocks"
[Droid Eris Q&A, Help & Troubleshooting] bftb0:
SoSickWiTiT,

I built several of the mtd-utils as statically linked executables from the sources, and have attached a .zip with a few of the those executables. (I punted on some of the UBI and JFFS stuff because I couldn't find the libuuid sources in a convenient form).

You have to move them off the sdcard to someplace where there is no -noexec mount option in use and chmod 755 them; I just created a folder /dev/foo and stuck them there.

I ran "flash_info" on each of the partitions on my phone, and it produced no interesting information - it looks like that only happens if there is an "erase region" present, and for all of my partitions it produced the same result:

Device /dev/mtd/mtdN has 0 erase regions

I wouldn't ask you to run the command

flash_erase /dev/mtd/mtd3 0 0

without doing so myself, so I did that on my own phone, and it seemed to behave:

./flash_erase /dev/mtd/mtd3 0 0
Erasing 128 Kibyte @ 7b20000 -- 72 % complete flash_erase: Skipping bad block at 07b40000
Erasing 128 Kibyte @ a9e0000 -- 100 % complete

Afterwards, I restored the system partition (mtd3) via a "unyaffs" of a Nandroid "system.img" file - my phone is rebooting right now, so I assume that this caused no harm.

Note that the device file name used as a command line argument is the character-special file /dev/mtd/mtdN, not the corresponding block device. (Also note that "flash_eraseall" is just a shell script wrapper around "flash_erase")

Also, note that I did not use either the "-N" (don't skip bad blocks) or "-u" (unlock) options of flash_erase - I have more at risk than you do, and I'll let you try them out for all the rest of us - if you come to the conclusion you want to take the risks after perusing the source code But I am eager to find out what you discover if you are willing to be the guinea pig for the rest of us.

I did not test any of the other executables in the .zip which seem to have "interesting" names (e.g. "flash_unlock"), nor did I read the sources. For anyone else that is reading this, it is your responsibility to read the sources to figure out whether these are tools you should be messing with.

bftb0

"mtdflash.zip" should be 2,214,939 Bytes in size - MD5 198094fdd1ed456e5ac76bef2b5b4984
[Droid Eris Q&A, Help & Troubleshooting] SoSicWiTiT:
^ is there anyway i can try that on the boot partition first since that one isn't being used at all??

because as of right now the phone is completely working, i just have to use volup+end to turn it on...
[Droid Eris Q&A, Help & Troubleshooting] bftb0:
I don't see why not - it doesn't operate on filesystems, and so it doesn't really care which partition you are fooling with.

If you want to see if the "bad" blocks get reclaimed, then - what the heck, erase that partition and then attempt to mount it as a yaffs2 filesystem. As I mentioned previously, YAFFS is a "format-free" filesystem - that's why you can point the kernel (via a "mount" command) at a completely blank partition, and it will "mount it" as if there was a filesystem there. (Note that this doesn't mean that there is no "filesystem" meta-data added as you add files to a yaffs filesystem, it's just that it does not need to be initially "prepared" in the same way that mkext3, mkdosf, programs would prepare a "blank" disk partition.)

So, I guess if you wanted to see whether or not you actually cleared bad blocks, just mount it as if it were a yaffs2 partition (after erasing it), and run a "df" command to see if it is about the right size. When finished (after unmounting it), just erase it again.

flash_erase...

mkdir /dev/mymount

mount -o rw -t yaffs2 /dev/block/mtdN /dev/mymount

df /dev/mymount

umount /dev/mymount

flash_erase...

As I said, I spent only a little time looking at the code, and am no expert here - if you want to, take your time and read the code to see what you make of it.

bftb0

PS If you are worried about clearing the page status of flash memory pages which are legitimately bad, you can certainly "condition" those pages back out of the mix by writing "stuff" to that partition several times after the "flash_erase -N" operation - when they fail during those writes, the pages will get (again) marked as bad pages, and taken out of service. Then, finish up with an erase without the "-N" option, and flash the data that you really want (for "keepers") onto that partition. (To insure that you get all the pages, you want to flash enough stuff that you nearly fill up the partition with the dummy writes.)
[Droid Eris Q&A, Help & Troubleshooting] SoSicWiTiT:
i didnt exactly know how to use flash_eraseall ... so i used flash_erase like your example showed except on mtd2 and 0 18 instead of 0 0 and it let me flash with no errors but phone hasnt booted yet, still at 3 skate-droids

EDIT:

just flashed plaine jane , flash success.. and phone is at verizon logo (still had to use custom mtd on /system but if phone boots into os then ill flash_erase it and reflash a rom using stock mtd setup)
[Droid Eris Q&A, Help & Troubleshooting] bftb0:
Why 0 18 - you were trying to limit the number of blocks erased?

if you use flash_eraseall, it always sets those two values to "0 0" when it calls "flash_erase" internally.

The first literally means "at the zero'th page/block", and the second (the stop count) when set to zero - indicates you want to do it over the complete partition (it computes the stopping block from the known size of the partition).

( I don't know how you are keeping everything straight - it makes my head swim thinking about what you need to remember about what you did to your phone. )

Anyway - if you try with the system partition (mtd3) , the overhead of the yaffs2 filesystem mount is small enough compared to the overall size, that you should be tell right away if any pages got reclaimed via the

flash_erase -N /dev/mtd/mtd3 0 0

command

bftb0
[Droid Eris Q&A, Help & Troubleshooting] SoSicWiTiT:
=) i went back and did 0 0 instead of 0 18 and it booted.. i edited my last post to say that but i think you read it before i edited it
[Droid Eris Q&A, Help & Troubleshooting] bftb0:
Are you saying that it appears you got more space back?

Next up ... mtd3 !! :)
[Droid Eris Q&A, Help & Troubleshooting] SoSicWiTiT:
yes, just did mtd3 and ran df after. 0% used but now i have a 300mb system partition so im reflashing the original unpatched amon ra, and hopefully a rom flashes and it boots how its supposed to.
[Droid Eris Q&A, Help & Troubleshooting] bftb0:
[SIZE=+15]\oo/[/SIZE]

Props to your unbelievable tenacity at arriving at this point; this is unquestionably the best rescue I have ever seen on this board.

Woot.

bftb0

PS. I'm going to bed early tonight - 7:30 Zulu. I'll look in here tomorrow.
[Droid Eris Q&A, Help & Troubleshooting] MrObvious:
Good work! Props to helping out.
[Droid Eris Q&A, Help & Troubleshooting] SoSicWiTiT:
IT WORKED!!!!!!

Success! phone boots fine, hboots fine, recovery is fine, ruu mode is fine.

thanks to you not only did a total "noob" bring a "bricked" eris with nothing but a black screen back to life, that noob also recieved a "crash course" on everything from mtd, to fastboot, to adb & shell , to editing scripts and packing image files ,kernels (i could go on and on), and a new obsession for android.

bftb0 is officially a xda "king" (even though you were "crowned" after reading a few of your other posts in other threads which also helped me with this one) :)
[Droid Eris Q&A, Help & Troubleshooting] bftb0:
A Note about bad page recovery in eeprom Flash Memory

Hey SickWiTiT,

For completeness, I wanted to add one last comment - as much for anyone else who reads this thread as for you.

In general, recovering "bad pages" in flash memory is not a great idea - but was absolutely necessary in your case. I'll explain in a second, but my point is this: folks that follow in your footsteps should first verify that the problem they are having is indeed one of massive numbers of flash memory pages incorrectly marked as bad before they start using

flash_erase -N /dev/mtd/mtdN 0 0

in a willy-nilly fashion. They can use the "mount" and "df" trick discussed previously in this thread to detect excessive bad pages. (And they might also be able to use the yaffs2 mount option "no-checkpoint" to reduce the overhead page use cause by the mount)

Here is the reason why: "soft" errors.

Flash memory, by it's nature, is unreliable stuff: not only does it wear out, but it can also contain pages straight from the device manufacturer that can be (a) "hard failures" (every time a write occurs, the device internal verification check does not pass muster), or (b) "soft failures", where a page write might succeed or might fail ...depending on the data being written!!

What the "-N" option of "flash_erase" appears to do is to attempt to erase every page in the specified page/block range, including pages which are previously marked bad. If the erase operation succeeds, the page is no longer marked bad; and if the erase fails, it is re-marked bad.

My concern here is about pages with "soft" error behaviors that were detected previously - usually by the device manufacturer before the device even left the factory, but possibly also during subsequent flashing operations.

Some of those "soft error" or "pattern dependent error" pages (if you have them in your device) will successfully be re-introduced into the pool of "good" pages because they can be erased successfully - but it doesn't really mean they are very trustworthy. My point here is that the flash memory device manufacturer has very good testing capabilities to identify those "weak" or "soft error" pages, so erasing bad pages loses some info. If it can be avoided, "flash_erase -N" shouldn't be used. (In your case it was absolutely necessary, though). Again, folks should attempt to verify that they have a need to use the "-N" option before trying it (but it should be perfectly fine to use "flash_erase" without the "-N" option).

Not trying to scare anybody - the actual level of page defects is pretty small, and filesystems based on flash memory always detect failures that occur during writing; the only real concern is pages which will write correctly, but won't read back correctly after some period of time.

bftb0
[Droid Eris Q&A, Help & Troubleshooting] SysFailur3:
Man, I am going to marry both of you. I've learned/done things I didn't think possible, went mad, and saved a phone someone had written off. That was a lot of fun. Thanks heaps for sticking through it to the end.

Hopefully now I can put this knowledge to use in my continued rom building adventures.
[Droid Eris Q&A, Help & Troubleshooting] bftb0:
Any details you can provide about how your phone in a "near death" state came to be that way will help the rest of the community to know what things to avoid, so...

Details please! (How did it get borked in the first place, and what steps did you use to repair it?)

- Was ClockworkMod recovery involved?

- Flashing or operation the phone with very low battery?

- Other?

- Was the S-OFF bootloader on the phone before it got borked?

bftb0

[shameless plug]

There's always the "Thanks" button ;)

[/shameless plug]