yashsingh1/xdaforums huggingface dataset:
[Samsung Epic 4G Touch] MoHoGalore:
*Wrong thread* Disregard.
[Samsung Epic 4G Touch] TrayLunch:
The issues were mainly in the ICS kernels. GB kernels did not make the triggering command, and from what Garwynn says, JB kernels may not either. That is excellent news! Glad to see the work Garwynn did with Samsung is finally paying off!

Bugging up my phone, so you don't have to!

Need help? XDA.Tray@gmail.com on GTalk or by Email
[Samsung Epic 4G Touch] Entropy512:
JB kernels for I9100 have Samsung's official fix, which is to replace secure erase with non-secure erase.

So they're safe IF Samsung's claims that nonsecure erase is safe are true. I'm personally a bit paranoid. :)

I'm ASSUMING Sprint leaks for D710 also have this fix, it's possible to check an unpacked kernel image for the chip IDs using "strings" - if MAG4FA is present in an unpacked kernel image the fix is probably there.
[Samsung Epic 4G Touch] garwynn:
I'll pull one and check today if I have time.
[Samsung Epic 4G Touch] garwynn:
E4GT JB Kernels have the official fix. It's about danged time!!
[Samsung Epic 4G Touch] celsius0010:
Thank goodness.I bricked 2 OG Epics due to the old cheap Samsung USB cables. I've been extra careful with my Touch and it's been fine.. But this is good news fewer mistakes..
[Samsung Epic 4G Touch] monkeytools:
so are we safe to do a factory data wipe. or is it too soon to say that.
[Samsung Epic 4G Touch] TrayLunch:
It's the official fix, so it fixes all.

Bugging up my phone, so you don't have to!

Need help? XDA.Tray@gmail.com on GTalk or by Email
[Samsung Epic 4G Touch] Entropy512:
It fixes all IF you trust Samsung. So far it seems OK though.
[Samsung Epic 4G Touch] ps3hacker3:
Thank god ;)
[Samsung Epic 4G Touch] shmallow:
I just got bricked, using EVOLTE. I wasn't using a CM rom, but a rom that had some CM elements in it, Dirty Unicorns 4.2.2. Don't use lagfix if you're on that rom and have an EVOLTE.
[Samsung Epic 4G Touch] Entropy512:
Actually, these days there are more dangerous stock firmwares out there than CM. CM has been disabling MMC erase on known affected devices for over a year.

(There were some new bugs uncovered with 4.3/CM10.2 and fstrim, mainly on devices that didn't suffer from the main Superbrick issue with secure erase.)
[Samsung Epic 4G Touch] Th0m1sl4v:
thx for the research;)
[Samsung Epic 4G Touch] MarianoQT:
Hi! Yesterday i used the eMMC Check but i don`t Know some meanings of the app...

First, in te item "Brick Bug?" the app says Yes. With Danger.... But In the check memory block by block of memory says that its Ok... I don`t know what to think ! :S

Gt-N7000 Android 4.1.2 Stock Rom

Type: VYL00M

Date: 02/2012

CID: 15010056594c30304d1901c83bcb2f5f

FwRev: 0x19

Please Help Me ! Thanks !
[Samsung Epic 4G Touch] garwynn:
It just means you're susceptible to it but that it actually hasn't been triggered yet. The good news is 90 percent of the kernels and recoveries affected have been already fixed; anything JB is fixed by Samsung.
[Samsung Epic 4G Touch] lawong:
so that means jb firmware are safe ?
[Samsung Epic 4G Touch] garwynn:
Yep. At least from this.
[Samsung Epic 4G Touch] ptericles:
Blue light special with cm-10.2-20131220-NIGHTLY-d710

I tried to recover my /data partition from cwm recovery mode. The boot sequence never completed, so I held power. Now all I get is a blue light on my d710. No battery charge status, no download mode, no recovery mode, no PC recognition over USB, no com1 connection in Odin. I've tried different USB cables. I was running cm-10.2-20131220-NIGHTLY-d710

For more detailed info (hopefully not to confuse things more) here's the longer story:

I've been running dastin's ROM for a long time. I think I started back in March or April. I've been fairly pleased with it. I've been through Android 4.1.2, 4.2.2, and now 4.3. I usually do in-place upgrades. I know in-place upgrades can cause issues, but I'd rather keep all my data and settings if possible. Issues finally started catching up with me. The AOSP keyboard was crashing, but I mostly found okay workarounds for that. Supposedly, the 4.1.2 to 4.2.2 update can break some bit of radio code so that Google Photospheres use the accelerometer X-axis for the Y-axis and Y-axis for the X-axis rather than the orientation sensors. I really wanted to get photosphere to work and added to the keyboard issue, general crashes, and perhaps still some battery drain, I decided to bite the bullet and get a fresh start.

I tried an app data and device data backup with HaloBackup and created a 490MB ab file. I also tried to drag and drop some data that I cared about over USB storage mode. I got quite a bit of data that way, but my phone would freeze while trying to transfer some data. I did a factory wipe from CWM recovery while updating from cm-10.2-20131215-NIGHTLY-d710 to cm-10.2-20131220-NIGHTLY-d710. When I tried to restore from backup, I couldn't press the button for some stupid reason. Eventually, I found Nandroid Manager. It was a pretty nice app for the most part. I was able to restore specific data and apps that I wanted. Then I got greedy. I tried the beta feature of restoring the desktop icons and widgets. I wish I hadn't tried that. I could no longer get into the settings menu after that, so I reflashed again but still no settings menu. I would have to do a factory wipe again. I did the factory wipe again and tried to restore data from Nandroid Manager. This time, I couldn't see my backup available for some reason. I was beginning to get frustrated. That's when I tried restoring the /data partition from the CWM restore mode.
[Samsung Epic 4G Touch] garwynn:
Solid blue? If it was this it would have frozen during the restore process.
[Samsung Epic 4G Touch] ptericles:
solid blue

Does rebooting qualify as part of the restore process? Either way, it's a solid blue light.
[Samsung Epic 4G Touch] gamepro602:
Solid Blue = Emmc failure

Sorry to say but your phone is dead :(
[Samsung Epic 4G Touch] ptericles:
solid blue = dead ...jig?

I had a little bit of hope because my friend had a homemade jig. It didn't do anything, though. Is this fundamentally the same thing? mobiletechvideos[dot]mybigcommerce[dot]com/samsung-galaxy-s-download-mode-jig
[Samsung Epic 4G Touch] gamepro602:
Well no, Emmc chip in your phone died, so even a jig won't bring it back.
[Samsung Epic 4G Touch] Lanchon:
fixing lag

hi!

Entropy512, i hope you read this as no one else dares to give me a response.

i would like to trim the emmc in a Note 1 as the phone is exceedingly slow, almost to the point of being unusable.

it is a VYL00M 01/2012 fwrev:0x19, which is affected according to this page:

- http://wiki.cyanogenmod.org/w/EMMC_Bugs#eMMC_parts_known_to_be_buggy

by Samsung eMMC secure erase bug:

- http://wiki.cyanogenmod.org/w/EMMC_Bugs#Samsung_eMMC_secure_erase_bug

the page says this bug involves secure erase, but says nothing about TRIM. can TRIM be safely used on this chip? (for example, lagfix?)

is there any other way to wipe it and restore as-new speed? will a non secure erase (as issued by samsung fw) help?

do you know how cm10.2 (based on android 4.3 which includes fstrim) handles this issue for the note 1?

thank you!
[Samsung Epic 4G Touch] AA1973:
Put an @ in front of the XDA member name, otherwise [MENTION=591147]Entropy512[/MENTION] won't be alerted.

Gesendet von meinem Galaxy Note mit Tapatalk
[Samsung Epic 4G Touch] garwynn:
From what I recall in the discussions secure trim was affected but even TW kernels from 4.1+ (AOSP kernels earlier) have had a fix that effectively disables that option for these eMMCs. So cm-10.2 should not experience this issue.
[Samsung Epic 4G Touch] Entropy512:
TRIM is safe IF you trust Samsung.

I personally don't. TRIM has been documented as causing problems on other Samsung flash chips - http://wiki.cyanogenmod.org/w/EMMC_Bugs
[Samsung Epic 4G Touch] vampyyri1123:
MAG4FA

0x0

0x0

0x000015

0x0100

01/2012

MMC

0x1c0f531d

1501004d4147344641191c0f531d1f89

i believe my phone has the eMMC glitch so i will not be testing it at this time. unfortunately i was wanting to install cyanogenmod 10.2 with KK and ICS modem.. im coming from 4.1.2 and a GB modem.. do you guys think that if i flash the ICS modem and then the CM 10.2 ROM over would it activate this eMMC error????????
[Samsung Epic 4G Touch] UPdownLoAD:
It's been awhile since I was actively following this thread/bug, but I believe it was triggered by doing a hard reset in ICS that was later "fixed" in JB and up. Did you run the eMMC check app?
[Samsung Epic 4G Touch] garwynn:
No, it won't. Grab your modem of choice and flash in Odin. Recovery/kernel should state that it has patched against this - if so you're good to go!
[Samsung Epic 4G Touch] auxdefault:
In search for solutions to my SGS 3 mini issue, may I know if this is somehow relevant to this http://xdaforums.com/showthread.php?t=2734191 ?
[Samsung Epic 4G Touch] ChaosBitch:
Is this a eMMC BUG? I'm not really sure .

OK I don't know if this is really a bug but I attach some screenshot. Could anyone help me ?

The last image was captured from a website who sells mobile spy. And even read some thread saying that its a RN-42 Firmware bug. Related to adruino? I don't know. I'm afraid to do anything with my phone now. .
[Samsung Epic 4G Touch] Lanchon:
lol

what is the problem? what is your question? what do you need help with?

btw you DO NOT have brickbug in your moto X lol
[Samsung Epic 4G Touch] Krabicz:
I've read for last 2 hours about brick bug on S II and I'm still confused. Is it safe to install Cyanogenmod 12 on Galaxy S II (Android 4.1.2) with insane chip (YVL00M, FwRev: 0x19)?
[Samsung Epic 4G Touch] shoey63:
It's safe unless you are on ICS and flash with CWM.zip or a very old custom ICS kernel.
[Samsung Epic 4G Touch] Lanchon:
get a kernel with fpbug fixed and trim. i recommend you go for cm11 latest nightly with my trim kernel. cm12 is still very "nightly" :)
[Samsung Epic 4G Touch] vov120:
Hi,

My phone (I9100) suffers from the sudden death syndrome.

Boot and SBL partitions are readable (It starts kernel loading before gets stuck - checked with UART).

I plan to dump user data partition and mount it then to retrieve the user content.

And if some partitions are readable, doesn't it mean that I will be able to read other partitions correctly?

Would appreciate any thoughts if it could work as I plan to order this service from the local phone repairing lab.

Thanks.
[Samsung Epic 4G Touch] garwynn:
Before you do anything else I would go look for the detection tool and make sure you have an affected block.

It's rare to see this anymore so just wondering if something else is at play here...
[Samsung Epic 4G Touch] Lanchon:
you are mistaken, there is no sudden death syndrome on i9100.

i assume you can't boot into recovery.

can you boot into download mode?

if your emmc is having trouble, it might hang when you try to read some areas, and some areas might read incorrectly (data corrupted and/or misplaced).

you can dump the emmc via JTAG.
[Samsung Epic 4G Touch] vov120:
Not sure I understand how I can see if there are affected blocks? I can't get into Recovery mode. Only to Download mode. Is it possible in this case?

I can only boot into Download mode.

I've made UART JIG and see the following info during SBL run:

Copyright (C) 2011 System S/W Group. Samsung Electronics Co., Ltd.

Board: C1 REV 02 / Apr 5 2012 20:15:29

....

[hsmmc_init] MMC card is detected

Product Name : VYL00M

CID:150100 56594c30 304d191a 7713e7e

Seems I have VYL00M with FW version 0x19 and OS from April 2012.

As I understand, it's a standard combination for

Samsung eMMC secure erase bug, Also known as: "superbrick" bug

as the fix for this issue has been available since June 2012.

Do I miss something?

The phone gets stuck when I try to save changed env parameters from SBL:

SBL> saveenv

save param.blk, size: 5268

...

I am able to read all environment parameters correctly, but seems any write access to this area fails.

PS: The issue has happened at the night when nobody used the phone.
[Samsung Epic 4G Touch] garwynn:
If you can boot into download mode, have you tried flashing a full ODIN tarball?

If so, what is the result when you tried?
[Samsung Epic 4G Touch] vov120:
It fails during boot.bin flashing.

I tried also with Heimdall, but with near the same result.

Heimdall is able to read PIT but at the end reports:

Ending session...

ERROR: Failed to receive session end confirmation!

Looks as if at the end of session SBL tries to write something into NAND and fails.

I've read somewhere that as result of "superbrick" bug, just some blocks of flash get corrupted/unavailable.

I count on that JTAG dump will contain most of 16GB data valid.

It's the main reason why I asked if it's possible to use JTAG to read flash dump of "superbrick"-ed phone.

Does it sound reasonable?
[Samsung Epic 4G Touch] UPdownLoAD:
Have you tried another cable? I swear I've had that error before back in the days of my Epic and it was cured by using a different cable.
[Samsung Epic 4G Touch] robertm2011:
1. That is correct.

2. No clue, did the same thing w/Calk's format_all, but was able to make it work on the second attempt.

3. Nope, don't have one.
[Samsung Epic 4G Touch] Esoteric68:
Oh no. I went through about 5 ROM installs the other night with only one tiny (user error) hitch but didn't do any data wipe/factory reset. I hope you can fix it.
[Samsung Epic 4G Touch] sfhub:
The current theory is wipe data/factory reset is the culprit. This matches earlier experiences with folks flashing CWM Touch and doing wipe data/factory reset.

So IF you were to do further testing please AVOID using that command from recovery. Only use format_all script from Calk.

Even if all we get out of this testing is folks are safe flashing as long as they don't do Wipe Data/Factory Reset, then that will be an improvement.

I added BIG RED warnings to the first post.
[Samsung Epic 4G Touch] Esoteric68:
Robert I've got a spare E4GT on its way to me as we speak. I should have it by Monday, I'd be more than happy to send it your way as a loaner until you can get a replacement.

---------- Post added at 09:34 PM ---------- Previous post was at 09:34 PM ----------

So is it likely if I had tried a few more wipe/resets I might've bricked as well or do you think it's only when combined with flashing ROMs that it's triggered?
[Samsung Epic 4G Touch] sfhub:
Don't know if it is wipe/reset or wipe/reset combined with certain memory versions.

I think the problem is happening at the point of wipe, rather than the ROM flashing portion.

But that is just a working theory.

My guess is wipe/reset is using special emmc commands to do the reset while scripts like format_all are going through standard writes through the block device interface.
[Samsung Epic 4G Touch] robertm2011:
No worries, I'm contacting the insurance carrier shortly, so I'll be OK; REALLY appreciate the offer though.
[Samsung Epic 4G Touch] Esoteric68:
No problem.

Thanks for taking one for the team :)

---------- Post added at 09:41 PM ---------- Previous post was at 09:41 PM ----------

Understood. Then I'll hold off on anything further until you guys have more to go on.
[Samsung Epic 4G Touch] garwynn:
Very interesting. XDA app didn't let me move beyond the line so I am removing the post from URL to try again. The 2 posts describe give a valid reason why JTAG and other reformat solutions fail as well as come to a similar conclusion to the bug we're investigating.

Reading more but with the brick I think we should hold until get a response from Mr. Sumrall. If anyone has a direct line to Sammy please ask about the fwrev mismatching cid as well as the cid_rev parms. Still leaning towards this is our fix but bugged..
[Samsung Epic 4G Touch] sfhub:
Well we have an existence proof that either the fix doesn't fix what we are encountering or the fix isn't being applied to our phone.

I still don't understand from their description the mechanism of persistent/permanent damage to EMMC though.

If we do continue testing I would suggest eliminating Wipe Data/Factory Reset from the testing. Then at least if there are no further bricks, we can improve the situation from the current "flash back to GB" situation by replacing the wipe data/reset functionality with a straight filesystem format.
[Samsung Epic 4G Touch] garwynn:
Anyone with a friend that has any of the following devices or variant:

Galaxy S 2

Galaxy Note

Galaxy Nexus (ics one in case I have model name wrong)

Please try and get their cid values (split as mentioned by sfhub on 1st page) and cid string (straight cat cid). Let's see if we can pin down that fwrev... If 0x25 isn't out there but 0x19 is and the prevailing value it will support the idea that the fix is ours but bugged. The bigger we can make the sample set, the more confident we can be whether we are on the right track or not.

I think we're close.. Just need to get the remaining pieces in place and at the least try to report it to Samsung.

Update

Sorry, forgot to ask. For the brick, did anyone try to pull a logcat? We know from drnull you can temporarily restore functionality by remapping the data partition by gparted. Getting those logs may help as well, depending if they survive during the wipe.
[Samsung Epic 4G Touch] garwynn:
I should have posted the question as I posed it in the last reply to Mr. Sumrall. In short it gives the Hdd example (reformat) and asks why this nor JTAG can seem to clear the bad superblock(s).

At this point we have a better handle on this from observation; now let's see if we can get a technical (as detailed as possible) explanation. Anything to help prevent this and hopefully fix/patch the underlying cause...
[Samsung Epic 4G Touch] azyouthinkeyeiz:
Damn, my wife ended up pulling me from home tonight, and making me go out.

I just get home and see the bad news. Sorry, Robert. That sucks man. I hope you get it sorted out soon.

Also, on top of it being the wipe feature, as mentioned early on, it also happened immediately after flashing AOKP, but worked fine after non AOSP roms. So, it could technically still be a fix, but need code not present in AOKP?

It didn't brick until he wiped the data that was installed on the second attempt. The first two wipes were wiping modified stock ICS.
[Samsung Epic 4G Touch] sfhub:
So along those lines of thinking, Robert, what version of AOKP did you install and what kernel did it include?

Also can you boot into recovery with your phone.

If you can look in the /cache/recovery folder, sometimes there is a log file for what recovery did last.

Let's get as much post-mortem out of Robert's phone before he has to presumably return it.
[Samsung Epic 4G Touch] robertm2011:
I was booting AOKP Build 35 and it comes with an FE07 AOSP kernel.

As of tonight, I can't boot into DL mode or recovery, all I get is a black (as in non-functioning) screen and a persistent blue glow from the notification light.

If you all can think of a way to access the /cache/recovery folder, I'll give it a go.
[Samsung Epic 4G Touch] sfhub:
For the record, these were the id values for Robert's EMMC
[Samsung Epic 4G Touch] cerebralzulu:
related?

My ICS froze on me and I tried a clean install. Now my phone won't allow me to install ICS roms, from the stock with root or ASOP/AKOP. I tried the EL29 to FD24 OTA update as well. When I tried it I got an emmc error abortion (status 7). Not sure this is a corruption bug error as I can still get into odin mode and can still install gingerbread. If someone can help me to figure this logcat thing out I will post it.
[Samsung Epic 4G Touch] azyouthinkeyeiz:
After review, this was not related to our issues.
[Samsung Epic 4G Touch] Entropy512:
That info is a bit old - MMC_CAP_ERASE isn't it - turns out it's enabled in Gingerbread.

:(

However some other bug might be interacting with MMC_CAP_ERASE. What's interesting is that Sammy disabled TRIM (a relative of ERASE) in their latest M250* kernels - but that didn't fix it. Kind of a sign they may be aware of the issue but flailing.

The latest XXLPY update for Galaxy Note is questionable - one person hardbricked, many others are saying it is safe, I worry they may just be getting lucky. It'll be interesting when XXLPY source gets posted (it's official not a leak).
[Samsung Epic 4G Touch] cerebralzulu:
Check your PM please
[Samsung Epic 4G Touch] sfhub:
Thanks for chiming in here. It seems wipe data/factory reset is a common theme in the brick threads. It may not be the only way to trigger the problem, but it seems like it is involved. Have you guys investigated what functions wipe date/factory reset is performing?
[Samsung Epic 4G Touch] garwynn:
Absolutely sounds reasonable, but let's make sure that's the problem you're facing first.

If it were indeed the brick bug, the phone would just freeze and require a battery pull... Both on boot error and download.

If you're not seeing that in both cases - that's not it.

Can you send me the Odin flash log next time you try? And definitely consider a different cable as suggested.

We can also try flashing individual images to see if we can get recovery, system or userdata to take.
[Samsung Epic 4G Touch] Lanchon:
it can require some extra work. as i already said, the emmc could stop responding while reading some areas, JTAG or not. if that happens, it would require the operator to power cycle the phone, skip a guessed number of sectors, and continue dumping. you could also read backwards from the end, or just some partitions.

the point is that it may misbehave, and the operator has to want to do something about it and not just call it quits.

i9100 emmcs are known to fail from time to time. this has nothing to do with brickbug. brickbug is a bug in the implementations of the secure erase and secure trim emmc commands, and your OS never issued those. this is just a random failure.

i have talked to people with similar malfunctions out of the blue.

i have (remotely) tried two things:

1) i made custom PIT files that relocated the boot (kernel+recovery) partition to the area in the HIDDEN (ie: preload) partition (new end of storage) and also another near the beginning. the idea was to flash the PIT, then flash a kernel, then boot into recovery and dump the data. or repartition to skip the damaged area. or attempt a full emmc reset.

it didnt work. the emmc was locked in read only mode (the emmc firmware seemingly detected an unrecoverable problem and boot into that mode to let you at least read out the contents... say via JTAG). but i encourage you to google that xda thread and try the approach, it might work for you.

2) in another case, the emmc was read only too, but he was able to enter recovery. we attempted a full emmc reset (resize of the special bootloader partitions). this would have cured the emmc of damage caused by brickbug but is very dangerous because the bootloader is also wiped. if something goes wrong before you rewrite the BL, you need JTAG to recover.

it didnt work. the reset was totally ignored by the read-only emmc. curiously enough, the PIT flashing itself worked. and im willing to bet that flashes to the BL areas could have worked too. these areas of the emmc are treated in a more robust fashion and dont get handled by the same 'general' FTL in the emmc (which is what gets corrupted in these failed emmcs, i presume). you can google this thread if your are curious but you can't attempt this.

so there are your options. JTAG might fully work. if the emmc hangs, it would be better if you did the JTAGging yourself to avoid the problematic areas.
[Samsung Epic 4G Touch] vov120:
<ID:0/007> Odin v.3 engine (ID:7)..

<ID:0/007> File analysis..

<ID:0/007> SetupConnection..

<ID:0/007> Initialzation..

<ID:0/007> Get PIT for mapping..

<ID:0/007> Firmware update start..

<ID:0/007> boot.bin

<ID:0/007> NAND Write Start!!

<ID:0/007> Complete(Write) operation failed.

<OSM> All threads completed. (succeed 0 / failed 1)

<ID:0/007> Removed!!

In the past I tried it with different cables, usb ports, Odin versions (1.83 - 3.09) and even another PC.

I don't want to try to repartition the flash (at least meantime) as my main purpose is to retrieve the user data.