[Samsung Galaxy Nexus] Lanchon:
i got the chance to take a look at this phone and it reminded me of something.

once i had to analyze an old 16GB SSD from STEC, it had an encrypted linux distro that underwent a major upgrade and never booted up again. first i couldnt figure out why the booting failed so early, but then i realized that during the upgrade process the SDD had gone read-only. no ATA command would modify it, not even the various erase commands. other units of the same model were failing and people would replace them. eventually what was happening became clear: the FTL data structure maintained by the drives firmware to emulate a standard block device was getting corrupted during periods of high volume of writing. the firmware was smart enough to detect the FTL corruption, but not smart enough to fix it. instead, it was "mounting" what remained of the FTL structure device read-only and exposing its contents via ATA as a last resort for customers to recover what data they could.

but then STEC reacted and sort of publicly leaked a firmware update tool that you could use to recover the drive. this drive already had that same firmware, but flashing the firmware all the same wiped the SSD reformatting the FTL structure, thus reviving the drive. this makes sense, as evolving the FTL data structure ("importing" it to a newer firmware) would be difficult and error prone. its much easier to ask the customer to dump the data somewhere and get it back in after the flash. keep in mind that this was a time of small and expensive SSDs anyway.

the eMMC of this phone looks exactly like that. writes succeed immediately and so do erases, but all the firmware does are no-ops. the phone is locked in the middle of a stock to stock upgrade (lots of writes... surprise!). it has a locked bootloader, stock recovery and stock ICS. (i imagine it's not even rooted, but i didnt check.) so this qualifies entirely as a defective device that should be replaced by google or samsung were it under warranty (dont know about that).

writes, wipes, fastboot erases, nothing works. while i prepared for a final test i backed up a lot of the phone, and an interesting thing happened. via adb on a recent kernel (by ways of fastboot oem unlock (doesnt stick but works temporarily) and fastboot boot img) i can read the whole mmcblk0 device just fine, no errors reported from the eMMC. but if i boot a monitor over the on chip OMAP bootloader (google OMAPFlash) and dump the eMMC from there, there is a sector range that hangs the eMMC driver in the monitor. these are 13 contiguous sectors, about 20MB past the beginning of the eMMC.

this is noteworthy. the android kernel driver and the OMAPFlash monitor driver implemented by samsung are obviously handling the eMMC differently, and the android kernel *is silently ignoring errors* somehow!! this is dangerous and something the community should know and maybe fix. i've had several galaxy nexus, and i've experienced silent corruption of the data inside camera pictures several times. this could be the mechanism behind those incidents. might this be a side-effect of the brickbug fix?

btw, ive OMAPFlash-read those same sectors in another gnex i have just to test and sure enough they read back with no issues.

back on track. i've read that brickbugged eMMCs that were still not dead but hanging the OS actually resumed working after 5 to 25 minutes if u were patient. and it is widely reported that if you wait, the firmware actually repairs that part of the FTL after the timeout, gradually improving the health of the eMMC over time. many people have completely cured their eMMCs this way, running tools that exercise the eMMC for days in a row.

so before continuing i attempted to OMAPFlash-read an affected sector and let it linger for long. two hours into it there was no response so i interrupted. and the defect wasnt cured by this. if the method works, it has to be done before the read-only lock happens.

so what i thought was, in the brickbug aftermath, kernels and bootloaders were all stripped of erase commands. wipes and fastboot erases actually dont erase at all. so because erases were never tested, there was a small chance that issuing them might get the damn thing back to life. and id bet my life that the OMAPFlash monitor driver was *not* updated for brickbug safety and can issue erases. this is why i got involved with OMAPFlash in the first place.

so first i tried to erase the 13 unreadable sectors. success, but no change: they remained unreadable.

finally after dumping enough of the drive to make sure i could reconstruct the partition structure and the important partitions through OMAP flashing, i went ahead and did a whole eMMC erase, and... (drum rolls) nada, no change. damn thing!

so the only way to shake the thing back to life is with a propietary samsung tool that reflashes the eMMC firmware and formats the FTL, exactly like in the STEC SSD affair. samsung has it, but doesnt want to release it. google has it, but its not their IP so they cant give it away. i suppose samsung doesnt want to expose their eMMC firmware binaries. well they could have thought of that before and encrypted the firmware update instead of screwing us. or they could take responsibility, man up, bite the bullet and publish it, just they way STEC did. then also i suppose google could have pressured samsung into it, but they didnt.

Ken Sumrall with google helped the community at lot during the days of the brickbug saga. here's a quote from him.

"Originally Posted by Ken Sumrall

As I mention above, the revision 0x19 firmware had a bug that after an emmc erase command, it could leave the internal data structures of the emmc chip in a bad state that cause the chip to lock up when a particular sector was accessed. The only fix was to wipe the chip, and update the firmware. I have code to do that, but I don't know if I can share it. I'll ask."

(http://xdaforums.com/showpost.php?p=26255080)

starring...

name: VYL00M

fwrev: 0x25

hwrev: 0x0

...as the wicked eMMC

so there. another almost perfectly good phone lost to samsung's faulty engineering coupled with samsung's proven track record of horrible community support. thank you samsung!