yashsingh1/xdaforums huggingface dataset:
[Samsung Epic 4G Touch] forest1971:
Just wish to make suggestion for correction of a minor piece of information:

If Jaymoon used a PIT file from Pit-Patched-standard.zip from hg42 thread as he described in his post, then he will loose only 4GB of space. The internal sdcard (USB storage) space will decrease from original 12.4GB to 8.45GB. So it is not a loss of 8GB but just 4GB. Probably has mistaken between the internal sdcard capacity and the whole emmc capacity. Hope it is useful in some way. cheers.
[Samsung Epic 4G Touch] TerryMathews:
At least as far as the E4GT is concerned, Samsung has not released one ROM that can damage the EMMC.
[Samsung Epic 4G Touch] Entropy512:
Yeah, this whole thing really "blew up" when N7000 XXLPY went live - that was the first time outside of Korea than an affected kernel was officially released.
[Samsung Epic 4G Touch] garwynn:
Since sfhub has been on vacation I went ahead and sent the details from drnull's tests to hg42 to see if he can make a custom PIT for the E4GT. It should reduce the loss even further to 2GB - and give a device specific solution instead of using one not originally designed for this device.
[Samsung Epic 4G Touch] forest1971:
That would be nice when hg42 can provide it! cheers.
[Samsung Epic 4G Touch] garwynn:
Update - E4GT Pit Files Available

Thanks to hg42 as he was able to create custom PITs specifically for the E4GT.

You can find them at the bottom of the first post here:

http://xdaforums.com/showthread.php?t=1667886

Please also note:

1) There is no testing done on these by hg42 so you use them at your own risk.

2) Please continue to at least check on your warranty repair/replace options as this will not restore full eMMC functionality. At time of posting this is still the only way to restore full eMMC functionality.
[Samsung Epic 4G Touch] KnukLHead:
Just tried and for me at least for right now I'm bootlooping. I'll update with more info as soon as I try some other stuff
[Samsung Epic 4G Touch] KnukLHead:
I booted into the recovery and did a factory wipe and it booted up. Running fine
[Samsung Epic 4G Touch] KnukLHead:
the internal memory after using the .pit for the et4g is 9.5gb and the device memory is at 1.9 gb
[Samsung Epic 4G Touch] djnattyd:
Hey guys, first post on XDA and it's a question.

I've read through all the posts in this thread regarding the superbrick issue and I'm still unsure what options are available to me in regards to custom ROMS.

Bit of background:

I've got a GT-N7000 running the official UK ICS release, it's been rooted using the method that doesn't up the flash counter but that's pretty much it. I wanted to install a ROM in order to get better battery life (got the 200mhz/Deep Sleep issue) but after reading through here I'm a bit wary, especially as Chainfires' GotBrick app said I'm at risk. It *has* been factory reset twice without issue, once after the ICS update and then again in effort to fix the sleep problem.

So my question is; What are my current choices? Should I wait for an official Samsung fix?

Cheers
[Samsung Epic 4G Touch] KnukLHead:
When you say "the official uk ics" do you mean it was an ota or was it a leaked build? If it was ota when did you receive it
[Samsung Epic 4G Touch] Entropy512:
Flash SpeedMod or Franco's kernel (DAFUQ needs updates for compatibility with released ICS) - all of these are safe.
[Samsung Epic 4G Touch] djnattyd:
Thanks Entropy
[Samsung Epic 4G Touch] nfribeiro:
Entropy512, is the last CF-root 5.6 also safe?
[Samsung Epic 4G Touch] KnukLHead:
So now that I've flashed that pit and resurrected my e4gt can I Odin to gain root and flash via clockwork mod like normal? Wasn't sure if repartioning everything had any affect on that.
[Samsung Epic 4G Touch] giri@xda:
Do I need to switch to a Safe Kernel?

Entropy512, I got my N7000 last week on ebay & have been reading through posts to understand this issue. I do understand that all kernels are affected except SpeedMod & Franco's. I am unsure if my phone has already been affected as it seems to have been updated from Gingerbread to ICS & then a factory reset seems to have been done after installation of CWM & SuperSu by the guy who sold me the phone on ebay.

Could you please tell me if I need to flash one of those as I am running stock ICS XXLQ2 & confused / afraid of getting phone bricked by not moving to a safe kernel. I will download one of these safe kernels & flash it from PC ODIN (checking only the "Reboot" option).

My current Kernel version is in the attachment. Moreover, I seem to be missing 3Gb of space :mad:

Thanks for your reply.
[Samsung Epic 4G Touch] nfribeiro:
We don't have 16gb and you are forgetting the memory rom.
[Samsung Epic 4G Touch] Entropy512:
Not entirely. Wiping from it is safe, but if you flash something with an update-binary that does an erase command while formatting a partition, it won't be safe.
[Samsung Epic 4G Touch] giri@xda:
Thanks for clarifying on space. :D

However, am waiting to know if I need to flash a safe kernel or not.
[Samsung Epic 4G Touch] nfribeiro:
Thanks Entropy512. But if I didn't flash or wipe I'm safe, right?

In other orders, in the next flash I will flash GB with ODIN first and after that wipe and new flash with GB Kernel. Am I thinking wrong?
[Samsung Epic 4G Touch] Entropy512:
Or use a "safe" alternate ICS kernel such as speedmod or franco.
[Samsung Epic 4G Touch] giri@xda:
Entropy512, please let me know if I need to flash a safe ICS kernel (speedmod or franco) as I am on stock ICS XXLQ2 and kernel version shown is

3.0.15-N7000XXLQ2-CL605927

dpi@DELL169#3

SMP PREEMPT Tue May 22 11:17:48 KST 2012

Thanks for replying
[Samsung Epic 4G Touch] shoey63:
Seeing as you're on stock ICS,do easyroot method by Dr. Ketan and then flash speedmod kernel using Mobile Odin Pro or some other app. You will be safe from bricking after that. (Just double check your on speedmod first before you do any further flashing/wiping/formating)
[Samsung Epic 4G Touch] jgaviota:
It seems that there was a superbrick from stock official ICS on the Galaxy Tab 7.7

Hard bricked 7.7
[Samsung Epic 4G Touch] Entropy512:
Already got a PM about that, trying to get more data on exactly what he flashed from and a few other things (such as definitively confirming Superbrick).

I've seen Odin occasionally fail on factoryfs if the existing partition content was corrupt, even though Odin should just be doing a raw write of the partition ignoring what is there already. It happens occasionally to Galaxy Note users and I had to make recovery changes to fix it. (Easily repaired by formatting the partition.) However if he executes some tests to do raw partition reads and these fail - he has Superbrick.
[Samsung Epic 4G Touch] Esoteric68:
Maybe sticky this one too until we have an answer? I know the majority of what is said in this thread will go flying over most people's heads (mine included) but it's important that people new to the phone understand the risks and are aware of all the research that has gone into fixing/avoiding it.

Thanks :)
[Samsung Epic 4G Touch] dejarque88:
I bricked mi phone ???

Hi Guys, first of all I should say that my english is not so good.

Ok, my situation is a bit diferent.

I installed the lq5 and then I did a wipe data BUT with the stock recovery. Then, the phone never turned on again. Although, it can charge, enter in a download mode, and it doesnt enter in recovery mode.. I have flashed a los of roms trying to fix it, in the most of the cases the proces of flash get frozen in "data.img"... For another way, I flashed the "unbranded aro lp4 ics" and the process of instalation has completed correctly... but when i turn on the phone it get stuck on the logo "galaxy s2 i9100" and it doesnt start.

Are there any way to fix it??? Some ideas'??

I really will appreciate it.

Thanks.

David from Argentina.
[Samsung Epic 4G Touch] Esoteric68:
Hi David, hopefully one of the guys with all the knowledge will be able to help you out. Don't be discouraged if they don't respond right away but I'm sure if there is a solution someone will help you reach it. :)
[Samsung Epic 4G Touch] Entropy512:
I am about to send you a private message - If you indeed did suffer eMMC damage from stock recovery, I really want to try and get your device to the correct people.
[Samsung Epic 4G Touch] nfribeiro:
I9100XWLPM (4.0.4) has the same problem as the leaked one (LQ5). In the russian forum two users had superbricks!
[Samsung Epic 4G Touch] garwynn:
Source dropped for the E4GT today and here are the findings so far:

I see it in a few of the source files, such as sdhci.c and mshci.c I believe Entropy mentioned ours uses sdhci - in which case it's not safe. However, I am sending a PM to both him and sfhub to see if either has time to confirm which controller the eMMC uses.

For those of you who would like to peek at the source, I took the contents of /drivers/mmc/host and compressed into a smaller file here: View attachment host.zip

It's just a matter of confirming which one is used as the controller for the eMMC and whether or not the following code is included:

mmc->caps |= MMC_CAP_SDIO_IRQ | [B][COLOR="Red"]MMC_CAP_ERASE[/COLOR][/B];

The code in red is the offending setting that enables secure wipes/formats that triggers the bug based on information known to this point.

Edit: See Entropy's verification below - Kernel should be considered unsafe. Devs are recommended to remove the option from mshci.c which will avoid the offending operation that locks up the eMMC.
[Samsung Epic 4G Touch] Entropy512:
mshci for the internal eMMC chip.

sdhci is for the external SD and the wifi chip - having ERASE capability is OK here.

There's a possibility they may have implemented a solution which only blocks secure erase and allows nonsecure erase through, but I have a feeling that instead it's just another bomb with no safety features.
[Samsung Epic 4G Touch] garwynn:
That would go back to their conclusion which you mentioned earlier in the Note thread - that the two behave differently. However, I also believe as you that that may not be the case. It really burns me that they left this in; I'm not surprised, but it still is infuriating. At least with source finally the devs can simply remove the option and recompile, meaning that ICS ROMs can easily be made safe.

I'll be honest, I'm half tempted to run a regression test of stock factory reset and see if I can trigger it. But hopefully your F2F will get at least some results where this won't be a total loss.
[Samsung Epic 4G Touch] sfhub:
Hi Garwynn, I just got back from travels and I'm working through a bunch of backlog. Would you be able to zip up the drivers/mmc directory? That is the another place they could have placed a more targeted fix.
[Samsung Epic 4G Touch] garwynn:
Edit: Here ya go.
[Samsung Epic 4G Touch] Mattix724:
Now we just need a way to fix emmc that has already been locked up...

I still need to send my e4gt to Samsung since it is still warrantied.

How does Samsung fix bricks related to the emmc lockup bug? Can't they just leak whatever they use so that those of us who are bricked can repair at home?
[Samsung Epic 4G Touch] Esoteric68:
sfhubbbbbbbb! Glad to see you around :)
[Samsung Epic 4G Touch] Entropy512:
Right now their service centers are still doing motherboard replacements.

I MAY be getting the documentation required to do a full chip reset in a week and a half. This will wipe the damage clean - but it'll also wipe your bootloaders according to everything I have been told. :( It may be possible for some devices to repair the damage and rewrite bootloaders in a single power cycle, but I suspect many devices will come out of it as a traditional hardbrick. At least devices repaired in this manner will be JTAGable.
[Samsung Epic 4G Touch] sfhub:
I looked over the obvious places where they might have short circuited a secure erase and it didn't look like anything was done on that front either. I'll look more carefully later as I might have missed something. Sometimes fixes can be done in less obvious ways that aren't immediately apparent.

We don't get source code for the userspace utilities like recovery and update-binary, but once the FF18 OTA is available, we can run an MD5 on it to compare against previous knowm problematic update-binary executables to see if that changed. Probably can do the same for the recovery binary. I think I compared it a few weeks ago and didn't find any changes, but I will go back and reverify.

If neither recovery, update-binary nor kernel mmc drivers (either completely removing mmc_erase in the host capabilities or something more specific to secure erase) were changed then we are still exposed to the issue.
[Samsung Epic 4G Touch] ruffneckZeVo:
So with this method i could recover the 8gb i lost using the custom pit method the phone works great just would like my partions to be normal again
[Samsung Epic 4G Touch] Mattix724:
If there is a way to reset the chip that would be awesome! I doubt it would recover my brick though... unless somehow my boot loader is still okay.

How can I tell whether or not the boot loader was affected in my emmc lockup?
[Samsung Epic 4G Touch] Entropy512:
It's possible to determine if a binary attempts to fire commands at the chip safely - check my n7000_erasetest_kernel repo on github

Yeah - although there's a high likelihood it might hardbrick your phone in the process as mentioned previously so that it needs JTAGging.

Once I get the information, I may need to work with an SPH-D710 kernel developer to deploy it on that device. Right now I'm thinking of sbrissen since I know him from the cyanogenmod IRC channels.

If your device isn't turning on at all, the bootloaders are hosed. This is a scenario where you will require JTAG AND the JTAG box guys will need to implement the chip reset sequence. :(

It would be a lot easier if they would give us what is needed to deploy AdamOutler's Unbrickable Mod on Exynos devices, but they are refusing. The other ERDs are not happy about this - so far in our opinion, every "solution" they have proposed for protecting devices is incomplete and unreliable (after all, it amounts to "do nothing and let the bricks pile up" as it involves no change from them and was a change we're already deploying to as many places as we can), and similarly the "solution" for repair they have proposed is incomplete and will be unreliable due to fact that it will frequently fail and leave a traditional hardbrick, and it won't be possible to deploy it at all on devices that have already suffered bootloader damage.
[Samsung Epic 4G Touch] sfhub:
BTW the update-binary included with the official FF18 ICS OTA update matches fe22, fe10, and the previous ICS update-binary executables, so they definitely didn't patch update-binary. For their OTA it doesn't matter as they don't do a format, but it should be considered unsafe to perform a format using this update-binary with an unpatched kernel, if someone should choose to use it with their own ROM install script.

update-binary-ff18 [MD5: 439f2f998616c0ddf7b2f0149d6f7669 Size: 241,036]

I'll check the recovery binary to see if it changed later, but I doubt it.
[Samsung Epic 4G Touch] jefbal99:
so running a factory reset from Android has the potential to super brick?
[Samsung Epic 4G Touch] sfhub:
On stock, it likely does, but not because of update-binary, because of stock recovery. Doing a reset in Android reboots into recovery and recovery does the actual reset. I'll verify the md5 of stock recovery to see whether they changed it or not to be sure after I finish some packages.

Since the problem is likely in the wear-level encoding of the EMMC firmware, it won't necessarily happen every time you do a reset. The same operation can work fine, then on the Nth reset, it fails.

We don't have the source for the EMMC routines, so we can't really say how often the superbricks would happen and trying to figure that out treating the phone as a black box is prohibitively expensive due to not having reasonable ways to recover the damaged areas.
[Samsung Epic 4G Touch] Entropy512:
Now that you have kernel source, it would probably be better to test the stock recovery against an instrumented kernel rather than MD5 it.

https://github.com/Entropy512/n7000_erasetest_kernel/commit/c9b5be55339417831a507de9e41a0493113c8076 - this takes mmc_erase(), neuters it so it always returns -EOPNOTSUPP without sending anything to the chip, and prints a message any time an erase is attempted of what was attempted for erasure and what the erase args were.
[Samsung Epic 4G Touch] sfhub:
Yes, thank you, I saw it way back when you first put it in. If I don't get to it right away, I'm sure someone will. I'm finishing up some other packages right now but will get on it right after.
[Samsung Epic 4G Touch] feyrune:
Sounds like it officially shoots a hole in their excuse of only unlocked recoveries causing the bricks.
[Samsung Epic 4G Touch] Bruce Inman:
So, my friend's phone has the OTA ICS update.

We want to induce the superbrick.

So I'm assuming that if we reset to factory enough times, it will/may happen?

Is there anything we can do that would help the devs test anything before we proceed?
[Samsung Epic 4G Touch] garwynn:
The two known locations on the E4GT are in the data and system partitions.

So changing the contents on these and then performing a stock factory reset several times is a good test plan.

From the OTA thread:
[Samsung Epic 4G Touch] hakaz:
I decompiled zImages from XWLPG XWLPI XXLQ5 XWLPM to verify differences between the kernels.

4.0.4 branch:

XXLQ5 against XWLPM shows no diff in ko-modules despite the version/date in the binaries.

XXLQ5 against XWLPM shows huge diffs in recovery binaries.

4.0.3 branch:

XWLPG against XWLPI shows no diff in ko-modules despite the version/date in the binaries.

XWLPG against XWLPI shows no diff in in recovery binaries.

(all done using aZuZu Samsung Mobile zImage Splitter, v1.02.3h. and WinMerge 2.12.4.0 Unicode).

Lacking the 4.0.4 sources I can take that as a hint only what Sammy is working on ... maybe helps sb else :)
[Samsung Epic 4G Touch] Entropy512:
Most likely chain-resetting will be less likely to trigger the bug after the first wipe.

For a variety of reasons, factory reset is far less likely to trigger the bug. Stock recovery uses non-secure erase which is far less likely to cause issues than secure erase (to the point where Samsung believes non-secure erase is safe, but there have been enough reports of damage from stock recovery on other devices that I don't think it is.)

What I have seen is that it seems like the reports of damage in stock recovery spike when an update is first released for a device that has previously not seen any erase activity performed on its eMMC - such as when GT-N7000 ICS was first officially deployed, and again when I9100 XWLPM and XXLQ5 went live, which were the first releases for I9100 that attempted to erase partitions when a factory reset was performed (as opposed to a reformat without low-level MMC erase).

Right now my guesses as to why this happens are:

1) More people are likely to wipe in stock recovery with an official release - sample size is far greater

2) Once it is known here that a given kernel is capable of causing damage, people who read and post here avoid wiping on dangerous kernels, bringing the damage incidences way downwards. For example, even in the N7000 forums, there have been very few reports of damage over the past month because people know that wiping on a Samsung ICS kernel is just something you don't want to do unless you're willing to write off your device.

3) It may be that damage is more likely to occur when there is more work to be done in order to erase the partition. When a device first receives a dangerous update, existing devices in the field have many write cycles to the data partition (and in the case of flash-a-holics, also the system partition) without an erase. So if you're trying to maximize the chances of damage from stock recovery - between wipes, strain the wear leveler by doing many writes to the data partition. Does anyone know of any I/O benchmark that does repeated writes to a large portion of the data partition?
[Samsung Epic 4G Touch] garwynn:
Couldn't one just do a logcat dump to disk and let it keep going until it FCs due to out of space?

Or take a massive file - say, a movie - and copy in and out of /data?
[Samsung Epic 4G Touch] Entropy512:
Logcatting would just do one write cycle.

#!/system/bin/sh
rm /data/workimage.img
rm /data/tmpblk.img

n=$1
c=1
while [ 1=1 ]
do
dd if=/dev/urandom of=/data/workimage.img bs=1048576 count=$n
dd if=/dev/urandom of=/data/tmpblk.img bs=1048576 count=1
for j in 1 2 3 4 5
do

for i in 1 2 3 4 5 6 7 8 9 10
do
dd if=/data/tmpblk.img of=/data/workimage.img bs=1048576 seek=$((RANDOM%n))
sync
done

for i in 1 2 3 4 5 6 7 8 9 10
do
dd if=/dev/zero of=/data/workimage.img bs=1048576 count=1 seek=$((RANDOM%n))
sync
done

done

done

The above is a very ugly shell script that will write a bunch of random data, then start overwriting the file with more random data or zeros. When done with a few loops, it'll write more random data. Push to the device as diskbeater.sh, make executable, and run as follows

diskbeater.sh N

Where N is the size in megabytes of the file to work with.

Sorry for the horrific script. I should register isuckatshellscripting.com
[Samsung Epic 4G Touch] sfhub:
Are you sure stock recovery is using non-secure erase?

We don't get the userspace utils in the code drop from Samsung, so I can't be sure exactly what they are using for their libext4_utils.a, but the 4.0.3 wipe.c from Ken's group attempted to do a "SECDISCARD" first and if that failed tried a regular "DISCARD"

It is possible that code changed later on or Samsung is using different source.

http://code.metager.de/source/xref/android/4.0.3/system-extras/ext4_utils/wipe.c

int wipe_block_device(int fd, s64 len)
{
u64 range[2];
int ret;

range[0] = 0;
range[1] = len;
ret = ioctl(fd, BLKSECDISCARD, &range);
if (ret < 0) {
range[0] = 0;
range[1] = len;
ret = ioctl(fd, BLKDISCARD, &range);
if (ret < 0) {
warn("Discard failed\n");
return 1;
} else {
warn("Wipe via secure discard failed, used discard instead\n");
return 0;
}
}

return 0
}

The call trace for how stock recovery arrives at that function is here:

http://xdaforums.com/showthread.php?p=26685850#post26685850

The easiest way that we had to trigger the problem was to do a ROM install that did a format for an ext4 partition, followed by a wipe data/factory reset from recovery. Robertm was able to trigger it this way using stock kernel and the unlocked stock recovery that Samsung slipped to us (it doesn't enforce signatures) That scenario involves a format of the ext4 /system partition from the ROM install (which isn't something normally done by Samsung's OTA install), followed by the format of the ext4 /data & /cache partitions through the factory reset. (By "format" I'm implying SECDISCARD because both recovery and update-binary eventually reach the wipe.c function above when formating ext4 partitions)

Early on before we knew what was going on, we had many people triggering the superbrick with the same scenario, except they were using CWM Touch to do the factory reset. That is what led to our testing to prove stock recovery can cause the superbrick as well.

However for the purposes of forcing a superbrick using all stock, we haven't had a lot of testing for the easiest scenario to get the superbrick.
[Samsung Epic 4G Touch] Entropy512:
When I tested stock GT-N7000 XXLPY recovery using the instrumentation technique mentioned above (neuter mmc_erase() and printk() it) - I got the following results:

CWM 5.5 without BOARD_SUPPRESS_EMMC_WIPE - arg=0x80000000 (secure erase in the JEDEC standard)

Stock XXLPY recovery - arg=0x1 (non-secure trim in the JEDEC standard)
[Samsung Epic 4G Touch] Dubez:
Dont know if im posting in the right place, but i believe i hard bricked my phone. I did the cardinal idiot sin of battery pulling in the middle of flashing a rom. Now the phone has the BLOD. Is there anyone that can help me get my phone back? Thanks in advance...