yashsingh1/xdaforums huggingface dataset:
[HD2 Android NAND Development] bojanbl:
I have one TMOUS HD2 with 10-20 bad blocks, but I have only problem with AngelDeath roms. I installed Pyramid, BOYPPC and Sense of eclipse ROMs, all of them were large Sense 3.0 ROMs, over ~300MB and I think I had no problem with them. With AngelDeath Kingdom ROM i cannot install anything in any way (market, apk, titaniumbackup, etc)... Hm, I just got idea to try copying apk file in android apps folder and see will it work :)
[HD2 Android NAND Development] psyCORe:
big thanks for reveal this issues, this thread deserve a stickies! :cool:
[HD2 Android NAND Development] chvvkumar:
Does anyone know how this effects WP7 installs?
[HD2 Android NAND Development] roloracer:
so since I was going to flash a different rom today I figured I would give this a try and see what my results from testing all the roms I have was inside my nand, and to my amazement and disappointment it seems my nand is pretty messed up even though I hardly have any issues with any rom besides sense 3.0 roms.

Here's the section of the recovery.log that states the amount of bad blocks in my nand. :(

bootmode=unknown

ro.baseband=unknown

ro.carrier=unknown

ro.bootloader=unknown

ro.hardware=htcleo

ro.revision=0

init.svc.choice_fn=stopped

init.svc.offmode_charging=running

init.svc.detect_key=running

init.svc.adbd=running

init.svc.recovery=running

I:Checking for extendedcommand...

I:Skipping execution of extendedcommand, file not found...

mtd: successfully wrote block at 0

I:Set boot command ""

mtd: successfully wrote block at 0

I:Set boot command ""

Formatting /boot...

Done.

Formatting /data...

mtd: not erasing bad block at 0x0bfe0000

mtd: not erasing bad block at 0x12fc0000

mtd: not erasing bad block at 0x1aa60000

mtd: not erasing bad block at 0x1c800000

mtd: not erasing bad block at 0x1f960000

mtd: not erasing bad block at 0x21940000

mtd: not erasing bad block at 0x285e0000

mtd: not erasing bad block at 0x29040000

mtd: not erasing bad block at 0x2b760000

Done.

Formatting /system...

mtd: not erasing bad block at 0x01840000

mtd: not erasing bad block at 0x05320000

mtd: not erasing bad block at 0x07260000

mtd: not erasing bad block at 0x089c0000

Done.

Formatting /cache...

Done.

Formatting /sd-ext...

I:Formatting unknown device.

rm: can't remove '.' or '..'

rm: can't remove '.' or '..'

Done.

mtd: successfully wrote block at 0

I:Set boot command ""

rm: can't remove '/data/dalvik-cache': No such file or directory

rm: can't remove '/cache/dalvik-cache': No such file or directory

rm: can't remove '/sd-ext/dalvik-cache': No such file or directory

Dalvik Cache wiped.

mtd: successfully wrote block at 0

I:Set boot command ""

-- Installing: /sdcard/HD2_NDT_MIUI_GINGER_DEVELOPMENT_V21.1_MAGLDR.zip

mtd: successfully wrote block at 0

I:Set boot command "boot-recovery"

Finding update package...

I:Update location: /sdcard/HD2_NDT_MIUI_GINGER_DEVELOPMENT_V21.1_MAGLDR.zip

Opening update package...

Installing update...

mtd: not erasing bad block at 0x01840000

mtd: not erasing bad block at 0x05320000

mtd: not erasing bad block at 0x07260000

mtd: not erasing bad block at 0x089c0000

not sure if anyone will figure out how to fix this and hopefully someone will.

Not sure how this will affect the rest of my hd2's life but what the hell!!!!

I will keep flashing this M.F'ER until it dies or blows up!!!:cool:
[HD2 Android NAND Development] Clom801:
Hello from bad block city!!
[HD2 Android NAND Development] chvvkumar:
Ok, something weird happened.

I was on Typhoon before when it was restarting every 30 minutes. I did a task29 and went back to WM6.5, couldn't stand it after 4 hrs, flashed WPH7, as usual it was very slow for me, flashed NexusHD2 and now it is working like new *knock on wood* :D
[HD2 Android NAND Development] s_superman:
just tested my phone

flashed a 400 mb rafdroid rom

and checked the recovery.log file

and used "ctrl+f" to search for bad word and thankfully none was found

:)

but I'm gonna lay off flashing new roms for a while

hyperdroid is very good and stable for now :)
[HD2 Android NAND Development] speedyracer5:
I was looking through some of the config files in the recovery 3.0.2.5 folder and found an interesting flag 'ro'. The description is as below....

flags:

"ro" - disable add extra 5% to partition size and count bad blocks into size

Does this take into account the bad blocks and size the partition accordingly?
[HD2 Android NAND Development] rafpigna:
Just my two cents:

I had bad-blocks from the "MAGLDR" appearence.

Developing kernels and roms I flashed and re-flashed stuff THOUSANDS of times.

I remember that when I tried to port the first sense GB rom I flashed it 163 times ( I recorded it)

During my tests and flashes, I use a special kernel that has the kernel debug console active and an intird without any logo or splash scree, so I can see all the boot process, including the check on the partitions that shows the bad blocks.

But I have to be honest, I never had the issues that were reported int he OP like hot reboots and so on...

And, just to say, I always work with a 340mb rom on 400mb partition...

I'm lucky?
[HD2 Android NAND Development] calvinfoo:
**** Got 1 bad block...

Any solution to this?

Its say not erasing bad block, so it doesnt even try erasing to repair?

EDIT: Found this http://xdaforums.com/showthread.php?t=1085374 Could this work?
[HD2 Android NAND Development] Kameirus:
really did you even bother to read any pages in this very long thread of 9 pages
[HD2 Android NAND Development] TheInVisibleGoD:
OMG LOL

Relaxe dude, just one is not the end of the world...

Just to make you fell better, I have around 8, and I still have a very stable device!
[HD2 Android NAND Development] lukedunk:
Bump... anyone know anything about this?
[HD2 Android NAND Development] TeeHD2:
If I had 9 bad blocks, Can I still able to run roms very stable?

Formatting /system...

mtd: not erasing bad block at 0x05740000

mtd: not erasing bad block at 0x05780000

mtd: not erasing bad block at 0x06600000

mtd: not erasing bad block at 0x067c0000

mtd: not erasing bad block at 0x06800000

mtd: not erasing bad block at 0x06e40000

mtd: not erasing bad block at 0x07340000

mtd: not erasing bad block at 0x07f00000

mtd: not erasing bad block at 0x07f40000

Done.

mtd: successfully wrote block at 0

^ That's mine said.
[HD2 Android NAND Development] bojanbl:
I have more than nine bad blocks, but have only problems with AngelDeath Kingdom ROM, all other (sense 3.0, ~400MB) that I tried are working with no problem...
[HD2 Android NAND Development] jcsy:
This is my big ASS story from 8 months ago

Day 1 of my HD2, I have already removed the RADIO and STOCK ROM and placed a custom WM6.5 on it and ran it without problems

My initial days of Android was booting via Haret from SD card, off SUPERRAM series made by Darkstone.

I then tried a GB2.3.3 releaseand noticed my device had random reboots and all sorts of random hangs during gaming, charging, after reboot, wifi and a bunch more

i troubleshooted and replicated the problem as much as I could and narrowed down but was not convinced. During this period, I tested MAGLDR and WM7 and WM6.5

Now I am back on WM6.5 without any NAND or SD android loading, and im suffering from the SAME EXACT PROBLEMS as the OP, and a few more. I wondered WTF was wrong with my device. I have another HD2, and loaded the exact configurations and it worked FLAWLESSLY. It didnt even hang once. I was convinced that it is a hardware issue within the HD2 and didnt have any idea what it was

This post confirms that now, i might have bad blocks.... I will definitely need MAGLDR and do a complete format (but a little tentative towards that ) to find out whether my device has bad blocks.

so if my device has bad blocks, does the task2a partitions them off ?
[HD2 Android NAND Development] Rick_1995:
Hey guys,

Some good news.

It seems cLK successfully passes the list of bad blocks on NAND and now we just have to see what the native android device kernels do for such bad blocks. So now we need not flash/erase our NANDs to see the badblocks, although the only downside is that you can see the bad blocks which affect android, but we cannot see bad blocks in RADIO, SPL, SPLASH or other Winmo partitions( That won't matter much as if your device does have bad blocks in SPL or radio, chances are it will never boot :p ).

[ 1.303375] #MTD# parts in atag = 6

[ 1.303405] Creating 6 MTD partitions on "msm_nand":

[ 1.303436] 0x000004320000-0x000004420000 : "misc"

[ 1.305023] 0x000004420000-0x000004920000 : "recovery"

[ 1.310516] 0x000004920000-0x000004e20000 : "boot"

[ 1.315979] 0x000004e20000-0x00000c220000 : "system"

[ 1.432678] 0x00000c220000-0x00000c720000 : "cache"

[ 1.438110] 0x00000c720000-0x00001e820000 : "userdata"

[ 1.462249] ###BAD BLOCK 1785 0DF20000###

[ 1.479858] ###BAD BLOCK 1926 0F0C0000###

[ 1.538574] ###BAD BLOCK 2395 12B60000###
[HD2 Android NAND Development] Unconn:
I addition to what Rick_1995 said above me...

A little history:

I have had some issues with my HD2. I have had random reboots, but honestly do not know if these are bad blocks (I think they are new gps and ril hacks...) and I also had issues with backing up and restoring my system partition. So this motivated me to start looking for bad blocks (along with new cLKs and other threads).

So on new cLK 1.6DE I ran fastboot oem format-all and noted my out put.

http://xdaforums.com/showpost.php?p=16375858&postcount=272

I then used the new features and resized my system partition from 150 to 250. This changed the starting block for my data partition and my /data partition restore problems went away. This is interesting but I have not reached the useful part....

The Issue?:

So, I have been reading through this thread (twice) and other pages trying to learn what I could about yaffs, and leveraging knowledge about Android troubleshooting I had a look at what is happening in the system startup running cat last_kmesg >/sdcard/last_kmesg.txt This file tell us what I already knew:

<4>[ 3.175903] ###BAD BLOCK 3735 1D2E0000###
<4>[ 3.293609] ###BAD BLOCK 4627 24260000###
<4>[ 3.306976] ###BAD BLOCK 4728 24F00000###
<4>[ 3.713531] ###BAD BLOCK 7822 3D1C0000###

Then later on the bootloader/kernel (?) passes the bad blocks to yaffs. Remember this is during the boot up of the normal Android OS.

<4>[ 6.092468] ###BAD BLOCK 3735 1D2E0000###
<7>[ 6.092498] yaffs: block 991 is bad
<4>[ 6.458770] ###BAD BLOCK 4627 24260000###
<7>[ 6.458801] yaffs: block 1883 is bad
<4>[ 6.500000] ###BAD BLOCK 4728 24F00000###
<7>[ 6.500030] yaffs: block 1984 is bad
<4>[ 7.763702] ###BAD BLOCK 7822 3D1C0000###
<7>[ 7.763732] yaffs: block 5078 is bad

Now I thought, I wonder if recovery is having these blocks passed to it? So while in recovery I mounted all of the partitions, then ran adb with cat last_kmesg >/sdcard/last_kmesg-recovery.txt. The boot up of the bootloader/kernel (?) sees them:

<4>[ 2.713256] ###BAD BLOCK 3735 1D2E0000###
<4>[ 2.830444] ###BAD BLOCK 4627 24260000###
<4>[ 2.844055] ###BAD BLOCK 4728 24F00000###
<4>[ 3.249847] ###BAD BLOCK 7822 3D1C0000###

But this information is never passed to yaffs while in recovery. CWM Recovery (I am using 4.0.0.0) is going to try to write data to these blocks instead of avoiding them becuase yaffs does not know about them (edit: mark them?). This is actually why you CAN see the back blocks in the recovery.log. If yaffs knew about the bad blocks while in recovery then recovery would never report them because it would not even try to write to them.

Please give me feed back. I am no expert and may have missed something.

Edit: This may not address new bad blocks that fail after flashing a bootloader. (Now edit your post)

Edit 2: As stated below information being passed from the bootloader the yaffs may not be accurate, but I am leaving this information as is for brain fodder.
[HD2 Android NAND Development] Rick_1995:
First of all sir, yaffs is not a program/method/routine to which bad blocks/address can be passed to. yaffs is the Filesystem much like FAT32 and NTFS to Windows, HFS and HFS+ to mac and ext(x) to linux.

yaffs stands for "Yet Another Flash Filesystem" it is the yaffs2 driver which chooses to echo or say silent about the bad blocks in the log, however i'm pretty sure that it is aware of them as the atags passed are still the same.

From what i can interpret, we just need some logic in kernel yaffs driver to skip the bad blocks and/or remap them (Although this should have been happening by default as yaffs filesystems are made for NAND flash storage and were made with wear leveling logic).

Also, i was wrong a few posts ago, each block is 128kb and not 512.

EDIT: just for your information, MAGLDR is way better than cLK for now. Please revise your statement with facts. Most of the code used to "port" lk to HD2 was borrowed from Cotulla.
[HD2 Android NAND Development] Cheech1976:
I have been flashing quite a lot of roms these days, trying to find a build that would work for me and give me all i need, want :D

Since reading this thread, i created the log file each time i flashed or restored something, to check if the bad blocks were increasing.

Right now i have one bad block, sorry, don´t have my phone with me right now, i will check later and post the address of the bad block if it´s interesting to someone.

What i found out however, that the adress of the bad blocks changes depending on which version of CWM you are using.

My bad block :D is in the system partition, the adress between CWM 3.0.2.5 and CWM 4.1.0.4 is a different one.

With CWM 4.1.0.4 my phone wouldn´t boot either dungphp´s nor langthangs pyramid builds, the phone would restart approximately 5 seconds after it began to boot.

With CWM 3.0.2.5, where the address of the bad block is a different one, both builds boot up just fine and show no weird bugs that may originate from the bad block.

So maybe changing the CWM version could improve the stability of the flashed builds for one or the other?
[HD2 Android NAND Development] jcsy:
crap, the only way to find bad blocks are thru MAGLDR? or did i miss something?
[HD2 Android NAND Development] AngelDeath:
Also as someone pointed out that certain roms worked with a different CWR, remember that based on what I am seeing is I used a 400-445mb system partition when this started happening to me, when I switched to a eu version the system partition got smaller obviously, and the affected location I am presuming is now in the data partition, which in the eu version doesnt change since I have sd-ext to enabled and app2sd nothing gets written to the partition which obviously stops the problems.

@Raf, the possibility you not running into this issue (Assuming at the moment) is because you are a eu user, which at that point would clearly as I said before would not affect you since it doesnt affect me now either using my eu rom.

Also I dont know if this would have an affect, my presumption is it would, is that some of us do battery pulls when our phones lock up. I would think this wouldnt be good for the phone especially if its writing to the phone at the time of doing it, since a normal HD is not immune to abrupt shutdowns, I would not think that a flash memory would be any different.
[HD2 Android NAND Development] Unconn:
I do agree that using less of NAND with smaller ROMs, Smaller partitions, and moving as much data to SD or sd-ext will help alleviate the symptoms if the bad blocks are at a high enough address, but it is also just masking the problem. The bad blocks are still there, and I assume that eventually you or someone else will have a bad block low enough to affect the first few partitions. I like your idea, and actually got around some of my own bad block problems by expanding my /system partition so my bad block did not reside in the first few blocks of my /data partition.

I assume that when you call me sir you are being respectful and appreciative of my efforts.

I think we actually agree that Recovery has the ability to write to blocks that is should not.

I believe we are not the only ones to go through this:

http://xdaforums.com/showpost.php?p=6886783&postcount=1

I really think this is worth a read. They worked around the problem by (simplified):

- Flashing

- tarballing off the partition that has bad blocks (most bad blocks will not hold their data after reboot?)

- rebooting (allowing blocks to be marked bad again)

- tarballing the partition back on. Tar will not write to bad blocks as it works with the file system and not directly as Recovery seems to.

He says things like:
[HD2 Android NAND Development] AngelDeath:
Unconn,

I agree with you that my solution is just a workaround and the key is either to fix the block, or to mark them bad so that they are not attempted to be written to. I think that would be the key in making us have less issues, but as I also said before, based on some of my reads, you also have to take into consideration that it is considered an aging process, by that I mean that even if the blocks are marked bad, each block reduces the size of the partition and as well the size of the rom that can be used. And your right, as I stated I think in the first post that it will come to a point that the bad blocks will become more apparent and significant that TMOUS users moving to a EU version rom or one that utilitizes the sdcard with sd-ext or app2sd, will no longer be able to use that, as I also stated that EU users would wind up basically possibly at the point of using a SDversion of android since they're flash memory is smaller.

So the only real solution which I think is not possible would be to fix the bad blocks, and based on what has been written about it, that is not an option we can do, so marking them as bad and having the system bypass or not used them stops the various issues, but will not stop that eventually we will come to the same crossroad.
[HD2 Android NAND Development] Unconn:
Very true. NAND (or any storage really) has a finite life. With flashes and apps caching info to /data the memory will only last so long. I do believe that if we could get Recovery to pay attention to the yaffs bad blocks table then we could extend the life of our phones a very long time. I have 4 bad blocks out of nearly 8000. Even if they double and are just ignored after being marked bad I am fine with that.
[HD2 Android NAND Development] Rocheau:
I have found this thread as one of the more interesting I have read in months. You gave us the key.

My HTC HD2 is one year and a half old, and it has been flashed many times, firstly in the windows mobile 6.5 universe and lately in the Android platform. What I have experimented in the last months is that with specifics ROMs my HTC could not run properly ( I mean with out random reboots). At first those random reboots were not frequents but recently I began to have more and more. Even I tried to install the last Rafipgna rom, the one with 400 mb but it was impossible, as the HCT reboots itself quite often. But, at that moment I could not identify where it was the problem. I put the blame on the System or on the radio or even on my SIM CARD but I could not imagine that the problem was due to the bad blocks.

Finally I could managed to install a MIUI ROM that is currently running in my HTC HD2, without problems so far, and I am very happy with it, but now, I know that I can only install these kinds of light roms, and also, that my HC HD2 is getting old very quickly, so maybe in a next future I could not ever install any rom except the ones that are installed on the SD. Reallly I do not care too much about it, before it will happen I surely will buy a new smartphone.

Thank you for your information
[HD2 Android NAND Development] Zupp34:
Does anyone know if new HD2s have no bad blocks at all? How can I check how many bad blocks mine has without having to reflash? And is there a way to avoid bad blocks?

Sorry for noob-ish question.
[HD2 Android NAND Development] Unconn:
I will answer as best I can:

1. New phones should show no bad blocks. That does not mean that the NAND did not have bad blocks that remapped before being released to the phone manufacture. This is the way they used to do it anyway. Maybe they can create solid state memory that has no errors now.

2. ADB shell (or other terminal emulator)

SU (if necessary)

cat /proc/last_kmesg > /sdcard/last_kmesg.txt

then open this file (last_kmesg.txt) from the sdcard some how. In there there may be a section containing the word "bad"

another way is to use "Report Error" in CWM after flashing (or restoring) a ROM. It will copy a Recovery.log to your SD card.

3. To minimize bad blocks do not turn on and use your phone. If you have to use your phone minimize flashing new ROMs. ;-)
[HD2 Android NAND Development] Zupp34:
/proc/last_kmesg: No such file or directory

I get that error using terminal emulator with su
[HD2 Android NAND Development] Unconn:
Oops. Try just:

dmesg

If that works then:

dmesg > /sdcard/dmesg.txt

This will give you messages since bootup.

/proc/last_kmesg is for seeing what happened just before the last kernel fault. I got them mixed up. Sorry.
[HD2 Android NAND Development] Zupp34:
Getting a similar error with dmesg.
[HD2 Android NAND Development] Unconn:
Try Connectbot from the market. Connect to localhost (not SSH) with no password.

It works for me in this and adb.

What emu you using?
[HD2 Android NAND Development] Zupp34:
I'm using Terminal Emulator from the Market.

And maybe you assumed I'm using ADB through a computer but I'm not. I tried ADB before but found it too complicated and quit :) Hopefully that's not the issue here.

EDIT: I tried connectbot and I get the same error :(
[HD2 Android NAND Development] jcsy:
i dont see a "dmesg" in /proc

but i can see "kmsg" and "last_kmsg" in /proc

probably different rom's have it stored different locations

i really want to see my bad blocks without reflashing though

i have 2 x HD2's , 1 Windows Mobile(suspected high bad blocks) and 1 NAND android, (suspect 0 bad blocks ) since they both exhibit totally different behaviours even if i swapped their roles
[HD2 Android NAND Development] Rick_1995:
Why copy the logs to sdcard ?

adb dmesg > c:\dmesg.log (Windows)

adb dmesg > ~/dmesg.log (linux/mac)
[HD2 Android NAND Development] AngelDeath:
Or the other way is to install mtty 1.42 (You have to have active sync installed and uncheck allow usb connections), and in the cmd window type "info 8" without the quotes, this will tell you your phone layout and any bad blocks, just remember that the phone MUST be in tri-color mode (Holding the volume down button as you turn it on).

Also stated in the OP as to how to find bad blocks.
[HD2 Android NAND Development] tRIACTIs:
very interessting thread! especially because i'm a flashoholic and pretty sure my flash count is 1000+

i tested a lot of ROMs and also (try to) follow the threads and i wonder why ppl have so much issues and not me.

but suddenly my phone started to have strange issues which are not ROM related (since a couple of weeks i have many hot reboots). after reading this thread it was absolutly clear in my mind that i have some bad blocks too. but no bad blocks detected so far (neither in dmesg nor in mtty or Recover.log). i will observe it further of course and looking forward to further insights of this thread...

sorry for imo OT. i think my post will be fine in discussion forum but here in the dev corner it feels like OT :o
[HD2 Android NAND Development] jcsy:
sorry was not aware that mtty 1.42 was an installable

anyways, it doesnt work on my Windows 7 (Windows Mobile Device Center) and I would need to return home to my Windows XP to get Active Sync and test bad blocks
[HD2 Android NAND Development] pyrorob:
mtty works just fine on win 7. if you load the right mobile device drivers.. look it up, it was the same issue with vista
[HD2 Android NAND Development] Zupp34:
Got the mtty method to work for me but sadly I found 12 bad blocks. Should I consider sending it in for warranty mobo replacement?
[HD2 Android NAND Development] jcsy:
struggling to get it to work under Windows 7

will just go home and try on Windows XP