yashsingh1/xdaforums huggingface dataset:
[Samsung Epic 4G Touch] sfhub:
Just keep in mind the CM9 and AOKP public versions that were posted can still potentially brick your phone. Darchstar and T.C.P have mentioned they will make the necessary change next release.

For now, ONLY flash the BRICKFIX versions in the Test Plan post if you want to try flash CM9/AOKP in ICS Recovery.
[Samsung Epic 4G Touch] krazy_smokezalot:
Downloading now!.....

Sent from my PaRAnO!D aNDr0id! o.O
[Samsung Epic 4G Touch] krazy_smokezalot:
Hey sfhub or Esoteric68 for steps (1c) & (2c) do I just flash 'CM9a5 BRICKFIXv1' without wiping right just want to double check b4 I perform this.... other than that I understand the instructions CLEARLY.

Edit: works for me and my changes from 4e are present on cm9 and AOKP. Looks like you may have got something here sfhub:D:thumbup:

Sent from my PaRAnO!D aNDr0id! o.O
[Samsung Epic 4G Touch] Esoteric68:
Sorry I didn't respond earlier but I was asleep lol glad it went well and appreciate you running the test. :D
[Samsung Epic 4G Touch] sfhub:
Yes, just want to get 2 straight flashes before doing a wipe. Nothing bad would happen if you didn't follow those steps and did a wipe, it is just a choice for what to test.

Glad it worked for you.
[Samsung Epic 4G Touch] aquaholik:
A donate button for sfhub will allow him to take MANY for the team :). Congrats on the fix!
[Samsung Epic 4G Touch] sfhub:
I would just like to stress that the *core* EMMC firmware lockup/superbrick bug is still there and unless that is fixed folks will ALWAYS be exposed to it to some extent.

What we are doing is eliminating the common paths by which someone might hit the bug, hopefully to the point most people don't notice it.

We are NOT 100% fixing the problem (ie so that nobody will ever see it again)

People can flash older kernel/recoveries, fake flash CWM Touch, older ROMs, etc. and still superbrick.
[Samsung Epic 4G Touch] garwynn:
Action Summary

Just to add on to sfhub's comment - At this point the goal should be trying to minimize the risk as much as possible as it will be statistically impossible to avoid eradicate the bug, even if we did get the eMMC controller patch.

Efforts so far have been great to this part:

1) Patch the stock components - OSRC is reviewing now and based on the update I'm cautiously optimistic that they'll fix the kernel. Certainly confirmation on this one is pending source; hopefully the code delay is giving them time to look at this and possibly add a kernel level fix prior to release.

2) Patch the most common and popular downloads - in progress thanks in great part to sfhub's efforts but also those of the E4GT dev community as well. The more that the popular/common downloads - particularly new builds as we go forward - are patched, the less we should hopefully see this.

Unresolved issues still remain though:

1) We still have nothing to deal with this after the lockup occurs. I'm still trying to check both with Mr. Sumrall and Samsung's semiconductor division to see if we might get something. Fortunately this should not be necessary as much once the above two actions greatly minimize the risk and most people who do brick can replace their phone by TEP/Asurion.

2) Scope beyond GS2 and Note: We've seen other eMMC PRVs, other devices that use these and it still isn't known if this could happen on other eMMCs made by Samsung - recently Entropy512 suspects the Kindle Fire may have a similar issue. Honestly don't know if this will ever get answered - it is part of my question to Samsung Semiconductor - but only time will tell.

I will suggest that once #1 and #2 are resolved that the first few posts by sfhub be updated with core information and that the thread be locked and stickied - perhaps even on the Development Forum as this will really be useful over there once this is mainly resolved.
[Samsung Epic 4G Touch] krazy_smokezalot:
No worries man I should have been asleep as I have had no sleep while attempting this! Not a very bright Idea :D

Sent from my PaRAnO!D aNDr0id! o.O
[Samsung Epic 4G Touch] sfhub:
That's when we brick most often so you were just simulating real-world conditions. :)

Perhaps I should add no sleep as a prerequisite in the test plan? :)
[Samsung Epic 4G Touch] okantomi:
Lol, but seriously, that is so true. When I'm tired I make mistakes more often than not.
[Samsung Epic 4G Touch] krazy_smokezalot:
lol yes that also and add not to be under the influence of any drug or alcohol lol:D

but i was VERY careful wen i did this with some starbucks coffee :D

---------- Post added at 03:25 PM ---------- Previous post was at 03:24 PM ----------

im wondering if kbizzel is still going to attempt this that would be cool also....
[Samsung Epic 4G Touch] sfhub:
He mentioned needing to go off to work but would try checking in tomorrow to test.
[Samsung Epic 4G Touch] jgaviota:
garwynn, please ask Samsung if they could release the errata for the 0x19 emmc firmware. That would allow us to really understand the exact conditions needed to trigger the bug. Right now we are basing everything on a secondhand description of the bug. I'd like the official description :-)
[Samsung Epic 4G Touch] krazy_smokezalot:
This guy!!! Lol Yeah ask Samsung if they can release ice official ota before the 11th. Hopefully they will listen!:rolleyes::p but hell who knows they might just listen ;)

Sent from my PaRAnO!D aNDr0id! o.O
[Samsung Epic 4G Touch] krazy_smokezalot:
I feel super lucky I'm gonna perform this test AGAIN for the hell of it lol:D

Edit: I just did another round of testing and everything went smooth like butter!!!

Sent from my PaRAnO!D aNDr0id! o.O
[Samsung Epic 4G Touch] garwynn:
While I fired off an inquiry to Samsung Semiconductor it's going to largely depend on how far they'll be willing to share. I haven't thought about how this would work yet but I'd bet that getting into the guts of the eMMC will probably require an NDA from anyone who wants to be involved. Great for possibly solving the problem but not sure how that's going to help the community unless we're able to share the results of the discussion/research.

And honestly I don't know if the Mobile division would have all of this - they would probably go back to the source just we're doing.

---------- Post added at 10:54 PM ---------- Previous post was at 10:51 PM ----------

First off, Samsung has a part of this but I think it largely falls onto Sprint now.

FF02 thread has an update on this situation that suggest there is movement towards the OTA release. Will suggest jumping over there to read what's up.
[Samsung Epic 4G Touch] krazy_smokezalot:
Dude I know they said "One is to share the information that open source developers can use to fix the problem."

Lol I was being sarcastic. Take it how ever you want!

Sent from my PaRAnO!D aNDr0id! o.O
[Samsung Epic 4G Touch] sfhub:
What is the old saying:

"Courage is not the absence of fear but the action in the face of fear"

You've just made it

"Courage is feeling super lucky"
[Samsung Epic 4G Touch] davidstjohn1:
So its looking like were SOL! Unless Samsung gives us a fix. So one question i have is if i stay on a gingerbread rom is there still a chance of a superbrick? Also if i choose to use a ICS rom and just follow the instructions using only odin am I safe? Sorry for noobish questions I came from the evo and it was just plain simple on that phone.
[Samsung Epic 4G Touch] sniper:
We're not really SOL. We've already come very far from where we've started, and as long as you just read directions you can completely avoid bricking. Yes, the problem is still technically there, but we know how to avoid it now for the most part.
[Samsung Epic 4G Touch] davidstjohn1:
so my following the instructions carefully and using odin I should not break at all right? I already odined ics once. and went back to gingerbread very easily el29 (odined) it just sucks because the gingerbread rom there's not many.
[Samsung Epic 4G Touch] sfhub:
ODIN itself is safe, but if you get stuck on data.img or factoryfs.img, that means you hit the EMMC firmware bug prior to using ODIN.

GB-based kernel/ROM is mostly immune to the problem because the calls into the kernel that would trigger the bug were disabled in the kernel MMC driver.

ICS can be relatively safe if you follow guidelines/instructions and are disciplined.
[Samsung Epic 4G Touch] rajendra82:
I have the I717 AT&T Note, and we have a testing thread going in our general forums. All of the I717's return fwrev 0x25. The good news is that I will not be subject to a superbrick. Is the March 2012 patch for the 32KB of zeroes already implemented in the leaked kernel UCLE2, with a build date of May 8, 2012? If so we are totally in the clear.
[Samsung Epic 4G Touch] garwynn:
Not sure but the 32KB of zeros is not a dealbreaker IMO. At worst a format of the eMMC shoul clear it up and that is only if it borks a superblock's metadata.
[Samsung Epic 4G Touch] NOMIOMI:
IS SEYAH kernal is safe to flash on sgs2???/
[Samsung Epic 4G Touch] chrismalla:
Yes, Siyah kernel is safe.
[Samsung Epic 4G Touch] MartinEve:
Edit: never mind!
[Samsung Epic 4G Touch] citytrader:
Are this kernels for sgs2 safe!?

- Stock Kernel

- Speedmod

Thanks!
[Samsung Epic 4G Touch] sfhub:
I don't know any specifics about the kernels on other platforms other than what I've read posted here by others (so take this with a grain of salt), but IIRC there was one version that wasn't safe, but that got pulled, and all the current ones you could download are safe. It is possible I'm confusing this with another kernel though.
[Samsung Epic 4G Touch] dexter35803:
Using SFHub's test process and verification via Chainfire's application that i have the vulnerable emmc firmware i have successfully flashed with the NOBrick Fix kernels on my device 3 times for CM9A5 and AOKP Build 37

4 flashes CM9 BRICKFIXv1

3 flashes AOKP BRICKFIXv1

6 wipe data/factory resets

3 nandroid restores

2 stock FF02 flash
[Samsung Epic 4G Touch] sfhub:
Thank you very much for running through the test plan.
[Samsung Epic 4G Touch] sfhub:
6/8 Update for other platforms waiting for fix

Codeworkx's contact with Samsung got following response [discussion]
[Samsung Epic 4G Touch] hawkerpaul:
Can someone veriify, is this potential brick a problem with the existing kernel that you flash onto, or with the new kernel you are flashing? Or a combination of the two?

Is it only triggered by a kernel flash, and is it CWM-Recovery flash related?
[Samsung Epic 4G Touch] sfhub:
The core bug is in the EMMC firmware so you are always technically exposed.

GB kernels (for our phone) have the call to the EMMC firmware essentially disabled, so any recoveries that use GB kernel are safe.

Now if you use an ICS kernel, those that have been leaked so far (except possibly for FF02, but that has not been verified) do NOT have the call to the EMMC firmware disabled, thus you want to minimize your exposure to the bug by making sure the ways you might trigger it yourself do not get run.

The brick points we have seen with the ICS kernel are as follows:

Recovery

a) Wipe data/factory reset

b) Nandroid restore (nandroid backups are always safe)

If you use a "safe" recovery that is compiled against GB libraries (see agat's FF02 repack) then those 2 operations are safe. It is likely other Recoveries like Rogue are also safe, but it hasn't been verified, so I would stick with what has been verified and tested.

ROM install

When you install a ROM, Recovery uses a "helper app" contained in the ROM's update.zip. This helper app is called update-binary.

Even if you have a "safe" Recovery, if you install a ROM with an "unsafe" update-binary, and the install script for that ROM does a format(), you can brick. This combination exists with current CM9/AOKP ROM installs.

The ways to avoid this would be for the *ROM packager* to use a "safe" update-binary (ie one compiled against GB libraries) or for them to make sure they don't do a format() in their install scripts.

As to your question, ROM installs often install their own kernel/zImage. This means you get whichever Recovery was bundled in with the kernel you installed. If you started with a "safe" Recovery, then flash a new ROM (which included a safe update-binary) then you would no longer be running the Recovery you started with. You would be running the kernel/zImage//Recovery which the ROM installed. That may or may not be "safe". You would need to verify.

It is early on in the process. Eventually things will get smoother.
[Samsung Epic 4G Touch] cp320703:
Sfhub I will run through your test process later tonight if I have the energy or tomorrow morning and post my results, haven't read this thread for a week or two and you guys have made some FANTASTIC progress

edit: Used chainfire's app to confirm that my phone is susceptible to bricking, it was, oh joy!... followed sfhub's testing protocol to the letter... literally printed out his post and crossed things out as I did them, who needs sleep when you have adequate preparation!.. without issue (other than an accidental desk-nap leading to a late night coffee run to dunkin donuts) for both CM9 and AOKP... so either we've all been lucky or you've come up with a very good kludge to prevent the problem! thanks for all the hard work guys! Should you need any further tests run or any other information please do not hesitate to ask... although I am a bit tired of flashing things for the time being!
[Samsung Epic 4G Touch] andz92:
how about speedmod ,franco and abyss kernel?

is it safe?
[Samsung Epic 4G Touch] Entropy512:
There's no way to know if you have the patch for the 32kb of zeros patch without source - but as stated below, this bug is VERY minor compared to the bug in fwrev 0x19. If you get hit with it, you just reformat/wipe and all is good.

Yeah. That 32kb bug is an annoyance but not a major defect.

None of those are valid kernels for SPH-D710. You need to keep in mind that while much of this thread content applies to multiple devices, it is primarily an SPH-D710 thread. If you don't have an SPH-D710, you MUST state which device you are using.

Also, this is not an appopriate thread for asking which kernels are safe and which are not for any non-Sprint device. Developers in the forums for affected devices have been informed of the situation, and there are summaries of safe/dangerous kernels for affected devices in various places. If you're an N7000 user as I suspect you are - why don't you try reading the original posts for the kernels you're asking about OR the stickies all over your forum OR my post listing known safe/dangerous kernels for multiple devices in the Got Brickbug? app thread, which is linked to from the first post of that thread.
[Samsung Epic 4G Touch] mrcasmir:
Pls guys, when this fix comes out, will it fix already bricked phones or will it just protect others from super bricking?
[Samsung Epic 4G Touch] PoisonWolf:
The latter.
[Samsung Epic 4G Touch] sfhub:
If you have a bricked phone, your best bet is to return it. If you can't do that, you can try a use a custom .pit file to map around the problem area.
[Samsung Epic 4G Touch] mrcasmir:
Ok, I have decided to return the phone

I have done these

Reset flash counter with Triangle away

I will set it back to original partition mapping

flash a stock ROM

but my problem is whenever I go into recovery mode, I get

# MANUAL MODE #

-- Applying Multi-CSC...

Applied the CSC-code : XME

Successfully applied multi-CSC

Does anyone know how to get rid of that and is there any other thing that I need to do just to get rid of any traces that might be left?
[Samsung Epic 4G Touch] sfhub:
It has always done that for every stock ICS leak we have had on E4GT. The only ways to not see it are to use a GB recovery (and ROM if you want it to boot) or use custom recovery, but if you are returning it, GB recovery is probably the best if ICS was a leak for your device. If ICS was official, just leave it there.
[Samsung Epic 4G Touch] Entropy512:
Right now - I think we'll be receiving protection measures only, not repair measures.

We're trying to convince Samsung to release the information required to execute repair operations on damaged devices.
[Samsung Epic 4G Touch] topprospect:
If it helps anyone else out there, I was able to get CM9 running on my eMMC corrupted Skyrocket using tmpfs for /cache and image files on external SD for /data and /tombstones.

It runs fine, although a bit sluggish at times.

http://xdaforums.com/showthread.php?p=27267823
[Samsung Epic 4G Touch] Esoteric68:
It makes me wonder why they wouldn't be all over this. I mean this is a possible solution to a potential PR nightmare.
[Samsung Epic 4G Touch] garwynn:
Honestly? My guess is risk based. Will type more when get home on this.
[Samsung Epic 4G Touch] Entropy512:
In the case of recovery mechanisms:

1) I believe it involves what Samsung Semiconductor considers proprietary information. Samsung has historically been VERY bad about releasing any information they absolutely don't have to. I think it's even worse when you cross business unit boundaries.

2) It's fairly high risk since it involves completely wiping the chip and reflashing bootloaders. That said - devices damaged by this bug are pretty much toast anyway, it's hard to make it worse.

There's also the issue of dealing with the EFS partition - if that has been damaged it probably has to go back to Samsung no matter what, however I hope that with this new repair info, they can offer a less expensive repair methodology than motherboard replacement.
[Samsung Epic 4G Touch] sfhub:
My guess as to their thinking is if they did release a fix they would just give it to the repair centers and expect people to make warranty claims. The danger for them would likely increase if they released an EMMC firmware patch because many people with working units would probably start installing the patch so they could be immune to these issues and some of small percentage of those are going to brick.

Big companies like to use existing mechanisms to handle issues, so if something can already be handled, they are very hesitant to introduce new mechanisms.

Who knows what would happen to such a fix after it reached a repair center, it might just leak :)
[Samsung Epic 4G Touch] jgaviota:
Also, Google patched 0x25 on the fly to prevent the other bug, maybe Samsung can do the same. If they go this way maybe (and this is pure speculation) they will do the fix in new bootloaders and we will be none the wiser.

In the Galaxy S era there were some batches that had faulty 3 button combos, they fixed that and some graphics initialization on the ICS bootloaders.

What would that mean? Well they would have to get bootloaders out for all affected devices and we wouldn't see a change in source code, also they most probably would not admit to the bug.
[Samsung Epic 4G Touch] mobilevil:
I fear that they are removing calls to erase command only
[Samsung Epic 4G Touch] jgaviota:
I think there is nothing to fear in that.
[Samsung Epic 4G Touch] garwynn:
Well, part of the wait may be over. T989 source dropped this morning - pulling now to see if we can get a better handle on if and how this was actually patched. This is assuming, of course, that it was patched the same as the E4GT... I have been told it was but it will be hard to confirm until we can compare source side-by-side.

*Edit*

Got it, now digging around in /drivers/mmc files...

I attached here as well:

http://xdaforums.com/showpost.php?p=27320103&postcount=137

*Edit 2*

The MMC_CAP_ERASE was found in 2 files but unsure if these are used by the T989. So long as it is not it would suggest this is how they've patched it.
[Samsung Epic 4G Touch] garwynn:
FYI: Response from Samsung Semiconductor

Well, can't say I'm surprised....

I know Entropy's been talking to someone and some of the fellow XDAers also work there... so short of shooting off an email through the Samsung Mobile website would entertain any suggestions how we can try and get that patch released. From what I've heard lately from Entropy it seems this may work through JTAG after all; but I do not know if that was confirmed through his contact or not.
[Samsung Epic 4G Touch] Entropy512:
Basically, my interpretation of Ken Sumrall's comments indicate that this would require a method of booting the device that does not require a functioning bootloader, as the firmware upgrade/wipe process clobbers the bootloader.

This means either JTAG or USB bootloading along the lines of AdamOutler's Unbrickable Mod. The problem is that there are items (specifically a signed IBL for USB bootloading) that we had access to with Hummingbird devices but not with Exynos device. As a result, Unbrickable currently does not work on any Exynos device.

So we need:

The updated eMMC firmware for affected eMMC chips

Documentation on how to load the new firmware

Documentation on how to repartition the chip including boot partitions

OR

Documentation on how to fullwipe the chip without a firmware load (this would allow resurrecting devices without fixing the underlying bug)

In addition we'd need a signed USB-bootable IBL along the lines of that which is used by the Unbrickable Resurrector for Hummingbird devices. AdamOutler and Rebellos know more about what we need here - Adam is already CCed on the email list with our contact and I'll be adding Rebellos. As I mentioned, you might also be receiving email from her yourself. Without this second item, then only JTAG resurrection services like the RIFFbox guys could implement the fix.

Note that the latter item would also permit resurrection of devices that have been "traditionally" hardbricked (clobbered bootloader) with USB (and possibly requiring a resistor change.)
[Samsung Epic 4G Touch] garwynn:
Well, for those of you who work at Sammy Mobile I'll apologize in advance for firing off that email on the website. Not trying to make headaches for anyone over there, just would like to see this made available if at all possible.

Guess at this point I'm down to the "squeaky wheel" approach... not much else we can do from our end.

And thanks Entropy - I'll make sure to keep an eye out for any emails.
[Samsung Epic 4G Touch] garwynn:
Minor Update

Moving a little forward - now have a mailing address for R&D to request the firmware patch. Any of you guys at Sammy in this section, please PM if I should specify this to someone's attention or if I should email a copy to you in advance. Either way I expect to get this out tonight.
[Samsung Epic 4G Touch] omar_killer:
hey guys I'am an SGS2 owner I was on an 4.0.1 AOKP ROM,wiped eMMC,then installed another AOKP ROM,after some time I restarted my phone,it turned off but never turned on,so my question is it because of this bug?

it's currently in the repair shop,should be fixed tomorrow.
[Samsung Epic 4G Touch] garwynn:
It's in the realm of possibility. If the repair shop can fix it by JTAG it won't be as there's no public way of clearing the eMMC lockup at the moment.
[Samsung Epic 4G Touch] omar_killer:
then I'll wait till tomorrow and will tell you guys if it got repaired by a J-tag or not..
[Samsung Epic 4G Touch] MR.change:
Wait, but isn't the s2 clear of this problem? I thought its kernels never had the ERASE command ?

Or maybe the newer versions are also blessed with this feature by Samsung? :D
[Samsung Epic 4G Touch] Mattix724:
He mentioned using a 4.0.1 based AOKP rom, if the bug was not patched in that release it may be susceptible to the bug. What kernel were you using to wipe data/cache?

Do you know what firmware revision of the EMMC was?
[Samsung Epic 4G Touch] Entropy512:
Most likely a different issue if you're on I9100. The description of your problem sounds different, plus only one I9100 kernel could ever trigger it and that was pulled ages ago.