yashsingh1/xdaforums huggingface dataset:
[HD2 Android NAND Development] Zupp34:
I followed instructions from this thread http://xdaforums.com/showthread.php?t=540290

Read post 1 and 2 and follow the steps for win 7.
[HD2 Android NAND Development] roloracer:
I have at least 17 bad blocks in my hd2 and It's working perfectly. But if you still got warranty and it worries you that much then send it in and get it fix.

Sent from my MIUI GingerHD2
[HD2 Android NAND Development] Zupp34:
How do I ask for them to fix this. They might ask what issues I'm having. I'm assuming it would have to be a new mobo to get rid of the bad blocks.
[HD2 Android NAND Development] jcsy:
i got Active Sync 4.5 working

This is my 1st HD2 with Windows Mobile 6.5 which I suspected having many bad blocks, but looking at it, only 1 ?

BLOCK 0 (0x0) is reversed block
BLOCK 1 (0x1) is reversed block
BLOCK 2 (0x2) is reversed block
BLOCK 3 (0x3) is reversed block
BLOCK 8 (0x8) is reversed block
BLOCK 1542 (0x606) is bad block
Partition[0], type=0x20, start=0x2, total=0x63E
Partition[1], type=0x23, start=0x640, total=0xA40
Partition[2], type=0x25, start=0x1080, total=0x1A140
Partition[3], type=0x4, start=0x1B1C0, total=0x5C9C0

CE Total Length(with sector info) = 0xD9B8E00
CE CheckSum Length(without sector info) = 0xD8E0000

This is my 2nd HD2, on Android (only flashed once MAGLDR & 2x NAND on HyperGBX & now, Hyperdroid CM7

BLOCK 0 (0x0) is reversed block
BLOCK 1 (0x1) is reversed block
BLOCK 2 (0x2) is reversed block
BLOCK 3 (0x3) is reversed block
BLOCK 8 (0x8) is reversed block
BLOCK 10 (0xA) is reversed block
BLOCK 11 (0xB) is reversed block
BLOCK 12 (0xC) is reversed block
BLOCK 13 (0xD) is reversed block
BLOCK 14 (0xE) is reversed block
BLOCK 15 (0xF) is reversed block
BLOCK 28 (0x1C) is reversed block
BLOCK 29 (0x1D) is reversed block
BLOCK 30 (0x1E) is reversed block
BLOCK 31 (0x1F) is reversed block
BLOCK 33 (0x21) is bad block
BLOCK 1693 (0x69D) is reversed block
BLOCK 2559 (0x9FF) is bad block
bad=0x212
Partition[0], type=0x23, start=0x2, total=0xFE
Partition[1], type=0x0, start=0x0, total=0x0
Partition[2], type=0x0, start=0x0, total=0x0
Partition[3], type=0x0, start=0x0, total=0x0

CE Total Length(with sector info) = 0x80800
CE CheckSum Length(without sector info) = 0x80000

2 bad blocks?

this phone doesnt reboot that often, or randomly hangs as often as the 1st HD2, which I tried WM6.5 or WM7 or Android SD/NAND, all hangs everyday a few times, and similiar symtoms as 1st post like = charging, tethering, sync, gaming, playing a video etc

what are reversed blocks?
[HD2 Android NAND Development] Zupp34:
Even with that many bad blocks mine doesn't hot reboot at all. But it does get SOD once in a while even though it's been weeks now since it had one.
[HD2 Android NAND Development] speedyracer5:
From what I said before, about the

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

In flash.cfg I have realised that some flash.cfg's contain things like the below:

misc ya 1M

recovery ya|ro 5M /Takes into account bad blocks and reduces size

boot ya|boot|ro 5M /Takes into account bad blocks and reduces size

system ya 350M

cache ya 10M

userdata ya|asize|hr allsize

And the rest of the partitions dont take into account bad blocks!?!?!?!

Maybe if you set the ro flags on the rest of the partitions we would not have bad block errors!

Lots of vital files reside on the other partitions like system etc so they should also have bad block checking!

Im probably wrong but, its worth a try...
[HD2 Android NAND Development] Unconn:
Very interesting. If it is true, I am shocked that bad blocks are not taken into account by default. Although, I could have it wrong and the setting normally does take into account bad blocks but basically moves the last block so that you have the same size when done, reducing the size of the next/last partition. That is probably it. This just gives you 250 is you ask for 250, instead of giving you 248 if there is a bad block in that range.
[HD2 Android NAND Development] AngelDeath:
Here is a couple of things again:

1) The Address of the bad block will affect how android works. Remember there are so many factors for this, for example, and by no means is this a complete list:

CWR partitions 350+ to 445mb would be more affected. smaller roms have more room to write to. (miui, cm7, vanilia GB roms, normally use less then 200mb of space)

If a rom is app2sd enabled, this would reduce writing to the phone.

ZIPALIGN, if a rom is or is not could affect how the files are flashed/written to the phone in the physical memory address and in what order, hence why some would say they dont have any problems, it COULD be something you never use hence why you dont notice it.

Size of apps. This is particularly interesting, and if my memory serves me right flash memory should work the same as a hard drive when working with clusters. (In case anyone is saying huh?)

The blocks should be like clusters on a hard drive, and normally the way from what I remember of hard drives apps or files as they are written to the hard drive are written to the clusters on the hard drive. if a app occupies part of a cluster and doesnt use the whole thing, that cluster is marked used, and even though you have space in that cluster, the next file or app must be written to the next un-occupied cluster. no two apps can share a cluster from what I remember, this would cause sharing violations in the hard drive and also corruption of data. This normally could be seen when formatting a hard drive you are asked if you want the default cluster or specify a cluster size. In Flash memory this question isnt asked, and personally I dont know if such a thing exists in yaffs, or a linux FS, I would suspect it would.

Again, there is so many factors it would be very hard to pinpoint, one of the reason why some roms will work, or somethings will work and on other roms it wont, its based on how the files and what order they are being flashed/loaded into the phone.

Also from what I understand the ro.xxx stands for Read Only, so if that is the case, then I would think that by adding that command to the flash.cfg, you would basically deny anything being written to the Recovery and Boot partition, that would be one of the reason why it wouldnt be applied to the System or Data partition. If i'm wrong, someone please correct me.
[HD2 Android NAND Development] chuck507:
From what I've read the file system being used is YAFFS (Yet Another Flash File System) and according to their website Nand memory ships with bad blocks and as it ages it develops more bad blocks so the YAFFS is designed to handle the bad blocks

From the YAFFS website ....
[HD2 Android NAND Development] antaed:
samsung vs hynix

i think it would be interesting to see if the bad sector issue occurs more often on devices having samsung nand chipsets...

see here:

http://xdaforums.com/showpost.php?p=10679711&postcount=2
[HD2 Android NAND Development] speedyracer5:
But in this file

http://cotulla.pp.ru/leo/Android/flash.cfg.txt

It clearly states that 5% of the space is taken off the partition size as it accounts for bad blocks. So you would have a reduced partition size but it should be clear of bad blocks... I doubt you would ever have more than 5% of the size of the partition worth of bad blocks....
[HD2 Android NAND Development] ephumuris:
I was all ready to buy a HD2 and this has kind of put me off buying one. I would be getting it second hand but what if i get one with lots of bad blacks...would i run the chance of having lots of weird erros when i install android?
[HD2 Android NAND Development] speedyracer5:
I got a used HD2 a few days ago and mine is fine, try to get one that isnt on android and is stock windows mobile as its probably had less flashing :p
[HD2 Android NAND Development] ephumuris:
Yeah that was my initial idea! Just need to get my head around all the magldr stuff and that. Is there an idiots guide...bullet point sort of thing? I'm no noob to Android but totally new to the HD2 world. Don't even have one yet just need to educate myself.
[HD2 Android NAND Development] clio94:
i have t-mobile hd2 with samsung nand chip and 10 bad blocks in /data and 2 in /system but for at least for now no problems even with sense roms.

Maybe bad blocks are only in samsung nand chips? And this is a serious reason not to sell hd2 for galaxy s2; :p
[HD2 Android NAND Development] clyder:
Can someone give me few hints on how to use mtty.

I downloaded mtty 1.42.exe, and in mgldr menu I entered tty option, but mtty have only com1 and com2 option, no USB. I read somewhere that I need to disable USB connection in active sync. After I did that phone just hangs in magldr/tty screen when I plug the USB cable and I need to remove the battery.

edit: Now it hangs even if I dont plug the USB cable. First time when I plugged the cable I had a line saying something like tty init. Now as soon as I enter the tty option phone is frozen.
[HD2 Android NAND Development] codiak:
My SPL shows: PB81100 SS-BC

I assume its Samsung, but not sure.

Dont have any Problems with it.
[HD2 Android NAND Development] jcsy:
does the task 2a clear the bad blocks?
[HD2 Android NAND Development] Unconn:
No. But it may reset them until they are found again by the first disk operation that runs into them. Not sure, but I know it does not fix them.
[HD2 Android NAND Development] Zupp34:
Do you know steps one can take to avoid bad blocks or minimize them? I might get a new mobo on my HD2 soon.
[HD2 Android NAND Development] Unconn:
I have 4 bad blocks right in the middle of my data partition. As far as I can tell Yaffs is handling these just fine.

I previously thought that my reboots were caused by the bad blocks, but I doubt this now. I think it is new additions to recent ROMs. I need to test this by flashing an older version of the same ROM and see.

I used to think that my problem with not being able to backup the data partition of my phone completely was bad blocks. But I am not convinced as I can backup and restore my data partition just fine with Tar. The problem was that I could do what seemed like a full backup with CWM. Then when I would restore only about half of my folders were there. I pulled the data.img out and tried to unyaffs.exe the file and it would cause a fault in unyaffs.exe part way through and the extracted files were only about half what I expected. I assumed this was because it was backing up a corrupted block. I assumed this because it even happened after I did a clean flash of a ROM and restored my settings using Titanium backup. I never ruled out my SD card. This may have more to do with my SD card needing to be formatted. This needs further testing.

The point of all this is that yaffs should handle bad blocks just fine. I know many HD2 users who have had many bad blocks for a long time and have had no issue at all. This may or may not be a real issue affecting other users, but I can see no clear and definitive fact that it is causing issues.

If there is an issue, it would be with CWM (recovery) writing directly to the storage and bypassing the yaffs records of bad blocks. I highly doubt this too as CWm reports the bad blocks it cannot format, so it would be wrong for it then to expect to write data to this location.

Futher:

- If I run an older ROM for a while and get no rebooting, then I know the rebooting is the ROM and not mishandling of bad blocks.

- If I format my SD card and backup and restore the ROM that got corrupted before the format then my CWM problems are my SD card. Not the mishandling of bad blocks.

Does anybody know for sure that they are having problems because Android/CWM/cLK/MAGLDR/grandma is writing to bad blocks? How was this verified?
[HD2 Android NAND Development] Zupp34:
Sounds to me like you are saying that bad blocks aren't a problem as long as YAFFS handles them correctly. But is the NAND memory diminished slightly if there is a considerable amount of them?
[HD2 Android NAND Development] Unconn:
I would say that there is nothing to worry about. Yes yaffs should be handling them correctly. Now if they go bad after you flash, you could get a corrupted file, but the bad blocks we have already should be no problem, but again, this is just my opinion and have not had it proved either way.

The space in NAND memory is diminished in size as blocks go bad. One of the worst I have heard of was like 18 bad blocks. That is 0.225% of the space take by bad blocks. So space is not a worry.

Now, solid state memory only has a finite life span. Writes, re-writes, formats and flashes all shorten the life of the NAND memory. Even if you flashed android just once and used that forever the data partition had data that constantly changes and eventually (years and years?) blocks would go bad quicker and quicker as it reached the end of it's life. So unless people are getting new bad blocks every month they probably do not have to worry.

All that said, if you have a warranty that covers your phone you could always try and get a new one.
[HD2 Android NAND Development] Serious_Beans:
I am not too sure what I understand from my log, it says not erasing bad block something something, can someone download my log and let me know what exactly is the problem and if there is a way to fix it?

Okay I can't upload it but here are the places it says bad blocks

"-- Wiping data...

Formatting /data...

mtd: not erasing bad block at 0x02140000

mtd: not erasing bad block at 0x0b120000

mtd: not erasing bad block at 0x0dec0000

mtd: not erasing bad block at 0x15e40000

mtd: not erasing bad block at 0x1c1c0000

mtd: not erasing bad block at 0x1ca80000

mtd: not erasing bad block at 0x1f460000

mtd: not erasing bad block at 0x23060000

mtd: not erasing bad block at 0x26d00000"

"Formatting /system...

mtd: not erasing bad block at 0x05320000"

"-- Installing: /sdcard/HD2/TyphooN_CM7_v3.5.7-MAGLDR.zip

mtd: successfully wrote block at 0

I:Set boot command "boot-recovery"

Finding update package...

I:Update location: /sdcard/HD2/TyphooN_CM7_v3.5.7-MAGLDR.zip

Opening update package...

Installing update...

Welcome to TyphooN CyanogenMod7 MAGLDR!

Formatting Boot...

Formatting System...

mtd: not erasing bad block at 0x05320000"
[HD2 Android NAND Development] roloracer:
So I did another flash since I had the need for flashing and found something that had me confused. I figured since I had 17 bad blocks that it was gonna be the same in other roms but I guess all roms install differently thru out the nand here's the last two flash recovery logs :

NDT MIUI DEV ROM

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

Typhoon CM7

-- Installing: /sdcard/TyphooN_CM7_v3.5.7-MAGLDR.zip

mtd: successfully wrote block at 0

I:Set boot command "boot-recovery"

Finding update package...

I:Update location: /sdcard/TyphooN_CM7_v3.5.7-MAGLDR.zip

Opening update package...

Installing update...

Welcome to TyphooN CyanogenMod7 MAGLDR!

Formatting Boot...

mtd: not erasing bad block at 0x01840000

Formatting System...

mtd: not erasing bad block at 0x05320000

mtd: not erasing bad block at 0x07260000

mtd: not erasing bad block at 0x089c0000

Copying files to system...

minzip: Extracted file "/system/app/ADWLauncher.apk"

Install from sdcard complete.

mtd: successfully wrote block at 0

I:Set boot command ""

Only 4 bad blocks in the CM7 rom so it makes me wonder if I were to use a rom large enough to use the nand space to the max, how many bad block would I encounter?:confused:
[HD2 Android NAND Development] AngelDeath:
I looked at this file, but unless its 2:30am and I've had a long day using the ro feature reduces the partition by 5% but it doesnt account the bad blocks, based on my looking at this file and reading it not using the the "ro" in the line adds 5% to account to include the bad blocks, cause if the ro omitts the bad blocks, or doesnt add them to the boot, then they have to end up somewhere else. of if the 5% is used due to the bad blocks to account for then it SHOULD write it to the added space.
[HD2 Android NAND Development] AngelDeath:
You need to be in TRI-COLOR BOOTLOADER Mode, not magdlr mode.
[HD2 Android NAND Development] AngelDeath:
Unless I mis-read something I apologize in advance, but your thought process is wrong, and here is the reason why as my example, before I came out with my 1.5 rom I was using my 1.42 rom, and it was working perfect, everything was fine, then I started testing my 1.5 rom, which all were fixes and if anything was smaller by a few mbs then my 1.42 rom, after flashing it I ran into a slew of problems that were unexplainable. For days I was banging my head trying to figure out why, even an XDA member couldnt understand or make sense of it, so then I needed a phone, and reverted back to my 1.42 rom and all of a sudden the same problems were occuring, I thought this is impossible nothing was ever wrong with this rom to cause these, it never did it before, thats when Kam suggested looking to see if I had bad blocks, I thought no way, sure enough I did, so when I changed to my Eu 1.5 rom, (exactly the same as my tmous 1.5, except sd-ext enabled and app2sd enabled) flashed it and nothing, no problems.

Understand that I will say again, depending on the address location of the bad block could be the problem, because explain why two roms exactly identical except for what I mentioned, only the eu rom works on my phone and not the tmous version.

Also you theory of using a older rom and not having the same problems are partly wrong, because depending on the location of the bad block you old rom could end up with the same issue, also if you have a newer rom understand most of the time that rom will be bigger (doesnt have to be significantly bigger, even slightly) and could cause the problem, and also the way the files are flashed/laid out to the phone.

Like I said I have two HD2, my daily phone has bad blocks and I cant flash my tmous version at all, my 2nd hd2 has 0 bad blocks and I can flash the tmous without issue.

I agree that blocks do go bad as you use it, which could be another way you can have them, but having a finite amount of writes or battery pulls, or low voltage, or anything else, contribute to this.
[HD2 Android NAND Development] AngelDeath:
Not to quote anyone but let me mention this again, I would PRESUME CM7, MIUI, and Vanalia GB roms would not encounter this problem because of the small partition layout needed for these roms.

This to me would be affected for roms that used nearly all the 445mb of system partition space, because at that point you have no room to write to, either the flash would fail, or you would have errors.

Think about this, each block is 128k based on the magdlr readme, but if you add up the fact that your max partition is 445 and cant be anymore you are limited, lets for the moment forget the data partition cause thats near 500mb, but if your bad block is in the system partition you are limited as you have bad blocks.

Here is something else, if yaffs is suppose to handle bad blocks, then fine. But what if its not? What if as its flashing that app thats suppose to be written encounters that bad block then part of that app becomes corrupt. Or If yaffs does handle bad blocks, then in theory we shouldnt see bad blocks in the recovery.log during a flash, we should see it only in mtty or during a format.

Also if yaffs is suppose to handle bad blocks and we have a finite amount of room in our system and boot partition, then if thats space we cant write to cause yaffs is handling it, then large roms should end up with an error in the recovery.log stating no room left on device, cause even if yaffs is handling the bad blocks, it cant make up new blocks for lost blocks.

Also and lastly, What if Yaffs only handles the bad blocks AFTER the flashing of the rom and when the phone is in use and not during the flashing of the rom? Or What if the fact that the HD2 was never suppose to have Android on it and obviously these are the works of great devs but that routine for handling bad blocks is not in magdlr, or clk, or the kernel?

Cause no where during a flash, or during the running of our phones do we ever encounter anything letting us know that the blocks have been flagged or anything. One would have to at this point assume that yaffs is either flawed, or the complete routine of yaffs is not implimented and is assumed working as expected when its not.
[HD2 Android NAND Development] clyder:
Thanx,

I also found this thread with instructions.

Just tried it and only one bad block. That good I guess since I did a lot of flashing during last year of using HD2.
[HD2 Android NAND Development] Zupp34:
Whats your nand flash type? It should be the top line in tricolor boot mode; something like PB____-__
[HD2 Android NAND Development] clyder:
pb81100 ss-bc
[HD2 Android NAND Development] Zupp34:
Its samsung like mine. I wonder how you managed to only have one bad block!
[HD2 Android NAND Development] clyder:
Lucky perhaps :)
[HD2 Android NAND Development] Beastage:
Why is this thread not a sticky? I only read this now and it explains lots of the issues I been having lately tho most of the time they are under control...

I guess my flashing days are over, I do have the suspicion that heat causes the NAND to malfunction , for example I get hot reboot installing apps from market , this is fixed after I shut down device and let it cool down.

I will only when major changes happen.
[HD2 Android NAND Development] OCedHrt:
It's not about fixing the bad sectors, but marking them to not be used. WM probably doesn't suffer from this because if it's using FAT, the partition format supports marking bad sectors and not using them. I think in this case it is CWR's responsibility to find bad blocks and mark them as bad. I'm not familiar with linux partitions so can't really comment on that but there should be a way to avoid using specific sectors.
[HD2 Android NAND Development] OCedHrt:
I think the issue is that while yaffs handles them correctly, the ROM image is a raw yaffs partition so the bad blocks are NOT marked in the image. CWR is writing the image raw to the partition and not using the bad block data there (if it had formatted the yaffs partition on nand first). Rather than doing a raw yaffs write, CWR needs to do a yaffs extract/copy to NAND - such as mount the image and copy rather than a dd kind of install.