[HTC Wildfire S] no.human.being:
Right. I'm not opposing you personally, Bad-Wolf, that's the first thing I'd like to make absolutely clear.

Uuh, please don't try to make a distinction and call us "the pros". You've actually contributed a lot to the success of this. Without your contributions, we might have never gotten off the "there's something hidden in the mtd3 partition" idea. :D

Like I said above, I'm not opposing you personally, Bad-Wolf, but, like heavy_metal_man says, most of the time you're either off-topic or repeating ideas that are either already implemented or have been verified and dismissed a few pages ago. There's nothing wrong with some amount of general discussion going on, but you've really been taking it to the limit quite a few times and in my opinion it disrupts quite a lot of our efforts. And all of the "everybode hates me"-nonesense you're letting off at this point is again nothing but distraction from our goal. You can't change other people, you can only change yourself. And changing yourself has nothing to do with shouting around that you're going to change ("nobody will hear a word from me unless I think it's important"). Just think about the critics and see what you can do about it. If you take this seriously, you're going to see that most people here will stop "hating" you. However, this is a procedure you have to do for yourself, not shout out to the world.

Not only this. They're currently doing the following:

1. Check whether the block is marked as "bad" (probably checks "bad" flag in the out-of-band area?!). If it is, check whether the user wants to erase bad blocks too, if not move on to the next block (see "Comment 1"). If it cannot be determined whether the block is bad (e. g. the controller doesn't support bad block management), abort the process completely (see "Comment 2").

2. Try to "unlock" (does this reset the "locked" flag in the out-of-band area?!) the block. If this fails, move on to the next block (see "Comment 3").

3. Try to erase the block. If this fails, move on to the next block.

Comment 1: This behaviour is not problematic as we can parametrize it NOT to skip bad blocks.

Comment 2: Why that? :eek: If we know that the block is bad, we skip it or erase it nonetheless (user may specify), but if we do now even know whether it's bad or not, we abort the complete erasure process. How does this make sense?

Comment 3: Will "unlocking" a block that isn't even locked succeed or fail? If it fails, blocks that are not locked will not get erased by the utility. How does this make sense?

What I'd do is rather the following. I don't know whether this procedure is "correct" or anything, but it seems logical to me.

1. Try to erase the block. Always do this first, no matter what the block's "out-of-band" data says. If this succeeds, set some "status variable" that the last erasure succeeded, else set some "status variable" that the last erasure failed.

2. If the last erasure failed, this might be due to the current block being locked, so unlock the block and try erasing it again. This time it should succeed, if not, then the block is probably really "bad" for some reason and we can't do much about it. (Should we mark it as "bad" at this point?)

3. Only after the block is either erased or confirmed to be completely unerasable, move on to the next block.

I'm not exactly sure what this "bad" marking is trying to accomplish though. I mean when we have a file system on the partition, it might tell the file system driver to avoid the block. However, on a raw partition (like "boot" or .. well .. you name it .. "radio" :D ) why should we even care about bad blocks? I mean the partitions are "raw". There's nothing "on top" that could "work around" the bad blocks. All they can do is "avoid" writing to them, rather leaving a 128 KiB "gap" in the kernel/radio/etc. but they can't put that data elsewhere as this would disrupt the addressing scheme (there's no address translation component in the memory controller that could "remap" the bad blocks to "good" ones). So it might even be tolerable to mark all the blocks as "good", no matter what they really are. The worst that can happen is that you write to it and the information is lost. But if you mark it as "bad", all the system can do is say "well that one is bad so don't write to it" and discard the information to be written, as it has no possibility to "relocate" it elsewhere on a "raw" partition. So in this sense "information that's supposed to reside in a bad block" is ultimately lost, this way or the other way. So we might as well mark all the blocks as "good". As long as there's no file system on top, this shouldn't be of any disadvantage, right?