yashsingh1/xdaforums huggingface dataset:
[HD2 Android NAND Development] gottley:
i just want to see if this problem i am having could be related to bad sectors that we have been tslking about just some weeks ago i was having touch screen problems with my phone the symptom were that everytime i press the back botton or the menu button or the the red shutdown button to wake up my phone i would have touch screen problems such as my lock screen i couldnt get it to open or sometimes it did open then when i would put it to sleep again it would not open again till after i put it to sleep 2-3 times after now i have heard of people losing their touch screen after a while and that is completely but mine has not completely gonna cuz the touch screen still functions but with the problems that i have stated above if try to install any ginger bread regular roms its doesnt let me touch the android to get the proscess of signing in started but if i insatll a sense gingerbread rom it works but i still get the touch screen freezes and problem it work pretty decent with the mytouch 4g rom from motoman but still small touch screen problem when waking up the phone so my solution was to take off the sleep mode completely it work bit my battery drained so just trying to see if it is bad sectors or something else :confused:
[HD2 Android NAND Development] MikeG4936:
I can definitely confirm that bad blocks can cause strange problems with ANY ROM. I didn't know what was wrong with my phone for the longest time (frequent random reboots) until finally I couldn't reinstall a recovery because of errors writing to the flash memory. Luckily, it worked just enough to flash a stock T-Mo ROM, which I used to get it sent in to HTC. I got a new phone out of the deal. :-)
[HD2 Android NAND Development] marzinho:
This is what i found in my recovery.log:

Just for the record: my HD2 is less than 1 year old, but i admit - i'm addicted to flashing.
[HD2 Android NAND Development] arkatis:
Yeah i have those bad blocks in my recovery! But my phone is still functioning like it should be! How many bad blocks should NAND have until it dies???
[HD2 Android NAND Development] ntluan:
In step 1, may i do a task29 instead of.
[HD2 Android NAND Development] orangekid:
I guess I've not had any problems because I've stuck to SD roms.
[HD2 Android NAND Development] Rick_1995:
NAND will never die until you have more than 50% blocks dead, although what will happen is if the software is incapable of marking bad sectors like android ported on leo you will experience strange bugs due to data corruption.
[HD2 Android NAND Development] arkatis:
Yeah thanks Rick. Got the point already.. :p

So there is no cure for Android users huh? Well WinMo 6.5 is cool also! :D
[HD2 Android NAND Development] theslam08:
Is that the conclusion? Our original WM wont create anymore bad blocks? Or it wont see them/use them (like it correctly should)?

Is it flashing or android causing the problem? Im assuming flashing, but you did say android was different so maybe both?

Thanks for post. Ive noticed this problem a while back, no posts on it so I couldnt get much help. But now its more known, hopefully someone can optimize magldr like you said. That would help.
[HD2 Android NAND Development] Rick_1995:
WM also will create bad blocks (if you are a flashaholic that is) but it should be able to natively handle bad blocks and mark them bad in the partition table.

Excessive flashing leads to this as you are continously erasing, flashing roms, the semiconductors in the chip go through 3~5 states for every flash. altough they are rated for million+ state change, some cannot survive and hence wear out much earlier.

magldr can not be optimised by anyone but cotulla or DFT, also it will be very hard for them too as checking for bad block, you have to flip the chip state first and doing that erases the data and if done using a buffer to let the data stay will take a LOT of time, approx 30~40 times slower, also they will have to reverse engineer the default win CE kernel/SPL to see how they deal with bad blocks and where is the list of bad blocks saved in nand.
[HD2 Android NAND Development] lukedunk:
Thanks AngelDeath. Good post and helpful info about outputting the error log. Your idea about using Data2Ext certainly should solve these problems if bad blocks are isolated to data partition. I was curious if there might be another solution through partitioning. Do you think it would be possible to manually "mark" the bad blocks by putting them in a dummy partition when formatting for recovery? For example:

misc ya 1M

recovery rrecov|ro|nospr filesize recovery-raw.img

boot yboot|ro 5M

system ya 150M

cache ya 5M

block ya XXM (Containing bad blocks)

userdata ya|asize|hr allsize

Of course this would also reduce the size of our available data partition, but might prevent any random errors. I don't know enough about the block locations to determine how large XX should be.
[HD2 Android NAND Development] arkatis:
Cool! Seems that you know a lot.. Why don't you do it yourself then? :D
[HD2 Android NAND Development] Rick_1995:
If i would be granted infinite time and infinite food and drink to accompany, i would have done everything i could. but it isn't that way, knowledge is not everything.

No sir, that shall not be possible as the bad blocks are spread throughout the NAND and not localised, partitions are meant to be linear which is not possible due to this nature of bad blocks, Although thanks for the tip, we could manually mark the bad blocks manually but we would need to know where the hell does HTC store the information of bad blocks so as to skip them on NAND or write up a hacked up kernel script to skip write to the block if it is passed as a cmdline or atag by the bootloader, which can be easily implemented but very time consuming as hacking linux kernel consumes A LOT OF TIME.

OR, what we could do as an alternative which will be very easy and very fast but will work only for the phone it was compiled for, in cLK, define the NAND addresses which have gone bad and make sure, no partition comes on those. imo it is a very dirty hack and will be fruitless if there are > 5~8 bad blocks.
[HD2 Android NAND Development] :
Bad blocks cannot be fixed. All you can do right now is mark the bad blocks until half of the nand memory goes bad and your phone dies. You can't avoid it..
[HD2 Android NAND Development] arkatis:
So.. a Temporary fix is to have WinMo OR least an Android build without flashing any other Roms? Or What? That sucks!
[HD2 Android NAND Development] mccmjoon76:
Em... interesting post my friend AngelDeath :rolleyes:
[HD2 Android NAND Development] Mafioso:
no that's a different problem, it has to do with buttons getting stuck...It has also discovered by AngelDeath...take a look here:

http://xdaforums.com/showpost.php?p=12105680&postcount=1
[HD2 Android NAND Development] :
Maybe this will help: http://xdaforums.com/showthread.php?t=707051 (on CLK though)?
[HD2 Android NAND Development] ph03n!x:
Found something interesting in my recovery log. If do a task29 and install, I see nothing - all clean. But if I format the partitions one by one, I see something like "Bad Block not formatted" (forgot the message, overwrote the log).

When I create a partition of, say, 150 MB I always get something like 147.5 MB - I was not all that bothered by it - but now I guess I know why I never get the size I create.

So, all of you out there - do a format of the partitions one by one and check the recovery log!
[HD2 Android NAND Development] arkatis:
Interesting facts....!
[HD2 Android NAND Development] TheInVisibleGoD:
Hum... that seems really interesting!

Just some noob thoughts... In your case, presuming that the bad blocks are effectively there even after a task29, but are not detected (???) by the installation, what really happens when some file reach that bad block location!? Skip to the next "healthy" block or generate corrupted data!?
[HD2 Android NAND Development] memin1857:
Since our phones don't have emmc (meaning hd2 doesn't have dedicated controller for the flash chip) we are using yaffs (yet another flash file system)

which I thought does bad block management (or it wouldn't work at all, because every new phone have bad sectors), it should be managed automatically. I thought yaffs handled bad sectors by itself. What am I missing?
[HD2 Android NAND Development] Rick_1995:
The fact that even HD2 has a dedicated flash controller -.-

i wonder who told you NAND chips would be linked directly to teh ARM chip.

check the irc logs.
[HD2 Android NAND Development] arkatis:
Exactly! Corrupted blocks shouldn't be used during Flashing. That makes sense.

But in that case the phone is acting weird as you guys said; so maybe during installation indeed generate corrupted data on bad blocks.

Dunno, this thing is complicated. And this thread is going no where; only presuming and guessing and and and ... What's the fix???:eek:
[HD2 Android NAND Development] AngelDeath:
Your touchscreen issue to my belief has nothing to do with bad sectors, it has to do with your end key, please read Unresponsive Screen in my Sig for your problem.
[HD2 Android NAND Development] chvvkumar:
This was my log and I was having random reboots every 30 minutes or so. What I observed was, when I installed the ROM after getting the log, the phone would function normally.

I did a restore of apps using titanium backup, and there it was, the phone would reboot again randomly.

I removed a lot of apps by uninstalling them (about 20 of them) and again, the phone is working normally.

So, in my case, removing the apps worked. YMMV
[HD2 Android NAND Development] memin1857:
You're right. Still, yaffs should be doing the bad block management.
[HD2 Android NAND Development] AngelDeath:
Okay just for the record, I am a programming idiot, especially when it comes to Android, I am a computer consultant and network administrator, I am more of a troubleshooter, having said that, If you do a task 29 in mtty, you will see the bad blocks appear at the end of the process, why you may not see it in say the task29 app itself, if that the error possibly isnt being echoed back and only the final result is.

As for the memory management checking bad blocks in magdlr, or clk, I dont think anyone really went that far because if you look at any flash done with bad blocks, I use magdlr so I can affirm this, you will see during the flash process that data is being written or flashed to locations and the recover.log will state a bad block. So I think that portion that was attemped to be written gets lost. If its not getting lost and at the bad block it just moves to the next block, then in at the end of the flash some of the things are not getting flashed since it would run out of room, but that doesnt seem to happen in the recovery.log if you happen to look.

But understand this, even if in theory if memin1857 is right that the bad blocks are marked, your still running out of room, the process of a rom being able to be loaded is still limited, because even if magdlr was marking bad blocks your reducing your available space, and one of the other things you have to consider is after flashing a rom, I have never seen in the logcat anything about encountering bad blocks, which makes me also ask the question does Android during booting, or even during use on a daily basis when it runs across bad blocks mark them and skip over? I am going to presume not.

Also the statement that all phones have bad blocks personally is false, as I stated before, I have a second HD2 and I ran the same tests and the same info 8, and it has no bad blocks, If there is bad blocks then hey are marked long before they even release the phone. So I dont believe that statement to be very true.

Hence if you run a Android Rom like CM7 or a 2.1 version thats small, you can get away with using it, obviously some problems may surface. But larger roms using over 300+ will encounter more problems.

But the key here is, how to make Android have a Bad Block map so not to write to it. But as I stated before, the location of the bad blocks is a big factor.
[HD2 Android NAND Development] chvvkumar:
@AngelDeath

Do you know the size of the blocks? Is the memory address in the logfile the starting address of the block or is the block 1 byte sized?

For the former, what I mean is, if the block size is 64KB, and if the starting address is F0000, the end of the block is F000+FA00(64k in hex)=1EA00.
[HD2 Android NAND Development] soapbox23:
SD builds?

do you guys know if this affects SD builds too? I've been having random reboots using AmeriCanAndroid builds from july15 til present. Weird thing is if I switch to a build before july 15, it works perfect...so that makes me think it's a kernel issue from the ROM. Any ideas guys?
[HD2 Android NAND Development] Rick_1995:
1 block -> 512 kb and the block address in recovery is virtual spl addr, the actual addr = GPIO base + 0x400 + block addr in recovery

the address in log is the address of the 512kb block.
[HD2 Android NAND Development] chvvkumar:
Oh, ok. Thanks for the post, I am not aware of the ARM architecture.
[HD2 Android NAND Development] :
Did anyone even look at this? If this would/would not work, can you please explain? I would like to know..
[HD2 Android NAND Development] mootmetal:
no it doesnt erase the radio ...only os and splash... after task 2a i didnt flash any radio rom and all connections r ok ...i still have 2.12 i flashed befor tasl 2a
[HD2 Android NAND Development] deibit:
I don't get it.bad sectors don't have anything to do with windows or android.my first HD2 had severe problems because of it, after 5 minutes youtube use, it crashed. Then I installed android for the first time instead of windows, and things went better for a while.but this is a hardware degenerative issue, it get worse as time passes..so eventually I got in android the same problems as in windows, and had to replace the phone.

Now everything goes perfect.

If you got a defective unit, there is nothing you can do. Your phone will get worse with time, no matter what you do (its like parkinson)
[HD2 Android NAND Development] buchetka:
Well, I had this issue with back-button (after using it the screen became unresponsive) and it ended-up with completely new screen & chassis & something they called "button electronics" ... so what remained were the battery cover, guts of the phone & buttons :) Luckily warranty was still in effect.:cool:
[HD2 Android NAND Development] Rick_1995:
I hope you are wrong as i was stuck at boot which is a known indication of bad/missing radio and also did you directly flash cLK/MAGLDR after task 2a or did you flash a WM rom interim ?
[HD2 Android NAND Development] mootmetal:
after task 2a i flashed clk and typhoon 3.5.1 ( wish is known for bootloops with fresh install) i didnt flash the radio rom ...but i didnt had any probleme ,everything went great.

i dont know any way to completely erase the radio ...cuz i have the famous 60ma probleme ...and i tried everything, even to delete the radio to see if it cause the drain but ididnt find how to do
[HD2 Android NAND Development] htcfreak:
TASK 29, erases the OS partition, it doesn't do anything to the RADIO :D
[HD2 Android NAND Development] htcfreak:
How do I do this for MIUI based ROM's..???

I mean, I could not find Advanced/Error Reporting, sorry to be lame :p
[HD2 Android NAND Development] clyder:
Procedure was done in recovery, not in android.
[HD2 Android NAND Development] htcfreak:
LOL I am embarrassed :o

I didn't read it properly :p

Thanks mate
[HD2 Android NAND Development] exbros:
Finally somebody wrote something about the issue I've been monitoring for last couple of weeks... Good job, thanks AngelDeath :)

Just an idea for Devels: if we can find a list of bad blocks (if it exists on the device) or just generate it during initial NAND clean/format procedures then adding few lines of residential low level code [(micro)assembler] to boot loader (?) to avoid these blocks (whatever: remapping / jumping over them or marking as 'occupied' then unusable) should not be too difficult? Something similar to HDD SMART mechanisms comes to mind...

There's only one question - is it worth time and effort since the HD2 is an ageing device?

And last but not least: any idea how to check for the bad blocks from the running Android or WinMo, so without flashing the ROM again? Is it possible or it's just too low-level procedure to do it from the running OS?
[HD2 Android NAND Development] theslam08:
Here, http://xdaforums.com/showpost.php?p=16079735&postcount=31 this was asked and shot down :(. See 2 posts below that one. Seems they are spread all over, no real way of combining the bad blocks...sucks :(
[HD2 Android NAND Development] exbros:
Sorry, but you don't understand :)

I know that bad blocks can be spread across multiple different addresses and I know it's not a problem, at least not a problem for what I suggested. Do you know how SMART technology used in HDD disks works? I can explain it in details if required... ;)
[HD2 Android NAND Development] :
thanks for this information ive had my hd2 for about 2 years now and have done many flashes and to my suprise only one bad block on the data partition which is to be expected
[HD2 Android NAND Development] Danny1911:
I think that by using simple ROMs like "NexusHD2-Gingerbread V2.8" which needs a ClockWorkMod Recovery partition of just 135MB would increase the probability of having less problems regarding to these bad blocks...

because even if I get this...

Formatting /data...

mtd: not erasing bad block at 0x05860000

mtd: not erasing bad block at 0x058a0000

mtd: not erasing bad block at 0x06020000

mtd: not erasing bad block at 0x060a0000

mtd: not erasing bad block at 0x28c00000

Done.

Formatting /system...

mtd: not erasing bad block at 0x01ae0000

mtd: not erasing bad block at 0x080a0000

Done.

mtd: successfully wrote block at 0

I can still run Android without having any problems (random reboots/freezes)... but well.. if to be honest.. it happened to me a few times to see my hd2 doing random reboots or to freeze, but this was quite rare...

I prayed God to deliver me from problems like these even though I have some bad blocks on my hd2 already.. but it's still functioning good.. :)
[HD2 Android NAND Development] AngelDeath:
Use mtty 1.42 and do a info 8 it will not touch your system, you will have to be in the tri-color mode to run mtty.
[HD2 Android NAND Development] AngelDeath:
Danny if you read the first post, I stated that Android roms using a smaller partition are less likely to have this, Like cm7 versions, miui versions, and such that are non-sense version use a smaller system partition, which helps not have this problem surface as much as using a larger partition, hence why I said also that tmous using eu versions for the moment can possibly avoid this problem too.
[HD2 Android NAND Development] htcfreak:
-- Wiping data...

Formatting /data...

mtd: erase failure at 0x06280000

mtd: erase failure at 0x09600000

Formatting /cache...

Formatting /sd-ext...

I:Formatting unknown device.

Can we find the size of these bad blocks..???

& is it somehow possible to repair them..???
[HD2 Android NAND Development] exbros:
... it has been already stated in this thread that each block is 512kb

... and it has been already stated that it is irreparable (imagine blown bulb - would you try to fix it? ;) )
[HD2 Android NAND Development] htcfreak:
No need to flash ROM to check BAD BLOCKS

You can get a report before flashing as well

1) Format your Boot, Data, Cache, System, Dalvik Cache (Eu users your Dalvik Cache is on your sdcard on the SD-EXT)

2) Go to Advanced, then Error Report.

3) This will copy the Recover.log to your SDCard.

4) Go Back and enter Mount & Storage.

5) Mount USB SD.

6) On your computer navigate your SD Drive.

7) Look for a folder called: clockworkmod.

8) Inside you will find a file called: recovery.log

9) Copy this to your Desktop.

10) Open with Wordpad or Notepad++

11) After checking you Bad Blocks, flash the ROM
[HD2 Android NAND Development] exbros:
Yes, before flashing, but using this method flashing is unavoidable, isn't it? ;)
[HD2 Android NAND Development] htcfreak:
Sorry my bad, I didn't read the previous posts..!!!

Thanks for the assistance :d
[HD2 Android NAND Development] stirkac:
we need "software" to flag bad blocks! but since hd2 is aging, i don't believe something like that will come...

every phone is shipped with bad blocks. it makes up for cheaper production.

goin to buy something in fall, until then hd2 will do just fine. WinMo has bad block check implemented right, last resort for me if it starts screwing android :)

only one block on my hd2 atm. after 1,1/2 years of flashing atleast weekly, it's fine by me :D
[HD2 Android NAND Development] Rick_1995:
The only method without flashing is using mtty and issuing "info 8"

i think the list of bad blocks is stored somewhere in SPL address, which is physical 0x00000000 to 0x00000219

Check this post where i in my complete noobness wrote data to the partition and removed htc logo during the flash, i hope partition addr is also stored somewhere in this address space since mtty is able to read the list and i dont think it does a buffered read and write of the bit address to check whether they are bad or not since data is preserved and it takes less than 5 seconds for the whole process.

So i think, i will be trying to include this fix in the coming version of cLK. as for magldr, i probably think we will get something big soon, under my observations whenever cotulla and dft go underground they come up with something substantial :D

EDIT: even if we do mark those blocks bad, the linux kernel will have to read the list and skip the respective blocks, so a better implementation would be to make a fix for linux kernel to skip the bad blocks and read the next block for the data. (but this could already have been done since we are using an old 2.6.32 kernel and the latest for ARM is probably 2.6.37 and 2.6.39 using hacks)
[HD2 Android NAND Development] THANHVO31:
Luckily, after 18 months cruel torture flashing my HD2 found no any bad block!
[HD2 Android NAND Development] exbros:
No :)

No, it's going to be slow, very slow... moving this kind of low level check operation to the kernel space would slow down the whole operating system horribly!

I know nothing about this kind of mechanism in Linux kernel and would be very surprised if this will be ever considered (see above) - wasting kernel space and slowing down the whole operating system due to a trivial read/write operation is basically bad idea, even loadable kernel module would be a resource waste.

I know (almost) nothing about Android/other mobile systems but am involved in kernel and different Linux ditributions development since early '90s ;)

Therefore my suggestion (again) of adding few lines of raw machine code to the loader. This would work like SMART or - just for an illustration purposes - like moving the whole operation to the PC BIOS. Not only extremely quick but makes the whole solution completely transparent for ANY kernel AND ANY operating system loaded through this loader - solution is completely OS independent so there's no need to worry during consecutive flashes of different versions of ROM (even switching between Android, WinMo, Linux, WP7 or any others, practically even unknown at the moment).
[HD2 Android NAND Development] exbros:
Very good read, thanks for the explanations! Despite being big enthusiast I can't find enough time to do some proper research (but will have to since I am experimenting with my own HD2 bootable Linux distro... ;))

So, I'm afraid, ARM init processes are quite different and my whole understanding and knowledge based on intel architectures are useless. I wrongly assumed that if we can trigger something before the OS (like NK, SLDR, SPL, MAGLDR) then we can add few lines of code there (NK, SLDR, SPL, MAGLDR) but now I know it's not the case and it is much more complicated.

BTW - PC BIOS example was used just as an illustration of the idea of going lower with the code, to the - let's say - almost hardware level, and it was intended for less literate readers who doesn't know what a machine code is but do know what is the difference between BIOS and OS ;)