Samsung working on Emmc brick fix

Search This thread
By:
Advanced…
androidindian

androidindian

Senior Member
Nov 16, 2010
1,844
809
New Delhi
More info and source credits here, thanks to codeworkx https://plus.google.com/111398485184813224730/posts/21pTYfTsCkB.


ATTENTION:
We've contacted Samsung about the problem where performing a mmc erase could hardbrick your phone (i9100, i9100g, n7000, m250 - MAG4FA, VYL00M, and KYL00M with firmware revision 0x19 // T989 and I727 with fw rev 0x12) if it's having a faulty emmc chip.
Read this thread for more informations about it: http://forum.xda-developers.com/showthread.php?t=1644364

They're working as hard as possible on a clean solution which will be ready soon.

Please be patient and try to not flash any leaked kernels or kernels based on sources where MMC_CAP_ERASE is present.

This app http://forum.xda-developers.com/showpost.php?p=27014974&postcount=1 can be used to identify if your phone is affected or not.

CM9 kernels are safe to flash.

Please share!

Update 14:56 CEST:
Patches will be out in form of new official ROMs and also sourcecode releases after testing, which might take some time.
Click to expand...
Click to collapse

New Clarifications by Entropy : http://forum.xda-developers.com/showpost.php?p=28416723&postcount=403 - Must Read.

To check whether your phone has the brick bug, download the Got Brickbug app from Chainfire: http://forum.xda-developers.com/showthread.php?t=1693704

Also do read the article on xda for more info.: http://www.xda-developers.com/android/samsung-diligently-working-towards-hardbrick-fix/
 
Last edited:
  • Like
Reactions: hbb0810, ad_slev, fido747 and 48 others
C

calvincarlos

Member
Apr 25, 2012
40
5
Good news!
Looking forward to see how Samsung solve this nightmare

Sent from my GT-N7000 using xda premium
 
gominolo2002

gominolo2002

Senior Member
Dec 25, 2010
282
44
Madrid
How many time to fix this Samsung BUG? How maby people need ti brick our 600€? If samsung knows why no first before? Grrrrr...

All hard work its from XDA devs!!!! Thank you devs!!

Enviado desde mi GT-N7000 usando Tapatalk 2
 
nandihno

nandihno

Senior Member
Jul 22, 2010
1,011
99
Brisbane
Hmmm don't want to get my hopes up
But hmmm ok let's hope saw but how do we know is true ?


Sent from my iPad using Tapatalk
 
R

ripnetuk

Senior Member
Aug 25, 2006
118
16
So to be clear...

Can someone confirm the following is correct please?

I have a N7000 on official (german) ICS, with the dodgy mmc chip. I must have been lucky since ive flashed a bunch of roms (including CM9, back to gingerbread, then official ICS) without issue. Ive also done a few CWM backup and restores... phew!

1. Flashing anything from the phone itself (eg using mobile odin or CWM recovery) is a no-go (assuming it issues the erase command)

2. Flashing from the PC is OK ??? (via desktop ODIN)?

If 2 is untrue, how is sammy gonna issue an update (with the erase capability turned off) without bricking a load of phones during the update process? can they maybe provide a custom app which re-flashes the kernel without doing an erase first?

thanks

George
 
nandihno

nandihno

Senior Member
Jul 22, 2010
1,011
99
Brisbane
ripnetuk said:
Can someone confirm the following is correct please?

I have a N7000 on official (german) ICS, with the dodgy mmc chip. I must have been lucky since ive flashed a bunch of roms (including CM9, back to gingerbread, then official ICS) without issue. Ive also done a few CWM backup and restores... phew!

1. Flashing anything from the phone itself (eg using mobile odin or CWM recovery) is a no-go (assuming it issues the erase command)

2. Flashing from the PC is OK ??? (via desktop ODIN)?

If 2 is untrue, how is sammy gonna issue an update (with the erase capability turned off) without bricking a load of phones during the update process? can they maybe provide a custom app which re-flashes the kernel without doing an erase first?

thanks

George
Click to expand...
Click to collapse

Flashing is not the problem but wiping is
So if they release a new update then simply don't wipe on your ics but wipe only after you install the new update
If however you want to be extra careful like I am
Flash a gb rom via odin then wipe that then flash said ics update via Odin


Sent from my iPad using Tapatalk
 
  • Like
Reactions: tsam19
C

cyberpingu

Senior Member
Apr 23, 2011
53
1
Firenze
While there have been brickage reports using either PC Odin or CWM, there have been none regarding Odin Mobile Pro. So, when I flashed back GB, I used Odin mobile Pro. Everything went smooth.
 
altae

altae

Senior Member
Mar 22, 2008
1,413
222
St. Gallen
I really hope this mess will soon be over. Let's hope while they are resolving the brick bug they also take a look at the wakelock thing. Contrary to others I have encountered this problem very rarely (1 time so far). Nonetheless it would be nice to see a solution.

Sent from my Galaxy Note running ICS
 
  • Like
Reactions: Braxos
T

tribalkg

Senior Member
Feb 12, 2011
73
18
Kragujevac
Good news but given that we haven't seen ics roll out in all countries, who knows when this will get fixed.

Another thing that bugs me. Is there possibility that Samsung push the solution for this bug and carriers just ignore it and continue with pushing the infected ics?

I guess that all we need is just one good release and everyone can flash it.

Hope to see it soon.

Sent from my Samsung Galaxy Note using XDA app
 
ashoksoft

ashoksoft

Member
Dec 5, 2007
19
6
ripnetuk said:
Can someone confirm the following is correct please?

If 2 is untrue, how is sammy gonna issue an update (with the erase capability turned off) without bricking a load of phones during the update process? can they maybe provide a custom app which re-flashes the kernel without doing an erase first?
Click to expand...
Click to collapse


In all probability it might show a message over kies / OTA message asking to connect to kies on the comp .. and provide an update for kies desktop :) having 0din in it :)
 
You must log in or register to reply here.

Similar threads

dr.ketan
[24sept12]How to Root/Unroot Samsung Galaxy Note + CWM
Replies
3K
Views
2M
N
notauseranymore
hg42
PIT file method to revive your phone from a MMC_CAP_ERASE brick
Replies
1K
Views
415K
kraken77
kraken77
T
[REF] Samsung firmware naming convention and explanation
Replies
57
Views
265K
T
Thomas280574
supercurio
  • Locked
Galaxy Note colour rendering issue: started working on it.
Replies
986
Views
224K
supercurio
supercurio
prabhu1980
  • Poll
Let's unbrick your phone - Guide (Soft Brick, Super Brick, Hard Brick, OTA Brick)
Replies
216
Views
179K
D
Deleted member 9635294

Top Liked Posts

24 Hours All time
  • There are no posts matching your filters.
  • 60
    E
    Entropy512
    I am sooo fried after the meeting. It was quite long.

    Bad news: It turns out that the repair process turns eMMC chips from "damaged" to "completely toast" pretty often. As a result Samsung understandly does not want to release the info to the "wild" as it can easily kill a device if used improperly. Example - if a user thinks they have eMMC damage when they don't, and then tries to repair it - they have a high likelihood of making the problem worse. I strongly recommended that they talk to the RIFFbox team and a few JTAG repair specialists so that at least they have a chance of bringing these devices back - JTAG repair services have the technical skills and equipment to make a reliable determine on whether to perform a "last resort" attempt of fully wiping/resetting the eMMC.

    Samsung is 100% certain that non-secure erase as implemented by their stock recovery is safe. I still have concerns that in rare cases it can do damage, but unfortunately, every user that has reported eMMC damage caused by stock recovery has either sent their device back for warranty service already, or fell silent when asked for more information. There are also simply not many reports of this - maybe 4-5 on Note, and 4-5 on other devices two weeks ago when a bunch of ICS updates went out to other devices. Without more evidence, there is simply nothing I can do here.

    There is of course, the issue of kernels permitting secure erase commands through when they shouldn't - I think they finally realize how many ways that a secure erase command can be triggered, and how it is critical that secure erase is blocked by the kernel. They are working on deploying a fix to newer kernels that will take secure erase commands and replace them with nonsecure erase, so at least protection will improve.

    I would feel more comfortable if erase commands were completely blocked, but there is simply not enough evidence of problems with non-secure erase to have Samsung change their opinion on its safety.

    What is interesting is that there seem to be a lot of issues with internal communication within Samsung. In some cases it could be language barrier issues. It was apparently never clear to my contact that this was seen as long ago as December/January by the Epic 4G Touch community. Also, at least some of their engineers are swearing up and down that MMC_CAP_ERASE has always been enabled in the I9100 - even though we know without any doubt that it has been absent in I9100 builds previous to XWLPM and XXLQ5. There's a possibility this may have been a miscommunication somewhere - because someone saw MMC_CAP_ERASE in sdhci.c, they said the kernel had it - but what matters is whether it is present in mshci.c

    In general, I think this whole mess is a no-win situation for everyone involved. The only really good thing to come out of it is - my contact at Samsung is working with the XDA administrators to open up more communication channels so that if something like this happens again, it'll be caught earlier.

    I still have a bunch of followup I need to do in terms of getting them some additional information... but for now, I'm exhausted.
    View
    51
    androidindian
    androidindian
    More info and source credits here, thanks to codeworkx https://plus.google.com/111398485184813224730/posts/21pTYfTsCkB.


    ATTENTION:
    We've contacted Samsung about the problem where performing a mmc erase could hardbrick your phone (i9100, i9100g, n7000, m250 - MAG4FA, VYL00M, and KYL00M with firmware revision 0x19 // T989 and I727 with fw rev 0x12) if it's having a faulty emmc chip.
    Read this thread for more informations about it: http://forum.xda-developers.com/showthread.php?t=1644364

    They're working as hard as possible on a clean solution which will be ready soon.

    Please be patient and try to not flash any leaked kernels or kernels based on sources where MMC_CAP_ERASE is present.

    This app http://forum.xda-developers.com/showpost.php?p=27014974&postcount=1 can be used to identify if your phone is affected or not.

    CM9 kernels are safe to flash.

    Please share!

    Update 14:56 CEST:
    Patches will be out in form of new official ROMs and also sourcecode releases after testing, which might take some time.
    Click to expand...
    Click to collapse

    New Clarifications by Entropy : http://forum.xda-developers.com/showpost.php?p=28416723&postcount=403 - Must Read.

    To check whether your phone has the brick bug, download the Got Brickbug app from Chainfire: http://forum.xda-developers.com/showthread.php?t=1693704

    Also do read the article on xda for more info.: http://www.xda-developers.com/android/samsung-diligently-working-towards-hardbrick-fix/
    View
    25
    E
    Entropy512
    Right now, things aren't entirely definite, but it looks like I am probably going to be having a face-to-face meeting with Samsung next week.

    They are unwilling to provide AdamOutler with what is required to repair devices with damaged bootloaders, but we at least will be slightly better off than we were before.

    This is what is currently being discussed since USB-booting (See Unbrickable Mod for Galaxy S1/Nexus S devices - We are missing a small but critical component for Unbrickable to be deployed on Galaxy S2 family devices) is not something they are willing to discuss even though I feel it is necessary to deploy a proper solution to end users.

    1) A solution will only be available for users whose devices can still boot a kernel. If a device has a damaged bootloader or the kernel partition is damaged, these devices will be unrepairable by users. It may become possible to recover these devices via JTAG.
    2) The solution will require wiping the chip, repartitioning, and then repopulating bootloaders all in one go. This is going to have a very high failure rate - after all, even merely overwriting the bootloaders in an OTA (see Captivate Froyo and T-Mobile Nexus S ICS upgrade fiascos) often can kill a device - we have to wipe the chip, power cycle the eMMC chip from the kernel and reinitialize the MMC subsystem, repartition the chip, then rewrite the bootloaders.

    The little bit of good news is that at least these devices will become recoverable via JTAG (which they currently are not). The bad news is that a reliable solution will not be deployable to end users - a partial unreliable one will be, but I fully expect it to fail and require JTAGging for many.

    I'm really pushing for more, but it's not looking good.

    So the summary right now:
    If your device boots but is missing chunks of storage, we will possibly be able to fully restore the device
    Devices in the category above that fail to fully repair will have all storage space back, but will require JTAG to boot again
    Devices that do not boot will still require JTAG, however it should become possible for JTAG shops to repair the damage
    View
    22
    E
    Entropy512
    An update: Our conference call last night went very well. I'm now 90% certain we will, at the very least, be able to turn "superbricks" into JTAG-recoverable "traditional hardbricks". Everyone is hopeful that some developers will be receiving this information sometime next week (do note that it is going to take some time to develop this information into a deployable solution - how long really depends on what I will discuss below.)

    This is of course not ideal, since it means the device is still bricked (but at least repairable using known methods), but we've made our case to Samsung why it is highly beneficial to everyone involved if the bits and pieces required to make Unbrickable Mod available for Exynos4 devices are provided. With that information, we will not only be able to fully recover "superbricked" devices to operational state, but will be able to recover many traditionally hardbricked devices to an operational state too. (Unfortunately, depending on the nature of traditional hardbricks, some may require resistor modifications to start the process. The "superbrick" recovery process fully wipes everything, so the device will USB-boot without any resistor mods.)

    One caveat: Right now, the process of recovering from a superbrick will ALSO nuke your EFS partition. EVERYONE who is able to should make a backup of their EFS partition to their PC (or at a bare minimum, an external SD card) ASAP! Those who have lost their EFS partition to Superbrick damage are in a unique and unfortunate situation, there are some possible paths for recovery here though that the ERD community, XDA admins, and a few others are looking into. The problem is that regenerating the EFS can change a phone's IMEI, which presents unique ethical and legal challenges.

    As to being stuck on GB - as long as you use a safe kernel (such as Speedmod, Franco's kernel, or the CM9 kernel) you should be fine.
    View
    17
    E
    Entropy512
    breckbit said:
    At least hardwareside, samsung keep on replacing bricked mobo´s with the same vulnerable eMMC chipset / 0x19 - as they did in my case. for my sake they replaced it as case of warranty.

    is there any possibility at all - in case samsung develope it - to update the eMMC firmware?!
    Click to expand...
    Click to collapse
    To my knowledge, not without fully wiping the chip, including the bootloaders. This will turn your phone from "superbrick" to "traditional hardbrick" - which is at least JTAG-recoverable. However Samsung will not release the information required to do this, nor will they give Mr. Sumrall permission it seems.

    prasad.adam said:
    At the moment, there is a mystery around extremely low failure rate on virgin stock ROM vis-a-vis rooted ROM.

    Entropy512 is working on unraveling the same. Hope he gets some concrete lead on the same. Patience till then.
    Click to expand...
    Click to collapse
    Yeah. I have the explanation why, the problem is I have been asked not to share it by the source. I'm in the process of drafting a response to said source that includes a bit of yelling... It explains why the damage rate is different between stock recovery and CWM - however the damage rate for stock recovery, while lower, is nonzero.


    abhijit038 said:
    Yes you are right my friend. NO ONE HAS bricked on official NON ROOTED ICS.
    When I ask for citation to add credence to their claim of Stock non ROOTED ICS being buggy, I always get blank response.


    Sent from my GT-N7000 using xda premium
    Click to expand...
    Click to collapse
    PRESENCE OF THE su BINARY IN SYSTEM DOES NOT MATTER. IT DOES *NOTHING* WHEN YOU ARE IN RECOVERY. ONLY KERNEL AND INITRAMFS MATTER THEN.

    You obviously don't even remotely understand how recovery works, such as the fact that everything in recovery runs directly from an initramfs image that is packed into the kernel itself. What is present in /system simply does not matter - if a brick happend with stock kernel and Samsung stock recovery, that is enough to prove that configuration is dangerous because the contents of /system do not matter. Especially not the presence of an su binary, considering that RECOVERY ALWAYS RUNS WITH ROOT PRIVELEGES!!!

    Arobase40 said:
    First, forgive for my english which if far from perfect and may not reproduce my real thoughts...

    The problem is even if one knows there is a emmc bug, nobody knows for sure where it's located and how if works, in order to reproduce the effect...
    I've tried to read all informations and posts about this bug but there were some many sparse threads, so it's hard to follow them all. ^^
    Click to expand...
    Click to collapse
    Bullshit. We know where it's located and how it's triggered. It's in the flash chip, it's triggered by ERASE commands sent to the flash chip.

    I may be not an expert at emmc, but at least an "old" dev (but not yet retired ;) ) (and among other occupations), and that's the first time I encountered such a bug that causes intermittent flaw on the way a bug is supposed to be working. :D
    Click to expand...
    Click to collapse
    Considering even the Google engineer that described the bug said it's intermittent, this isn't a surprise.

    If was first explained the MMC_CAP_ERASE flag (and CONFIG_MMC_DISCARD, CONFIG_MMC_DISCARD_MERGE, and CONFIG_MMC_DISCARD_MOVINAND set) could be the true cause of the bug, but that doesn't explain why in the same condition GB doesn't cause bricked or corrupted devices, nor why removing the MMC_CAP_ERASE flag is not enough to solve the problem (except maybe with ICS for i9100, but why ICS and not GB ?) ???
    Click to expand...
    Click to collapse
    Please read before spouting utter and total bullshit. It has already been explained by Mr. Sumrall why Gingerbread doesn't cause bricks - Gingerbread recoveries and update-binaries don't attempt to do wipe commands. That's how Chainfire has rendered recent CF-Root releases "safer" to use with affected kernels, and how CM9 has taken measures to reduce the chances of damage when flashing CM9 now that there is much more information about the bug.

    And you clearly are completely uninformed if you think MMC_CAP_ERASE removal doesn't protect from damage - there has not been a single incident of the bug triggering from someone confirmed to actually be running a "safe" kernel. The one person who bricked after flashing Franco R3 with Mobile Odin never verified the flash before dropping into recovery - and MO is rather notorious for occasionally failing to flash.

    It was also explained than erasing large files could also brick or corrupt some devices (only with internal or also with external storage ?), the reason I asked Entrophy, in another thread (Epic 4G Touch), why the MMC_CAP_ERASE flag was not removed from sdhci.c from latest ICS source code for i9100 and there was no problem... I now sdhci.c is dealing with external SD Card, and I haven't got time to develop my explanation not to study the whole source code, but I was wondering if it was using a complete different instructions set to do the erase/Trim operation or if at a time or another it was not also calling some instructions from emmc and so the incriminated firmware... Does that also mean there are 2 totally different source codes to deal with internal storage or external storage ??? ^^
    Click to expand...
    Click to collapse
    It was never "explained" that erasing large files could also brick - it was just speculated in the early days before Mr. Sumrall provided valuable information about the bug. Erasing large files is safe because none of our file systems are mounted with the "discard" flag. (Yeah, I need to update the PSA in this regard, it's a bit outdated now...)

    There are not two totally different source code bases to deal with internal and external storage - it's 90% common code. However the host driver is where there are differences, and the SDHCI host driver is only used for the external SD card and the wifi chip (SDIO). The internal storage is the MSHCI driver. The capabilities flags are in the source code for the host driver.

    This is just to explain that since "we" can't find a quick and reliable solution through the codes "yet", at least "we" could try to find indirect explanations by other means...
    Click to expand...
    Click to collapse
    You're severely misinformed if you think we can't find a quick and reliable protection solution... Preventing ERASE commands from reaching the chip is semi-reliable if done in userspace, and 100% reliable if done by blocking ERASE attempts in the kernel. (I consider failures to flash a safe kernel in the first place not to be a failure of the kernel itself.)
    View

New posts