they say (in the PSA message of entropy) that the OTA update of ICS is affected with the "superbrick" bug that bricked a lot of users... and the idea scares me...
Please post your eMMC CID data to help mr. garwynn in his investigations.
As of now, the bug or effects of the bug is hard to pinpoint. and with your help, it could be solved.. thanks for cooperating.
NOTE: you can use Terminal Emulator and input the codes in bold above. then copy paste it here. thanks
To MODS: i edited the thread since a few users have posted their eMMC CID here and avoid split threads with the same posts. thank you.
Note: stop posting eMmc data. Mr. Garwynn got enough stuff already. Just post if you have different cid other than 0x19 (check his thread how to determine)
Latest Update from Android Team:
Hello fellow XDAers!
I'm looking into something and need to kindly request some data from Note owners for comparison. We found a potential attempt to fix this and want to check Note eMMC cid data to see if it matches.
Can you please run the following from adb shell?
(Thanks to sfhub for original steps, two additions to it.)
shell@android:/ $ su
shell@android:/ # cd /sys/class/block/mmcblk0/device
shell@android:/sys/class/block/mmcblk0/device # cat name hwrev fwrev manfid oemid date type serial
MAG4FA
0x0
0x0
0x000015
0x0100
08/2011
MMC
0x01234567
shell@android:/sys/class/block/mmcblk0/device # cat cid
1501004d414734464119012345671f0f
Please copy and paste the results (examples in italics) and either PM or add here when possible. I need to expand the sample set as much as possible so those who can do it it is much appreciated!
And to follow the discussion on the Epic 4G Touch side (Sprint Galaxy S2):
http://xdaforums.com/showthread.php?t=1644364
Thanks to all in advance for your help!
Please post your eMMC CID data to help mr. garwynn in his investigations.
As of now, the bug or effects of the bug is hard to pinpoint. and with your help, it could be solved.. thanks for cooperating.
NOTE: you can use Terminal Emulator and input the codes in bold above. then copy paste it here. thanks
To MODS: i edited the thread since a few users have posted their eMMC CID here and avoid split threads with the same posts. thank you.
Note: stop posting eMmc data. Mr. Garwynn got enough stuff already. Just post if you have different cid other than 0x19 (check his thread how to determine)
Latest Update from Android Team:
Well, it's been some time but thankfully Mr. Sumrall from Android did get back to us on our questions. I think the community will find that this was worth the wait.
Issue: fwrev not set properly.
As we suspected the bugfix is not in our build. (The patch applies this unconditionally.)
Originally Posted by Ken Sumrall
The patch includes a line in mmc.c setting fwrev to the rights bits from the cid register. Before this patch, the file /sys/class/block/mmcblk0/device/fwrev was not initialized from the CID for emmc devices rev 4 and greater, and thus showed zero.
(On second inquiry)
fwrev is zero until the patch is applied.
Question: Revision didn't match the fix
(Emphasis mine in red as it discusses the superbrick issue.)
Originally Posted by Ken Sumrall
You probably have the bug, but rev 0x19 was a previous version of the firmware we had in our prototype devices, but we found it had another bug that if you issued an mmc erase command, it could screw up the data structures in the chip and lead to the device locking up until it was powered cycled. We discovered this when many of our developers were doing a fastboot erase userdata while we were developing ICS. So Samsung fixed the problem and moved to firmware revision 0x25. Yes, it is very annoying that 0x19 is decimal 25, and that led to lots of confusion when trying to diagnose emmc firmware issues. I finally learned to _ALWAYS_ refer to emmc version in hexadecimal, and precede the number with 0x just to be unambiguous.
However, even though 0x19 probably has the bug that can insert 32 Kbytes of zeros into the flash, you can't use this patch on devices with firmware revision 0x19. This patch does a very specific hack to two bytes of code in the revision 0x25 firmware, and the patch most likely will not work on 0x19, and will probably cause the chip to malfunction at best, and lose data at worst. There is a reason the selection criteria are so strict for applying this patch to the emmc firmware.
I passed on our results a few days later mentioning that the file system didn't corrupt until the wipe. This is a response to that follow-up.
As I mentioned in the previous post, firmware rev 0x19 has a bug where the emmc chip can lockup after an erase command is given. Not every time, but often enough. Usually, the device can reboot after this, but then lockup during the boot process. Very rarely, it can lockup even before fastboot is loaded. Your tester was unlucky. Since you can't even start fastboot, the device is probably bricked. :-( If he could run fastboot, then the device could probably be recovered with the firmware update code I have, assuming I can share it. I'll ask.
Question: Why the /data partition?
Originally Posted by Ken Sumrall (Android SE)
Because /data is the place the chip that experiences the most write activity. /system is never written to (except during an system update) and /cache is rarely used (mostly to receiving OTAs).
Question: Why JTAG won't work?
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.
Question: Can a corrupted file system be repaired (on the eMMC)?
Originally Posted by Ken Sumrall
e2fsck can repair the filesystem, but often the 32 Kbytes were inserted at the start of a block group, which erased many inodes, and thus running e2fsck would often result in many files getting lost.
So, while the fix doesn't apply to us at the moment, we've been given a great insight into the superbrick issue as well as information that a fix is already developed (hopefully we'll see it released!). The bug likely applies to us and assuming the fix for the 0x19 firmware is given then it would apply to our devices.
On a lighter note, I wanted to include his close:
Originally Posted by Ken Sumrall
You are getting a glimpse into the exciting life of an Android kernel developer. Turns out the job is mostly fighting with buggy hardware. At least, it seems that way sometimes.
Last edited: