yashsingh1/xdaforums huggingface dataset:
[Samsung Epic 4G Touch] kgp700:
hi guys

im using korea galaxy s2 (SHW-M250K)

many korean galaxy s2 (SHW-M250S/K/L) users experienced Super brick

almost people experienced super brick after data wipe on cwm touch recovery

symptom of superbrick

1. power on -> no screen(blank screen)

2. can not enter to download mode (can not use odin or heimdal)

is it relate to super brick?

can not enter to download mode another super brick phones too?

im making korea galaxy s2 kernel (base on m250k kernel source)

if want to avoid super brick bug,

only need remove MMC_CAP_ERASE from /drivers/mmc/host/mshci.c and /drivers/mmc/host/sdhci.c ?

( mmc->caps |= MMC_CAP_SDIO_IRQ | MMC_CAP_ERASE; -> mmc->caps |= MMC_CAP_SDIO_IRQ; )

like this

https://github.com/kgp700/exyroid-sgs2-ics/commit/d655a2834058a12b901075ee2cba85892bc56ae4

or need another fix?

(sorry my bad english)
[Samsung Epic 4G Touch] Entropy512:
Yeah... I think SHW-M250S/K/L was the first device to be affected by Superbrick. You are the first Korean developer to join in on the discussion - we've all been hearing rumors that the Korean SHW-M250* owners were having problems but the language barrier made it difficult to confirm. One thing to note - Sometimes the bootloader gets clobbered, but not always. Some people wind up with a device that boots into recovery, but /data and /system are unusable. Others had fully hardbricked devices because their bootloader got clobbered.

Our first experience here with source code that caused it (and allowed someone to review) was the M250L Update4 base - gokhanmoral rebased on M250L update4 for his I9100 kernel and a bunch of bricks ensued. (That was the SiyahKernel 3.1rc6 incident - all Siyah releases since then are safe.

You are correct - but you only need to do it in mshci.c, as sdhci.c is only used for external SD and the wifi chip (wifi is SDIO).

Also, one thing that may be useful for those who want to increase safety with broken Samsung kernels that permit ERASE commands through:

http://review.cyanogenmod.com/#/c/17326/

and, as an example for n7000:

http://review.cyanogenmod.com/#/c/17484/

This will cause recovery binaries and (in the case of full CM9 builds) update-binaries to be built which do not attempt to ERASE when formatting a partition, allowing for the creation of safe recoveries and safe ZIPs for dangerous kernels. (Unfortunately it doesn't have the guarantee of safety that removing MMC_CAP_ERASE does, for example a "safe" recovery can still brick of a "dangerous" ZIP is flashed from a "dangerous" kernel.)
[Samsung Epic 4G Touch] kgp700:
Thank you very much

answer :)
[Samsung Epic 4G Touch] ruffneckZeVo:
Is there a workaround for the et4g like the note using other partions and custom pit if so can someone point me in that direction

sent from my Verizon Wireless HTC EVO 3D
[Samsung Epic 4G Touch] sfhub:
If your phone still boots to d/l mode, you can follow their thread and do the same workaround (it actually started over on E4GT when we started experimenting with the problem). The locations will be different so you need to customize that. Most people here have just decided to get the phone replaced because they bought it through the carrier so warranty replacement is a simpler process.
[Samsung Epic 4G Touch] slick_rick:
So yesterday in IRC, xda member krazyflipj with the help of chris41g was able to bring his bricked e4gt back to life (not the BLOD type, the one that would get stuck at data.img in Odin) using this thread as a guide. He flashed CM9 and it booted back to life. After awhile, his phone would start to freeze randomly so he mobile odined the el26 cwm kernel and was met with a bunch of mount errors. From there he tried to odin something else, not sure, but got stuck at data.img again. So its possible to bring that type of bricked e4gt back to life but for how long it lasts, IDK.
[Samsung Epic 4G Touch] Esoteric68:
Okay well I installed ROM Manager, in fact I bought the premium and paid 1.99 for cwm touch but my phone doesn't seem to like it because when I reboot into recovery I'm only showing android stock. So I'm going to let this step hold because it's midnight and I'm tired. lol I'll post the steps I went through to this point.

---------- Post added at 12:13 AM ---------- Previous post was at 12:02 AM ----------

Here are the results of my testing. If you see any steps where I err'd please let me know and I'll run the tests again. Hope this helps.

Starting from Blu Kuban. FE07 Modem, FE07 kernel repacked plus.

1) flash FE07 unlocked , then format_all, then flash calk 1.5

E:signature verification failed

E:Can't open /tmp/sideload/package.zip

Installation aborted.

Immediately flashed Anakonda with success

2) flash FE07 unlocked, then format_all, then AOKP build 33 with success

3) flash FE07 unlocked

Android guy died, laid on back with red triangle and ! in the middle

tried format_all killed Android guy again

(Think I know what went wrong here)

Rebooted, went into ODIN flashed FE07 one-click with success

Used autoroot to install recovery

4) flash FE07 unlocked , then format_all, then tFE07_v0.1.0 Rooted. Themed. Odexed/Deodexed. Tweaked with success

5) flash FE07 unlocked , then format_all, then Calkulin's_E4GT_2_ROM_v1.5 with success

6) flash FE07 stock, use ROM manager to temp install CWM Touch

Got this far but had no luck getting recovery to work. Everytime I rebooted into recovery I got android stock. So leaving this for another day.

7) used autoroot to get cwm, flashed FE07 unlocked, then format_all, then Blu Kuban with success.

8) flashed FE07 repacked plus and called it a night!
[Samsung Epic 4G Touch] azyouthinkeyeiz:
Awesome! Thanks for the help. Just two simple things I noticed, but no errors to have to redo, unless you want to verify the second one.

1) I think the sideload error is from a bad download. I got it on a version of Gapps I tried, but re-downloading solved it.

3) The red arrow recovery is from trying to flash FE07 Unlocked from the stock recovery, flash EL26CWM (or the autoroot CWM) first to flash FE07.

/*Edit- Not sure about CWM Touch, I have heard others with your issue (not being able to boot into it) from ROM Manager, but then I hear the others complaining about bricking while using it. I tried it once from ROM Manager, when it first released, but had the same results as you, so I waited for the CWM Touch repack that SteadyHawkin made soon after, and I had no issues with it. (I used it to wipe data on the first ICS leaks, but then saw all the bricks and stayed away after that.) But, it was just the whipping boy, imo.

I'd like to hear from some people who bricked, and their path to a brick.
[Samsung Epic 4G Touch] Esoteric68:
I thought that might be the case (bad download) which is why I re-downloaded and tried again in step #5 which worked fine.

Aha, that's what I was wondering. Should've done the EL26 but just did the one-click and autoroot instead.

Glad I could assist. If someone can explain clockworkmod touch to me I'll be happy to try it again tomorrow when my eyes aren't crossing and my brain isn't mush. lol

Thanks for the feedback. Have a good night!
[Samsung Epic 4G Touch] nivron:
I think you can only get to CWM touch if you reboot into recovery via ROM Manager because it is a fake flash. Does rebooting into recovery from ROM Manager still give you stock recovery?
[Samsung Epic 4G Touch] sfhub:
Yes, I believe that is correct. If you do a real reboot, it will reload the initramfs from the installed kernel.

I believe the reboot from ROM manager does an in-memory reboot.

I would agree with one of the previous posters though and refrain from testing CWM Touch until the very end of our testing process. You should at least get to enjoy your phone a little before taking the ultimate risk :)
[Samsung Epic 4G Touch] sfhub:
AOSP is good to try also.

Just be very careful to go back to FE07 after you flash a ROM because most ROMs will include their own kernel.

IMO ODIN is actually the easiest way to do this because you are assured it flashes and have less chance of getting mixed up which got installed because you are using a different app than flashing the ROMs
[Samsung Epic 4G Touch] robertm2011:
I'll, for the sake of consistency, go the same route tonight after work; will post results immediately after.
[Samsung Epic 4G Touch] garwynn:
Morning and thanks for everyone's help overnight. I briefly went over the posts between sleeping bouts of a little 4 month old last night.

@Sfhub,

I'll be editing my previous post to update the terminology as you mentioned - that's first on my list. Want to make sure anyone jumping into this today can follow it as easily as possible.

I'm also going to take another crack at the fw version and why they are mentioning 0x25. I made the assumption that this was just to indicate a high and low date range for possible H/W and F/W revisions as it seems the most logical - Do this and we are valid subjects. But let me see if I can put something more than my assumption behind that today.

As many had the filesystem question still lingering (including me) I'm also going to try digging into that today as time allows. I've been reading articles from various sources, including ext2/3/4 and eMMC specifications to see if I can shed some light on this. It's taking me a little longer as I spent 95% of my time doing Windows-based support in the past; however, I can justify the time at work because the IBM i is Unix-based and so the file systems behave in a similar manner. (Meaning I can apply what I'm learning about this to work possibly.)

The firmware is not being corrupted, it's the one

doing

the corruption, according to Mr. Sumrall. The only thing that I can think of is that one or more superblocks are being corrupted. In the case of a HDD you could use fsck to try and repair it - but I haven't even seen an attempt to compile this and use it within Android. Without any tools or apparent driver support to repair the file system after corruption I think the kernel throws up an I/O error in frustration. (versus a physical I/O error that would require replacing the eMMC - which has been successful in other devices based on some searches.)

I'd like to try and see if we can get a little more specific on the next follow-up to Mr. Sumrall. I know they're probably busy so let's see if we can find a good way to ask what we are looking for in one more email and then hopefully let them get back to what they do best - improving Android.

More to come later today. Thanks to Eso for taking on the test.

To all,

I apologize but at the moment I can really only dig into this during work hours - after that I'm usually busy and unable to reply except by short messages (using the XDA app). So if you want to get a message to me please try and do so before 5 pm CDT - I'll keep digging into the technical aspects of this as much as possible.
[Samsung Epic 4G Touch] slick4mitch:
My apologiez for posting this but you guys are what XDA is all about, this is pure teamwork at its core ... don't give up and thank you for your hard work.
[Samsung Epic 4G Touch] sfhub:
They are finally using Unix now instead of AIX? I remember back in the day we used to call their RISC-based RS/6000 "Risky 6000" because lots of stuff didn't work right on it. That was when everybody did their work on SunOS.

My understanding is also the firmware is doing filesystem corruption. The issue is any periodic filesystem corruption can be fixed by repartitioning and reformatting, at least in the short-term. More importantly, filesystem corruption cannot affect a JTAG flash. We need to explain how the system can be permanently (or seemingly permanently) affected.

So the litmus test (for me) is whether this fix can explain the scenario with the failed JTAG flash.

All the far-fetched ideas being bandied around are not being put forth as "actually" happening. They are being put forth because we are grasping at straws to come up with ideas how the bug as described can fit the problem we are seeing. It may be that we are trying to fit a square peg into a round hole and this fix is addressing different corruption than what we are seeing.
[Samsung Epic 4G Touch] sfhub:
Woops, my bad, inserted a break in the switch statement where there was none.
[Samsung Epic 4G Touch] garwynn:
If you take a look again it looks like only hwrev and fwrev are excluded - the month and year fields are still populated on version 4. That's how I came to the conclusion.
[Samsung Epic 4G Touch] sfhub:
I realized in my head, I actually inserted a break statement, in the switch where there was none. Sorry about that.

Also I didn't even realize there was a scroll bar on the side to scroll down to the actual code in question :)
[Samsung Epic 4G Touch] sfhub:
Ok, so that can explain why our kernels all report 0x0 as the fwrev.

However the code that actually checks to see if "our" emmc is in the valid range is NOT ignoring the fwrev. It will still do the range check against the provided 0x25 and we will be outside the range thus the function will not be called (unless I'm misreading something)

hwrev is zero in both cases so doesn't affect the comparison.

However fwrev of 0x0 shifted 32bits will never be <= 0x25 shifted 32bits (range start). The rest of the bits cid_rev constructs are irrelevant because the highest order bits take precedence in this particular comparison.

/* Detect on first access quirky cards that need help when
* powered-on
*/
mmc_fixup_device(card, mmc_fixups);

00052 void mmc_fixup_device(struct mmc_card *card, const struct mmc_fixup *table)
00053 {
00054 const struct mmc_fixup *f;
00055 u64 rev = cid_rev_card(card);
00056
00057 /* Non-core specific workarounds. */
00058 if (!table)
00059 table = mmc_fixup_methods;
00060
00061 for (f = table; f->vendor_fixup; f++) {
00062 if ((f->manfid == CID_MANFID_ANY ||
00063 f->manfid == card->cid.manfid) &&
00064 (f->oemid == CID_OEMID_ANY ||
00065 f->oemid == card->cid.oemid) &&
00066 (f->name == CID_NAME_ANY ||
00067 !strncmp(f->name, card->cid.prod_name,
00068 sizeof(card->cid.prod_name))) &&
00069 (f->cis_vendor == card->cis.vendor ||
00070 f->cis_vendor == (u16) SDIO_ANY_ID) &&
00071 (f->cis_device == card->cis.device ||
00072 f->cis_device == (u16) SDIO_ANY_ID) &&
[B]00073 [U][I]rev >= f->rev_start && rev <= f->rev_end) {
[/I][/U][/B]00074 dev_dbg(&card->dev, "calling %pF\n", f->vendor_fixup);
00075 f->vendor_fixup(card, f->data);
00076 }
00077 }
00078 }
[Samsung Epic 4G Touch] garwynn:
Okay... let's go back to the change itself.

That's what I get for not checking the change versus the unchanged source.

fwrev is added in version 4 but at a different offset from version 1:

card->cid.fwrev	= UNSTUFF_BITS(resp, 48, 8);

Version 1 has card->cid.prod_name[6] there.

Any idea how we can peek at that offset and see what's stored?
[Samsung Epic 4G Touch] sfhub:
Ok, so lets all hold off on any testing of ROM Manager and CWM Touch.

This is so we can get as much data testing ONLY stock recovery. If we can get some confidence stock recovery won't brick our phones when repacked with FE07, then EVEN IF the kernel fix we are discussing ends up not fixing the /data EMMC corruption problem we are seeing, at least we will have had some value in discovering that stock recovery repacked with FE07 doesn't brick.

Then at least people will have one safe option to flash stuff on ICS-based kernels.

If we start introducing CWM Touch, there will be a slew of variables introduced and should something go wrong, it will just introduce lots of confusion and we wouldn't be able to isolate the cause.

So lets stick with testing just FE07 kernel repacked with unlocked stock recovery. If nobody bricks, then we'll move on to a FE07 repacked CWM.
[Samsung Epic 4G Touch] sfhub:
Yes, I noticed the prod_name field changed in size with the different specs and the bitshifts changed. I don't think it matters. card->cid is a data structure. It is populated using different bit shifts depending on the spec version.

cid_rev is a macro that takes the cid data structure (after it has already been populated) and bitshifts to create an internal numerical representation of the hwrev, fwrev, year, and month.

The bitshifts are not related to each other.

We know what our fwrev is (after being populated) because the kernel is reporting 0x0.
[Samsung Epic 4G Touch] sfhub:
I added a short status update to the beginning of the first post.
[Samsung Epic 4G Touch] garwynn:
I know I'm stubborn at times but I'm not giving up on it. If everything except for one piece matches I find it more likely I'm misreading this and we're included than it being the sole exclusion - especially since other factors give credence that this might be a fix on our devices.

Update

OK, found by parsing the cid string manually that fwrev is 0x19 (hex). It's the 2 hex characters in the cid string immediately to the left of the serial number. (cat this to find it).

This gets converted to unsigned integer in the revision so (16 * 1) + 9 = 25.

But what I can't reconcile is the 0x25. Why use decimals for every other field except this one?

Honestly? Either it's being treated as decimal (even though it breaks every common sense programming rule), is intentionally not supposed to match or it's a programming bug.

Definitely going to ask about this one because we haven't seen a Sammy device yet that this would satisfy - and I've been digging around on the 'net as much as possible. Also going to ask about why fwrev is not being set (maybe not in the kernel after all?) and the lingering issues about why the file system cannot be wiped by conventional means or JTAG where I have seen this possible with a HDD.
[Samsung Epic 4G Touch] Entropy512:
We've known about partition workaround hacks for a while - they're not a longterm solution.
[Samsung Epic 4G Touch] quick99si:
I've done the same thing last night actually, and it seems that all GB kernels get met with "can't mount" and "can't open/find" errors. Restoring backups and formatting doesn't work obviously, so access to the file system seems very limited to me for now.

Rogue 1.2.2 (CWM5) is more functional, but it won't let me flash a rom, kernel, restore, or do much of anything really.
[Samsung Epic 4G Touch] ruffneckZeVo:
Guess in stuck till I can find a fix bad esn yep gotta love craigslist so warranty isnt an option Im guessing Sammy won't fix a bad esn phone with no receipt I'm trying to talk one of my buddies into "losing" his et4g and claiming it on tep and giving me the lost one and paying the 100 bux or may just try n find another one cheap on here or eBay I've learned a lot about the device trying to fix the brick so in a way it was a good thing but damn it sux lol
[Samsung Epic 4G Touch] ruffneckZeVo:
I'm not able to get my pc to recognize my phone in recovery for adb to.attempt a repart or using the sdcard as the failed partions any thoughts on what the problem is I've tries Samsung and naked drivers
[Samsung Epic 4G Touch] MicrosoftBug:
When you report a phone lost or stolen, that ESN gets blacklisted and is unusable after that.

Sent from my SPH-D710 using Xparent ICS Tapatalk 2
[Samsung Epic 4G Touch] quick99si:
That's insurance fraud and I'm pretty sure it's $150 ;)
[Samsung Epic 4G Touch] ruffneckZeVo:
Bad esn isn't an issue It will be flashed to vzw
[Samsung Epic 4G Touch] ruffneckZeVo:
U don't consider lying about a phone u brick to be insurance fraud I see no difference
[Samsung Epic 4G Touch] ruffneckZeVo:
I'm trying to trade my flyer for one on here now and if its 150 I can find one on craigslist for that so no need for tep claim
[Samsung Epic 4G Touch] ruffneckZeVo:
Any advice on the USB issue I have tried everything I can think of and its still not recognizing it in recovery is there anyway to enable USB debugging on a bricked device
[Samsung Epic 4G Touch] feyrune:
What recovery are you running?
[Samsung Epic 4G Touch] ruffneckZeVo:
I have tried several cwm 5 from the el26 twrp,agats ics,rogue and none work windows keeps saying the device malfunctioned and won't mount it

Sent from my PG86100 using Xparent Red Tapatalk 2
[Samsung Epic 4G Touch] Mattix724:
Use AGAT's recovery from FF02. It has things like debugging enabled by default.

EDIT: Correction... FE22.
[Samsung Epic 4G Touch] ruffneckZeVo:
Got it thanks
[Samsung Epic 4G Touch] Ascertion:
Still insurance fraud...this is why we can't have nice things.
[Samsung Epic 4G Touch] playya:
Have any of you seen this post http://xdaforums.com/showpost.php?p=27852689&postcount=435 quite interesting
[Samsung Epic 4G Touch] garwynn:
Saw it, good for those who can use it... but still think people should at least check into warranty repair/replace options if available. It's one of the main differences between the int'l Note community and the E4GT community from what I have observed... many of them have been told they had to replace the MB for about the original price of the phone. I don't think many here have had that same experience unless they flashed over to a different carrier.

I, for example, would probably have to resort to this unless my MVNO agreed to replace. I doubt they would though based on previous experience.

And for clarification in case anyone isn't clear - If you can replace/repair for little or preferably NO cost, at least look into it. This is a great workaround in that it restores functionality but doesn't repair the damage to the eMMC. The thinking is it never hurts to ask; you're no worse into the situation by doing so.
[Samsung Epic 4G Touch] playya:
exactly, there were quite a few people either afraid, did not have the money or various other reasons were stuck with their phone and wanted to fix it. Now if someone kept their phone in hopes that some fix would come out, this may be the time to give it a shot. Like you said it is not going to make it any worse
[Samsung Epic 4G Touch] ruffneckZeVo:
Hell ya got it working again
[Samsung Epic 4G Touch] okantomi:
Fantastic! You we're just about to give up. Glad you didn't sell it as a "brick."
[Samsung Epic 4G Touch] renzyyy:
yeah that worked for me as well. if partition tables are altered, can the emmc bug occur again?
[Samsung Epic 4G Touch] garwynn:
Don't know if anyone has tested that to be honest. "Fool me once..." and such. :D
[Samsung Epic 4G Touch] renzyyy:
haha right. just thought perhaps if this method prevented it from happening again that maybe a phone that never encountered the bug could have its partitions changed & prevent it from ever happening. of course losing some of the internal memory, but the benefits from that would outweigh the cost in my opinion.

my apologies if this has already been discussed/brought up.
[Samsung Epic 4G Touch] Entropy512:
Almost surely - you'd have an even bigger chunk of the eMMC blown out.

I think eventually you'll pretty much lose the entire chip, or hit the bootloaders.

I was originally certain that this bug couldn't affect Galaxy S1 devices, but I realized they have hybrid storage - oneNAND/moviNAND for boot and /system and a few other partitions, but eMMC for /data and /sdcard - On those devices, wiping /data is starting to appear to trigger a bug that corrupts the partition table itself, rendering the entire chip unusable. (The Encryption Unavailable situation on those devices) - Currently this involves a lot of speculation though, far less is known about the EU situation on those devices, but it is starting to seem like it might be related.
[Samsung Epic 4G Touch] renzyyy:
yeah thats what i figured, thanks for the input.