[HD2 Android NAND Development] Unconn:
Honestly I do not know if this is good or bad news. I have moved the bad blocks into my /system partition and both CWM and TAR backup and restore fine. My first bad block was 110mb (880 blocks) into the system partition. I was using Typhoon CM7 which is a 150mb ROM. I also pulled and extracted the TAR and CWM backups. The CWM backup was taken while using 'bad blocks'. I did a diff on both directory structures and there was nothing that could not be accounted for.

Through all of this I have not had a random reboot in days. This may have more to do with me formatting my SD card than anything else.

I do believe that /data and /system may handle bad blocks better than other partitions. I think that having a bad block in the first ~68mb (537 blocks) may well brick your phone. Having bad block in /recovery may stop recovery from loading, and last having a bad block at the start of /boot may render your phone unbootable.

Now, I can move my bad block in to recovery and into boot by repartitioning to test these theories. This may become a work around for people that do have bad blocks in recovery or boot, partitioning them out.

<5>[ 1.918701] Creating 7 MTD partitions on "msm_nand":
<5>[ 1.918731] 0x000004320000-0x000004420000 : "misc"
<5>[ 1.920379] 0x000004420000-0x000004920000 : "recovery"
<5>[ 1.926116] 0x000004920000-0x000004e20000 : "boot"
<5>[ 1.931884] 0x000004e20000-0x00001c520000 : "sboot"
<5>[ 2.326782] 0x00001c520000-0x000026520000 : "system"
<4>[ 2.341461] ###BAD BLOCK 3735 1D2E0000###
<4>[ 2.458923] ###BAD BLOCK 4627 24260000###
<4>[ 2.472259] ###BAD BLOCK 4728 24F00000###
<5>[ 2.495880] 0x000026520000-0x000026f20000 : "cache"
<5>[ 2.506958] 0x000026f20000-0x00003e720000 : "userdata"
<4>[ 2.879241] ###BAD BLOCK 7822 3D1C0000###

A few things to note:

- in some view of the partitions they ignore the bootloader section of NAND. Here the phone does not. Misc starts at Hex 432 (block 537)

- You will not in Hex that 432 does not equal 537. The blocks hold twice as much information than just the data. Find the decimal value of the hex and devide by 2.

- If you do the math you will see that my sboot partition is 375mb. This is how I moved the bad blocks from /userdata to /system. I will resize misc to try and move my bad block into recovery, but this may leave me no space for /userdata.

- You will see that my first bad block is 3735 or address hex 1D2E. Again, if you do the math you will see that this block is 110mb into my system partition.

- /system and /userdata use yaffs. I really do not think that /recovery and /boot do. Therefore they may not handle bad blocks as well as yaffs partitions. I am guessing on this one.

- example math: misc is hex 432 - hex 442 that is blocks 1074/2 through 1090/2 or 537 to 545. 545-537=8 blocks. 1 block is 128kb. So 8*128= 1024kb. 1024kb is 1mb. So that is right. I have a 1mb /misc partition. (Thanks to greg17477 for catching my mistake)

So, I am not saying that people are not having problems with bad blocks in the /system or /userdata partitions. I am just saying I can't get mine to fail. I have had CWM backup corruptions before. I was not able to restore my data.img until I changed the size of data. I have not worked out where my bad block were at that time.

Next test, trying to get my bad block into /recovery or /boot.

Edit: UPDATE: I put my bad block in about the first megabyte of /recovery (actually first block in recovery is 3729 and my first bad block is 3735). I am able to flash recovery, but I am NOT able to boot into it. Next /boot

Edit2: Moved the bad block to boot, flashed recovery again and still cannot boot to recovery. Maybe it has more to do with the size of /misc. I can boot to recovery if I take misc back down to 1mb. (I have tried this in a post below).