yashsingh1/xdaforums huggingface dataset:
[Samsung Epic 4G Touch] Esoteric68:
About Phone (my info)

Android version

4.0.3

Baseband version

S: D710.10 S.FE10

Kernel version

3.0.15-SPH-D710.FE10-CL543980 se.infra@SEP-98 #3

Build number

RUJELUS22 The Blu Kuban FD24 1.0.3.2

Running Blu Kuban with FE10 kernel plus and FE10 modem

Flashed FE10 unlocked recovery

Rebooted

Using quickboot rebooted into recovery

Chose wipe date/factory reset

Data wipe complete

Rebooted

Phone back up and running, no problems to report yet

Added account to phone

Installed a few market apps

Rebooted into recovery

Chose wipe data/factory reset

Data wipe complete

Rebooted

Phone back up and running still no problems to report

Am I on the right path here or should I be pairing this with ROM installs as well?
[Samsung Epic 4G Touch] robertm2011:
I wouldn't do that, I believe that I've bricked doing that exact thing.
[Samsung Epic 4G Touch] blackroseMD1:
Damn. :(
[Samsung Epic 4G Touch] sfhub:
Ok, I think we should stop testing until we can figure this out.

Just to confirm "flashed wipe data/factory reset" meant choosing that option from the recovery menu, correct?

Any idea why GAPPs wasn't sticking the first time around?

Do you have a USB jig you can try to use to get into DL mode?
[Samsung Epic 4G Touch] Esoteric68:
Yes
[Samsung Epic 4G Touch] Mattix724:
This sounds to me like this is what caused the brick. What 4 files and how did you flash them using Odin?

You need to know what you are doing before you do it. Unfortunately at this point your friend better call Samsung for a warranty claim to have it repaired.
[Samsung Epic 4G Touch] ChromJ:
Thank you for replying

The 4 files rom I asked him to flash via odin is a stock rom for galaxy note. I must have flashed it doesn of times.

Prior to flashing the stock rom he recived a message in the galaxy note mentioning the word "nand" he did not state the complete message but I have a feeling that he bricked his phone prior to flashing the 4 files stock rom. He was stuck he could not enter the recovery mode but he was able to enter the download mode and his phone does not boot he must do something to make it boot. If a stock rom is not an exit from such problem then what would be an appropriate exit.

Eventhough the kernal he performed the wipe under has the emmc bug bypassed, the cm9 rom may contain a bypass to the bug fix.

My best regards

تم الإرسال من جهازي GT-N7000 بواسطة تاباتوك 2
[Samsung Epic 4G Touch] garwynn:
Cross Post: http://xdaforums.com/showpost.php?p=31114064&postcount=558

This is something we're going to want to keep an eye on to see if it makes it into our builds. If this

is

included it will - for most purposes - be the permanent fix to this issue.
[Samsung Epic 4G Touch] hakaz:
... and if I read the https://lkml.org/lkml/2012/8/17/54 code correctly apparently we have a complete list of endangered eMMC chip versions:

+	/*
+	* Some issue about secure erase/secure trim for Samsung MoviNAND
+	*/
+	MMC_FIXUP("[COLOR="Red"]M8G2FA[/COLOR]", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc,
+	MMC_QUIRK_SEC_ERASE_TRIM_BROKEN),
+	MMC_FIXUP("[COLOR="Red"]MAG4FA[/COLOR]", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc,
+	MMC_QUIRK_SEC_ERASE_TRIM_BROKEN),
+	MMC_FIXUP("[COLOR="Red"]MBG8FA[/COLOR]", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc,
+	MMC_QUIRK_SEC_ERASE_TRIM_BROKEN),
+	MMC_FIXUP("[COLOR="Red"]MCGAFA[/COLOR]", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc,
+	MMC_QUIRK_SEC_ERASE_TRIM_BROKEN),
+	MMC_FIXUP("[COLOR="Red"]VAL00M[/COLOR]", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc,
+	MMC_QUIRK_SEC_ERASE_TRIM_BROKEN),
+	MMC_FIXUP("[COLOR="Red"]VYL00M[/COLOR]", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc,
+	MMC_QUIRK_SEC_ERASE_TRIM_BROKEN),
+	MMC_FIXUP("[COLOR="Red"]KYL00M[/COLOR]", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc,
+	MMC_QUIRK_SEC_ERASE_TRIM_BROKEN),
+	MMC_FIXUP("[COLOR="Red"]VZL00M[/COLOR]", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc,
+	MMC_QUIRK_SEC_ERASE_TRIM_BROKEN),
+
END_FIXUP

So the VIS00M version they started distributing since 02/2012 (e.g. on replacement boards) seems to be safe in their eyes. Cheers.
[Samsung Epic 4G Touch] garwynn:
Also would seem that they're doing this regardless of revision. Not sure why though, GNex and AT&T Skyrocket should be safe according to Mr. Sumrall. Maybe they just thought it was better to outright disable it for the entire line? :confused:
[Samsung Epic 4G Touch] hakaz:
Imho they don't trust any 2011 chip version to a certain degree ...
[Samsung Epic 4G Touch] Entropy512:
There was some discussion on this - since some chips had revisions that were "unknown" it would have made the code very unwieldy and possibly risky. From that category of chips, the number of "known good" units (mainly VYL00M fwrev 0x25) was pretty small, and the negative effect this might have on those units is quite small - I need to ask for some clarification on this from my contact, but it sounds like nonsecure erase in these chips does have SOME of the benefits of secure erase, but without the risks. I'm not exactly sure of this though - however for 99% of users, nonsecure erase is fine. The people who would want what functional secure erase (ensuring EVERY copy of data is gone so that someone can't probe the chip and get information from discarded memory cells) has to offer are going to just physically destroy the chip anyway.

My main worry is that it will be next to impossible to check for the presence of this patch in a binary kernel - except POSSIBLY doing "strings" on the kernel to look for all of those chip IDs.
[Samsung Epic 4G Touch] garwynn:
Thanks for responding - know you're usually busy and this sometimes falls to the wayside.

While it does err on the side of caution and I'm glad to see Sammy finally take a more proactive stance on this, expanding the range to include any revision includes devices far beyond the original scope that we started looking at - the Note and GSII - to not only the entire Galaxy 2011 lineup but also Samsung's "lower end" devices such as the reworks of the Galaxy S. I recall also RainMotorsports saying that some of these eMMCs were on midlevel devices.

While Mr. Chen is proposing this to the Linux kernel has anyone submitted the change already to Google for AOSP inclusion? Getting both of these incorporated as soon as possible should help stem the tide on all devices, at least those using the common kernel source from either Linux or Android.

You're right to worry about that and that will be my next suggestion. We can check source and make sure people know that it's out. But for all those devices that may not know they're on the list there really needs to be a way to get the word out.

Could you ask your contact if they would be okay with sharing that fix beyond their current efforts? May just be easier to have XDA put a link to this on their front page and tell devs with affected eMMC models to modify any ICS kernel source as described in the fix. That ought to put them ahead of the game should it be incorporated into open source. Also would recommend reaching out to Chainfire to have him modify the Got Brickbug app to reflect the proposed fix - that's about as official of a list as we're going to probably see anytime soon and updating that app is one of the easiest ways to get attention to it.
[Samsung Epic 4G Touch] hakaz:
Chainfire already incorporated the chip versions of the proposed fix in his Got Brickbug app mentioning the additional versions as "probably bad" so the code is half-way prepared for a possible string checking as proposed by Entropy512.

Entropy512: If possible could you ask your contact what's about the VIS00M chip line? For Chainfire these chips are "unknown" of cause but the weren't added to the fix proposal too. Are the really assumed safe by Sammy? Thx alot and cheers.
[Samsung Epic 4G Touch] Entropy512:
I do have the fix in patch form. I'm a bit paranoid about actually implementing it on anything I've released so far - removal MMC_CAP_ERASE is proven safe. Their fix is (according to them) perfectly safe but I don't think we'll know for sure until it actually starts getting deployed. I don't think we'll be able to establish for certain whether Samsung is correct about nonsecure erase being OK until Samsung kernels with this fix come out and the bricks stop completely.

I'll ask her about VIS00M when I have the time - probably next week. Busy packing for a camping trip in my evenings.
[Samsung Epic 4G Touch] Mattix724:
My new Epic 4G Touch that I just received from Samsung has a MAG2GA eMMC chip revision 0xE.

From what it looks like this was a brand new E4GT. If there is anything else I can help with just let me know.
[Samsung Epic 4G Touch] hakaz:
So up to now we have 2 eMMC chip versions not on the patch list:

VIS00M found on GT-I9100 (int'l)

MAG2GA found on E4GT, GT-P6800

Maybe someone with a new N7000 can state its chip version too ... cheers.
[Samsung Epic 4G Touch] Mattix724:
Here's a screenshot from the brick bug app.
[Samsung Epic 4G Touch] aletheus:
i have a gTab 7.7 (p6800) that's affected. here's my info per OP:

MAG4FA

0x19

0x000015

0x0100

01/2012

MMC

0xf6f01107

1501004d414734464119f6f011071f5b
[Samsung Epic 4G Touch] Azon:
Got a Galaxy Tab 7.7 with eMMC chip version MAG2GA.
[Samsung Epic 4G Touch] Mattix724:
So does that mean the MAG2GA is the newest eMMC chip?
[Samsung Epic 4G Touch] garwynn:
Bump.

And MAG2GA appears to have the newer f/w revision that avoids the bug from what I've heard.
[Samsung Epic 4G Touch] Mattix724:
Sweet. That's less that I have to worry about...

If for any reason I brick... I'll post here.
[Samsung Epic 4G Touch] jayharper08:
Thread has been stickied due to Garwynn bringing to my attention exactly how important this thread is. :)

---Jay--- Mobile Moderating from the Nexus™
[Samsung Epic 4G Touch] PhAkEer:
I know placebo has a lot of lurkers.. I'll post a link to this and 'how to not ...'

Its refreshing to see how much you guys care about us little people. I know I'm not the only one thankful for it...

thanks guys.

Add: Also, don't know if it does anything, as Ive never clicked it before now... but ... " News worthy thread " ?? Ci??
[Samsung Epic 4G Touch] garwynn:
..meaning that Sammy is mentioning this thread when they proposed the kernel fix. Great job everyone and thanks for the sticky!!
[Samsung Epic 4G Touch] Entropy512:
This thread has already been on the portal news. :)

Yeah, it was a good idea to sticky it... It used to stay on top due to activity, but I expect activity to die down now that the situation has become clear... I don't expect there to be any significant new developments in this area other than Samsung's patch appearing on devices where it actually matters. It was deployed in the I9300 JB update, but we all know that device doesn't have defective eMMC to begin with.
[Samsung Epic 4G Touch] shoey63:
Isn't samsungs idea of a "patch", just to make format/erase commands "non-secure"? That's no different to what happens when wiping on stock kernel?! Please correct me if I'm wrong.
[Samsung Epic 4G Touch] pdub42:
is there a fix for the bricked phones? I have been searching for hours but all I can find is stuff to prevent bricking, not to recover, or is it not possible to recover from this?
[Samsung Epic 4G Touch] garwynn:
In essence, yes. For most of us it won't make a difference as devs have disabled the secure erase/trim regardless of eMMC model. The fix from Sammy targets the specific eMMCs affected so that it will become a permanent addition to Android - meaning that new dev efforts from source won't have to worry about it

once the code has been added.

(As Entropy mentioned only one model is verified to have the fix already. Hoping the new ICS build or JB will have it for the Epic 4G Touch)

Link to Fix (last known version):

https://patchwork.kernel.org/patch/1329761/

---------- Post added at 09:19 AM ---------- Previous post was at 09:17 AM ----------

Regrettably there is not and will likely never be a solution that will recover the missing space if you've already triggered the bug. I'll continue to suggest that folks replace when possible (and economically feasible) and refer to hg42's modified .PIT files for ways to bypass the trigger space when not.
[Samsung Epic 4G Touch] Entropy512:
Yes, and so far Samsung maintains that wiping with stock kernel+recovery is safe.

While we have seen claimed reports of it being not safe, we haven't been able to provide Samsung with hard evidence. Part of the problem is that numerous people considered CWM fakeflashes from stock recovery to be wiping from stock recovery - it isn't, that's wiping with CWM.

I don't think we'll know for sure until builds with the patch drop - however the problem is, alternate solutions are now so widely distributed that it doesn't really matter. People have gotten to be really good at NOT repacking CWM with secure erase into stock kernels, NOT releasing firmware packages with known dangerous update-binaries (there are exceptions, such as Westcrip's I9100 Resurrection Remix, which STILL contains a dangerous update-binary more than a month after being contacted both via PM and via a post in his thread that he had known dangerous components.)
[Samsung Epic 4G Touch] aletheus:
I had a SGT 7.7 that fell to the superbrick... got a SGN 10.1 monday, and at least on this unit the MAG2GA chip is sane.
[Samsung Epic 4G Touch] appagom:
safe wipe

So there are plenty of workarounds for this, but my solution for an SHW-M250K, with a stock kernel (which may or may not be a problem anyway) and ROM with SuperSU installed (won't work with SuperUser which can't grant adb root in recovery as far as I know) and busybox is to boot into recovery mode and do this when I need to wipe:

adb shell /system/xbin/su -c "mount -t ext4 /dev/block/mmcblk0p7 /cache"
adb shell /system/xbin/su -c "mount -t ext4 /dev/block/mmcblk0p10 /data"
adb shell /system/xbin/su -c "busybox find /cache -mindepth 1 -exec busybox rm -rf '{}' \;"
adb shell /system/xbin/su -c "busybox find /data -mindepth 1 -exec busybox rm -rf '{}' \;"
adb reboot

Obviously the mount commands will be different for different devices and this only makes sense if you have a stock kernel and rooted through other means. Formatting (with the tools installed) should work too and would be better if one has fs corruption to fix. dd'ing the whole partition would probably work too since I believe most stock kernels will reformat them on startup (but I'm not ten thousand percent sure that's done safely, I think it's just and fs format though which from my understanding is safe). In my case I just rooted by unpacking the ROM and added su to it before flashing it (seems like the most obvious way to me to put a file in /system/bin and as a bonus it doesn't increment the custom flash counter).

This kind of thing is probably obvious enough to serious devs and maybe useless to one-click style users, but maybe it gives ideas to people having skills but little or no android hacking experience. I originaly came here that way (haven't changed THAT much) and was pretty bafffled by all the one-click stuff to do the same things and lack of simple guides on things like how to just $#%!ing get a ROM from kies and copy su into it before flashing it!
[Samsung Epic 4G Touch] appagom:
or to just wipe the dalvik-cache, this should work, again in recovery mode with adb root (haven't tested it exactly cut and paste yet but it's basically what I did by hand)

adb shell /system/xbin/su -c "mount -t ext4 /dev/block/mmcblk0p10 /data"
adb shell /system/xbin/su -c "busybox find /data/dalvik-cache -mindepth 1 -exec busybox rm -rf '{}' \;"
adb reboot
[Samsung Epic 4G Touch] garwynn:
Boost FI22 Source Check Results

Note on Boost FI22 source - eMMC fixup by Samsung to disable secure erase/trim

still not in source. Kernel is at risk.

I'm attaching the source below for /include/linux/mmc and drivers/mmc here:

View attachment FI22_eMMC_Source.zip

Devs, please continue to make safe using current methods or adding Samsung's code changes as listed here:

[v4] mmc: card: Skip secure option for MoviNAND. - Patchwork

If further source drops occur I'll post the results here.
[Samsung Epic 4G Touch] shoey63:
I'm not too sure about Epic 4g touch but on the GSII and Note forums there has been a spate of "Temp" CWM.zips which appear to have been patched with

BOARD_SUPPRESS_EMMC_WIPE. This is evidenced by running "strings recovery |grep" on the extracted recovery file which produces the following message:-

warning: %s: Wipe via secure discard suppressed due to bug in EMMC firmware

So it has to be assumed such recoveries are SAFE. But how safe? Obviously safe to do factory resets/wipes when flashed on a kernel which doesn't have eMMC_CAP_ERASE disabled, but what about flashing "zip" files which contain "format" commands, coupled with an Update-binary which hasn't been patched? Will the format command be suppressed by the recovery or will it be allowed to go thru to the unsafe kernel as "secure erase". (and we all know the consequences of that!) I would appreciate some feedback on the matter. Thank you.
[Samsung Epic 4G Touch] Phil3759:
+1

One evidence for that is CF-root kernels with patched recovery by Chainfire but still vulnerable to bricks with format commands it seems...
[Samsung Epic 4G Touch] Entropy512:
Safe for wiping/factory resets/manual formats, but not for flashing ZIPs. However, you can verify the safety of a ZIP by checking the update-binary in the same way.
[Samsung Epic 4G Touch] PhAkEer:
Obviously one flashaholics input is irrelevant to the big picture, but before Ecap was identified and avoided I used format from stock unsecured kernels all day everyday every time I had an issue or flashed a rom because I used preload-installer.apk/mmcblk0p12 as my own personal titanium.

when it became a little more clear what the issue was I ( of course it wasn't singled out to format yet.....) continued to be reckless and I don't think it was coincidence that I met Ecap while wiping with rogue recovery and not stock...

I've always felt safe wiping via settings menu when on stock kernels and continued to do so.

(Just a story from a guy that doesn't matter... DO NOT put your phone at risk because I am lucky and stupid)
[Samsung Epic 4G Touch] garwynn:
FI27 source dropped for Sprint. Downloading and will update post but likely not safe.
[Samsung Epic 4G Touch] Entropy512:
Looking forward to the results... I'm beginning to feel like my meeting was a PR stunt to defuse the situation. Nothing has actually come out of it in the end - it's early-mid October and not a single affected device has received an update with the fix.

It's silly - they ARE deploying the fix to some devices, such as the I9300 - BUT THESE DEVICES DON'T HAVE DEFECTIVE eMMC IN THE FIRST PLACE!!!!!
[Samsung Epic 4G Touch] garwynn:
But was the i9300 confirmed to have the fix an international or US variant? Just curious if TX R&D even got the message...
[Samsung Epic 4G Touch] Entropy512:
I9300 is the international version.

I don't know the status of d2 devices (Qualcomm-based USA SGS3 units)... I'll try to spot-check one of em' tonight.

Any news on whether that patch is in the latest Sprint sources?
[Samsung Epic 4G Touch] garwynn:
Hot off the press...

Sprint FI27 (9/27/2012) Results - Samsung fix

not

included. Kernel is unsafe.

Attaching code for reference:

View attachment 1388075

Devs should continue to render safe using existing methods or implementing changes as posted here:

[v4] mmc: card: Skip secure option for MoviNAND. - Patchwork

Honestly I'm very disappointed to say the very least.

I'll pull LI3 source for Sprint GS3 and advise.
[Samsung Epic 4G Touch] PhAkEer:
Almost enough to transition from disappointment to anger..

Any thoughts on why or what theyre afraid of? I suppose it doesn't matter... I'm just stubborn and never satisfied with not-knowing...
[Samsung Epic 4G Touch] garwynn:
Until I see it in a source from US it's hard to prove that Korea has passed the code fix information down to the regional developers.

Since it was in the i9300 source I'm going to take a peek at the Sprint GS3 release LI3 and see if it's in there.

The other possibility is that they're addressing it in the JB kernel and not ICS.... but I'd find that odd at best.
[Samsung Epic 4G Touch] Entropy512:
This was on LKML and is being merged to mainline... In addition, no international device that is affected by the flaw has received an update either.

I'm beginning to think that my meeting was just a PR damage control sham. Absolutely nothing has actually come out of it in the end.

We discussed ways to improve developer relations and communications channels so that something like this could be caught sooner - completely shot down by management.

We discussed ways to protect devices in the future - I seriously thought they were going to deploy something and protect users, but they haven't. It's clear they just don't care.

please please PLEASE let the Xperia TL on AT&T have an unlockable bootloader like the international T does.
[Samsung Epic 4G Touch] garwynn:
SPH-L710 (Sprint GS3 Variant) has same source as FI22 (Boost GS2) and FI27 (Sprint GS2).

Really makes me wonder if Korea pushed this down to the regions yet....
[Samsung Epic 4G Touch] aletheus:
They already have our money, and in the US, they have no warranty obligation to us (for the GT-P68XX). Corporations are all the same. Anything that cuts into profits is out of the question.....

GT-P6800--superbricked

GT-N8013--daily driver
[Samsung Epic 4G Touch] BluesRulez:
http://xdaforums.com/showthread.php?p=32620022

Agat says the emmc cap erase command was removed/disabled.
[Samsung Epic 4G Touch] garwynn:
Isn't sdhci the driver used for the emmc and not mshci?
[Samsung Epic 4G Touch] agat63:
I did search for CAP_ERASE in FI27 source and couldn't find it.

Where did you find it or you talking about something else?

I did post FI27 source build kernel this morning and I would love to know where and How I can fix it.

If I can fix it.

---------- Post added at 08:29 AM ---------- Previous post was at 08:26 AM ----------

Thanks will remove it tonight.

But I did run

grep -irn cap_erase ./

in kernel directory. Line returned empty.

Did run it twice. :eek:
[Samsung Epic 4G Touch] garwynn:
Guess you saw the other post. Thanks for following up on this quickly.

(Found in line 1881 on mshci.c)
[Samsung Epic 4G Touch] Entropy512:
mshci is it...

So wait... MMC_CAP_ERASE was removed??? Samsung made it pretty clear that this was not their solution, that it not being present in I9100 sources was a "mistake", and that they would NOT be using that solution in any other devices.

I'll download it to look at it tonight...
[Samsung Epic 4G Touch] garwynn:
You can download the .ZIP in my FI27 analysis, it's still there in line 1881.

We think it may have been removed by another step in Agat's process and then was misunderstood as removed by Samsung.

Kernel source unmodified is still unsafe.
[Samsung Epic 4G Touch] Entropy512:
Ah... That makes sense... I think some kernel developers have gotten to the point where they instinctively remove that "on autopilot" the moment they get a new drop...
[Samsung Epic 4G Touch] shoey63:
Yes I have confirmed this by way of practical testing on PhilZ Temp Recovery:cool: Did factory reset, manually formatted /system and did Nandroid restore from old backup. All operations completed in a breeze! (Took a leap of faith and a couple of beers first tho). This is very good news for those who wish to stay on stock, virgin ICS, but just want a safe way to do factory reset :good: (As long as they don't get too excited and try flashing ZIPs with format commands in updater-script + unpatched update-binary)
[Samsung Epic 4G Touch] MattMatt0240:
So, sorry ahead of time for being so noobish with Samsung devices, but is it safe to switch between ics and jb?(NAND restore)

From my understanding, the real danger is between ics and gingerbread correct? Mainly from ics to gingerbread.

Thanks ahead of time
[Samsung Epic 4G Touch] shoey63:
Noob questions should probably be posted in Q&A but if u are on safe kernel u can do whatever u like.
[Samsung Epic 4G Touch] Entropy512:
No, that is not correct. Not even remotely... Please spend some time reading before you brick your device.