Samsung Developers - Hard Brick RFI (Samsung is working on it)

Status
Not open for further replies.
Search This thread
By:
Advanced…
nCoder

nCoder

Senior Member
Mar 22, 2006
685
59
Dublin
UPDATE

Samsung is now working to release a fix for this issue. Also glad to know Samsung is working closely supporting developers in this XDA community :)

More info here:
http://www.xda-developers.com/android/samsung-diligently-working-towards-hardbrick-fix/

Thank you to all members that helped contacting Samsung, and in a constructive way identifying the problem and report it in a professional way.

I hope Samsung is here to stay and work more collaboratively with this community ;)

Cheers!
____
Hi

Just received a response from Samsung developers on the topic, and need your help providing more details.

Please note that, you must only refer to scenarios using the STOCK Samsung ROM (not custom, cooked, rooted) and standard flashing methods (OTA or Kies).

If we're not able to provide this information, the case is closed.

http://innovator.samsungmobile.com/...Id=1&selectedSequence=00dgu030000~&viewMode=2

Hi,

We have failed to reproduce the bug, please provide a sure way to reproduce it, otherwise we won't be able to help.

While reading through the xda developers forum where this issue is discussed, I noticed that everyone reporting this is using rooted or leaked software. We cannot help you if you don't provide us with all the information - which software version? What are the exact steps?

Regards,
Adam Panasiuk
Samsung Developers
Click to expand...
Click to collapse
 
Last edited:
  • Like
Reactions: srmd
E

Entropy512

Senior Recognized Developer
Aug 31, 2007
14,088
25,086
Owego, NY
nCoder said:
Hi

Just received a response from Samsung developers on the topic, and need your help providing more details.

Please note that, you must only refer to scenarios using the STOCK Samsung ROM (not custom, cooked, rooted) and standard flashing methods (OTA or Kies).

If we're not able to provide this information, the case is closed.

http://innovator.samsungmobile.com/...Id=1&selectedSequence=00dgu030000~&viewMode=2
Click to expand...
Click to collapse

I've seen at least one report of XXLPY killing someone's device in stock recovery.

Also, Sprint was able to reproduce this on their devices (and apparently is deploying a fix) - I'll try to find more on that later.

"please provide a sure way to reproduce this" - ARE THEY KIDDING? If you reproduce this, YOUR DEVICE IS DEAD. One can't provide a sure way to reproduce a bug that you can test ONCE successfully. As stated by others, even a Google engineer himself, the fwrev 0x19 ERASE bug is intermittent and won't always happen. There is no "sure" way to reproduce this. However, this is a bug that was confirmed by Google during Galaxy Nexus development and we have confirmed that we have the same chip/fwrev as ones that Google experienced problems with in GNex prototypes.
 
  • Like
Reactions: Tyra Misoux, mikereidis, srmd and 1 other person
nCoder

nCoder

Senior Member
Mar 22, 2006
685
59
Dublin
Entropy512 said:
I've seen at least one report of XXLPY killing someone's device in stock recovery.

Also, Sprint was able to reproduce this on their devices (and apparently is deploying a fix) - I'll try to find more on that later.

"please provide a sure way to reproduce this" - ARE THEY KIDDING? If you reproduce this, YOUR DEVICE IS DEAD. One can't provide a sure way to reproduce a bug that you can test ONCE successfully. As stated by others, even a Google engineer himself, the fwrev 0x19 ERASE bug is intermittent and won't always happen. There is no "sure" way to reproduce this. However, this is a bug that was confirmed by Google during Galaxy Nexus development and we have confirmed that we have the same chip/fwrev as ones that Google experienced problems with in GNex prototypes.
Click to expand...
Click to collapse

I understand, but not proving evidence the bug exists in a stock rom, or reference to a reliable source (Do you have a formal statement from Sprint?) Even if the scenario is "Install ROM version N7000XXXLPx using Kies, then go to recovery and do this, then repeat XX times step 3, reboot, ...", we need to provide a scenario and examples of users that bricked their devices or else this channel to Samsung simply closes :(.

From what I understand, they are willing to break some devices to be able to confirm the problem.

Feel free to go to the link above and reply directly to Samsung ;)
 
Last edited:
J

joe2316

Senior Member
Jul 19, 2005
159
24
London
Weasels! I'm seriously disappointed that their "engineers" don't read up on the latest regarding their own devices....
 
musashiro

musashiro

Senior Member
Jul 1, 2011
718
86
Tarlac
one thing is for sure, if they can't reproduce it, they wont fix it and pretend that it has nothing to do with their roms..

same situation as franco on his kernel, he can't reproduce the wifi problem so he wont do anything.

i can't use a stock ics + cwm thinking that this bug is present...:(
 
nCoder

nCoder

Senior Member
Mar 22, 2006
685
59
Dublin
We just need as much information as possible.

This is a privileged channel to Samsung, and we should take advantage of this opportunity.

Complaining doesn't help. We need constructive ideas and reliable information ;)
 
U

Ueihtam

Senior Member
Jan 26, 2012
133
56
OnePlus 8T
Well, can just say one thing.

Long Live to CM9 and all CM based roms.

Seems that those will be the only safe roms for a long long time.

@nCode : Then go for it bro', break your phone and tell samsung what happend. I wont try to find a way to reproduce the bug except if they give me a Note to test on it.
 
GocaS6

GocaS6

Senior Member
Mar 31, 2011
415
86
45
Mostar
Well this gonna be challenging. Actually there's no exact way to reproduce hardbrick.
Maybe Entropy or someone of the guys that understand situation to the details should simply try to EXPLAIN what is actually going on... but i agree with Samsung developers it's hard to fix something when you can't reproduce the problem :(...
 
chasmodo

chasmodo

Senior Member
Dec 28, 2011
12,403
41,133
Novi Sad
nCoder said:
We just need as much information as possible.

This is a privileged channel to Samsung, and we should take advantage of this opportunity.

Complaining doesn't help. We need constructive ideas and reliable information ;)
Click to expand...
Click to collapse

Well, they could try this scenario on a dozen phones, and they will reproduce it:

1. install a GB Rom, root it
2. make a nandroid backup
3. flash official ICS Rom, get root
4. do several factory resets and cache wipes
5. attempt to do a nandroid restore from the CWMR

They are bound to brick at least one device on step 4 or 5.
 
Last edited:
  • Like
Reactions: SquirtingCherry
J

jgaviota

Senior Member
Jan 4, 2008
387
65
Yes, there is a sure way to reproduce the bug:

Take as many Notes as you can that have LPY or any official ICS, it doesn't matter how they got it.

Now factory reset them at least 100 times.

This is no joke, they can do it, it's quality assurance.
 
E

Entropy512

Senior Recognized Developer
Aug 31, 2007
14,088
25,086
Owego, NY
chasmodo said:
Well, they could try this scenario on a dozen phones, and they will reproduce it:

1. install a GB Rom, root it
2. make a nandroid backup
3. flash official ICS Rom, get root
4. do several factory resets and cache wipes
5. attempt to do a nandroid restore from the CWMR

They are bound to brick at least one device on step 4 or 5.
Click to expand...
Click to collapse

They won't accept this since it involves root and/or CWM.

I'll try to dig up the report of a user dying on stock recovery.
 
M

M3TALLICA

Senior Member
Nov 14, 2011
1,516
500
Why does not Samsung contact Mr Sumrall and other Google developers who worked on the Nexus?
 
musashiro

musashiro

Senior Member
Jul 1, 2011
718
86
Tarlac
i thought they support developers by supplying smartphones with unlocked bootloaders... they should support rooting and cwm in a way (even the slightest consideration for the betterment of stock )
 
D

Dragooon123

Senior Member
Aug 18, 2008
1,052
112
National Capital Region(NCR)
musashiro said:
i thought they support developers by supplying smartphones with unlocked bootloaders... they should support rooting and cwm in a way (even the slightest consideration for the betterment of stock )
Click to expand...
Click to collapse

That's not the point, if the bug can only be reproduced on a rooted/unofficial ROM then they can simply ignore it by saying that it's not a bug introduced by them. They're not liable for other people's mistakes.
 
musashiro

musashiro

Senior Member
Jul 1, 2011
718
86
Tarlac
Dragooon123 said:
That's not the point, if the bug can only be reproduced on a rooted/unofficial ROM then they can simply ignore it by saying that it's not a bug introduced by them. They're not liable for other people's mistakes.
Click to expand...
Click to collapse

and again, im just saying its like a "pathway" to fixing it and its proven to be present on official roms by Ken Sumrall..

sorry for not helping a lot, and posting chitchat...

im no big developer but whenever i troubleshoot, i make it to a point that i inspect every possible angle or scenario..

somehow reminds me of the quote "When you have eliminated the impossible, whatever remains, however improbable, must be the truth." :D

just my 2 cents on this
 
Last edited:
chasmodo

chasmodo

Senior Member
Dec 28, 2011
12,403
41,133
Novi Sad
Dragooon123 said:
That's not the point, if the bug can only be reproduced on a rooted/unofficial ROM then they can simply ignore it by saying that it's not a bug introduced by them. They're not liable for other people's mistakes.
Click to expand...
Click to collapse

But it's a way for them to ESTABLISH that there's something wrong with their kernels. If they want to, of course.

You can wipe everything, and do restores till you drop dead on rooted GB, and everything will be fine.

Not so on ICS, as we all know only too well.
 
Last edited by a moderator:
  • Like
Reactions: SquirtingCherry
EdgaBimbam

EdgaBimbam

Senior Member
Nov 26, 2011
2,559
1,134
Vilnius
www.google.lt
old news, everyone know/should know that samsung software support is peace of sh*t.. even if they will find that bug, they wont announce it because they dont want to reduce company reputation :/
 
BBFreak

BBFreak

Senior Member
Oct 9, 2009
53
8
Dragooon123 said:
That's not the point, if the bug can only be reproduced on a rooted/unofficial ROM then they can simply ignore it by saying that it's not a bug introduced by them. They're not liable for other people's mistakes.
Click to expand...
Click to collapse


This is very true. It needs to be something that "the average users" could recreate, meaning going through the "OFFICIAL" steps that Samsung put out. When I was developing for RIM/Blackberry we didn't support any custom software packages and the same thing when I was doing freelance development for Apple as we did NOT support and jailbroken software since it altered out factory coding....LOL.
 
  • Like
Reactions: nCoder
nCoder

nCoder

Senior Member
Mar 22, 2006
685
59
Dublin
Ueihtam said:
Well, can just say one thing.

Long Live to CM9 and all CM based roms.

Seems that those will be the only safe roms for a long long time.

@nCode : Then go for it bro', break your phone and tell samsung what happend. I wont try to find a way to reproduce the bug except if they give me a Note to test on it.
Click to expand...
Click to collapse

Nobody is asking to break anyone's phone. We just need reliable information either from people that bricked his phone using a stock ROM, or someone that understands and is able to explain the scenarios.
 
Status
Not open for further replies.

Similar threads

dr.ketan
[24sept12]How to Root/Unroot Samsung Galaxy Note + CWM
Replies
3K
Views
2M
N
notauseranymore
androidindian
Samsung working on Emmc brick fix
Replies
730
Views
267K
RovG
RovG
T
[REF] Samsung firmware naming convention and explanation
Replies
58
Views
270K
midoshbl1
midoshbl1
supercurio
  • Locked
Galaxy Note colour rendering issue: started working on it.
Replies
986
Views
226K
supercurio
supercurio
prabhu1980
  • Poll
Let's unbrick your phone - Guide (Soft Brick, Super Brick, Hard Brick, OTA Brick)
Replies
216
Views
182K
D
Deleted member 9635294

Top Liked Posts

24 Hours All time
  • There are no posts matching your filters.
  • 24
    E
    Entropy512
    There doesn't need to be any other case. We have all the proof we need now.

    I instrumented a kernel that would show if the stock recovery was attempting to use the mmc_erase() function during a wipe by printing an error instead of going forward with the erase - it does.

    Code: 
    <4>[   38.129797] mmc_can_erase: called
<4>[   38.129828] mmc_erase: mmc_erase() disabled for protection. from = 2293760, nr = 4194272, arg = 1
<3>[   38.129879] end_request: I/O error, dev mmcblk0, sector 2293760
<6>[   40.220059] pet_watchdog_timer_fn kicking...be65
<6>[   42.860276] sec-battery sec-battery: sec_bat_check_vf: Battery Health (1)
<6>[   42.860946] smb328-charger 19-0034: smb328_get_charging_health : charging status A(0x02)
<6>[   42.861601] smb328-charger 19-0034: smb328_get_charging_health : charging status B(0x00)
<6>[   42.862250] smb328-charger 19-0034: smb328_get_charging_health : charging status C(0x05)
<6>[   42.862296] smb328-charger 19-0034: smb328_get_property: smb328_get_property (2,1)
<6>[   42.934618] EXT4-fs (mmcblk0p1): mounted filesystem with ordered data mode. Opts: 
<6>[   43.094984] lcd panel: s6e8ax0_check_fb, fb2
<6>[   43.225179] lcd panel: s6e8ax0_check_fb, fb2
<4>[   43.226739] mmc_can_erase: called
<4>[   43.226769] mmc_erase: mmc_erase() disabled for protection. from = 106496, nr = 409600, arg = 1
<3>[   43.226817] end_request: I/O error, dev mmcblk0, sector 106496
    (full dmesg attached).

    I'm in the process of uploading the source for the test kernel and initramfs used - the initramfs is 100% stock except for enabling ADB in recovery so the dmesg could be pulled. The only kernel changes are build fixes and rendering the kernel safe by disabling mmc_erase()

    Edit: Kernel repo is at https://github.com/Entropy512/n7000_erasetest_kernel/commits/master
    Most important commit for this test is: https://github.com/Entropy512/n7000_erasetest_kernel/commit/c9b5be55339417831a507de9e41a0493113c8076 - All other commits are just cleaning it up so it will actually build. Samsung broke their Makefile by hardcoding stuff they shouldn't have, as usual.

    Initramfs repo is at - https://github.com/Entropy512/n7000_initramfs_dangerous/commits/master - Bone stock XXLPY other than:
    1) Adding placeholder files in empty directories. The kernel build script removes these at build time. (git doesn't like empty directories...)
    2) Enabling ADB during recovery (can't collect the dmesg attached without this).

    At this point we have proof positive that Samsung's stock kernels have all three of the prerequisites for eMMC damage:
    1) The data I just collected proves that their stock recovery attempts to execute mmc_erase() if permitted to do so. (Note that removing MMC_CAP_ERASE blocks the erase process earlier in the call chain than mmc_erase() - in this case I left MMC_CAP_ERASE enabled but disabled mmc_erase() itself.)
    2) Their kernels have MMC_CAP_ERASE set in the MSHCI host driver, which permits attempts from userspace to issue an ERASE command to succeed and send ERASE commands to the eMMC chip
    3) It's been proven that nearly every shipped GT-N7000, SGH-I777, GT-I9100, and SPH-D710 has MAG4FA, VYL00M, or KYL00M fwrev 0x19, which is proven to be unable to handle ERASE commands.
    View
    15
    E
    Entropy512
    sujal said:
    From whatever little knowledge that I have, I think its the kernel that makes things work on the device. Rooting DOES NOT affect the kernel. I don't know about CWM though, I think it does.

    So, if I were Samsung, I would rather do this:

    1. Get a brand new note, running GB.
    2. Root it. (Warranty gone but kernel still unaffected).
    3. Flash official ICS ROM, get root.
    4. Several factory resets and wipe from stock recovery.

    If I get a brick, its some kind of a problem with Samsung and Samsung should fix it, if not then I don't think Samsung should be blamed. Rooting does not do anything but to give you root privileges. Its what you do with the privileges that matters.

    The only counter argument to my own argument I have is if rooting does not do anything, we should be able to get hard bricks on unrooted devices too, right? Its all too confusing. :/

    Sent from my GT-N7000 using XDA
    Click to expand...
    Click to collapse
    No, no no NO - STOP talking about root. It COMPLETELY invalidates the test case in Samsung's eyes (even though it is totally irrelevant)

    opsakas said:
    So you ppl admit that the brick is connected to rooting?
    Click to expand...
    Click to collapse
    No, it doesn't have jack **** to do with rooting. It happens during a wipe in recovery. The recovery binary is in the initramfs, which is packaged with the kernel - All of the prerequisites for danger are fundamental aspects of the device that can't be changed (the eMMC model and fwrev) or are entirely located within the kernel image (either the kernel itself or the initrams).

    What is in /system is completely and totally irrelevant - rooted or not, it just doesn't matter. Period.


    jimmod said:
    I don't think we can find hardbricked galaxy note user that never root his phone posting their issue on xda-developers or maybe on internet.
    Those people will just directly go to Samsung Service Center and replace their board (warranty).

    So this debate will going nowhere
    Click to expand...
    Click to collapse
    Yup. The sample size of people who wipe in stock recovery is small to begin with - people running bone stock just don't wipe often. In addition, people who damage after wiping on bone stock are just going to go get warranty service, they're not going to come here.

    opsakas said:
    The problem is that the ICS works reasonable well in its predefined framework.
    The hardbricks that happen are due to the fact that root or custom ROM messes up the balance of that framework.

    Any software engineer knows that system works always as whole. You change parameters and you can end up with a crash of that system. Actually, it is like that with any system, not only software.

    Now the real problem is that some ppl keep telling that other ppl will definitely brick their phone when upgrading ICS even if these phones are always been stock. This is unacceptable. I would call it even a lie.

    What I see is that unfortunately ICS by Samsung on Galaxy Note is not fully compatible with root and custom ROMs. And the price of that uncompatibility is basically new phone. That also means that some ppl do not want to take any responsibility for their work. Even if thats for free.

    So once again, in the framework provided by Samsung, I see only working phones.
    In a framework that has been changed by third parties, I see some bricked phones.

    And, of course, the problem is solvable if these ppl create their own framework where everything works just fine. That means, kernel, bootloader (if necessary), all additional software that make up a custom ROM.
    It is always hard for any 'god' to come back to Earth. Sorry.
    Click to expand...
    Click to collapse
    You, sir, are an idiot. You are sitting here claiming that it has something to do with rooting or customization when all of the technical data collected over the past 2-3 weeks says otherwise. You are apparently completely and totally uneducated as to the nature of this problem and what causes it.
    1) We have code review of Samsung's kernel showing that it passes ERASE commands to the eMMC chip if the recovery asks it to
    2) We have documentation from a Google engineer that the eMMC chip and fwrev present in nearly every shipped N7000 is a fwrev that is documented as having a problem where it can't reliably handle ERASE commands. Google themselves encountered the bug during Galaxy Nexus development (and forced Samsung to upgrade the firmware in GNex devices)
    3) On the previous page, I established the third and final component - Stock recovery attempts to issue ERASE commands during a wipe, which WILL reach the eMMC chip if the kernel doesn't block it.

    While Samsung claims they can't reproduce the bug - Sprint can. http://xdaforums.com/showthread.php?p=26465085#post26465085
    (I commend Sprint for acknowledging the bug and working on deploying a fix.)

    While I realize the technical description of this issue may be difficult for some people (including, obviously, yourself) to understand - if you don't understand it, shut the hell up and stay silent, don't go around spouting completely untrue and baseless bull**** which is completely and totally wrong.

    Put your money where your mouth is. If you seriously and truly believe that Samsung's stock ICS releases for this device are safe despite all of the evidence that says otherwise:
    Verify that your eMMC chip is VYL00M, KYL00M, or MAG4FA fwrev 0x19 - nearly all devices shipped are in this configuration, but if you happen to have a rare device that isn't one of these, the test is invalid
    Install bone stock XXLPY. Use it a bit - install some apps, go through the setup process so /data has some content in it.
    Then enter stock recovery and do a wipe data/factory reset
    Since the issue is intermittent (as documented by Mr. Sumrall himself), repeat this 20-30 times (Including making sure that /data is not empty - ERASE commands on an already-erased partition might be safe.)

    Do it, or shut up and stop claiming that XXLPY is safe if it hasn't been customized - BECAUSE IT IS NOT SAFE.
    View
    10
    reinbeau
    reinbeau
    Think before you post

    Have any of you questioning the facts read this thread with all of the information that's known (that's real, confirmed information, not idle speculation as I've read here)? Have you read the Portal post, where Ken Sumrall, an actual Android kernel developer, discusses and confirms all of what Entropy512 has posted?

    Those of you who are irresponsibly (in my opinion) disputing the researched information posted by experts in the field are going to cause others to hard brick their devices. I don't care if you have flashed 12 times, or 24, or whatever. Others absolutely have experienced the issue and have ended up with expensive repairs - why on earth would you want to cause even more?

    This thread should be an informational discussion, not somewhere where idle speculation is given any credibility at all.
    View
    8
    E
    Entropy512
    Zamboney said:
    If i recall correctly Entropy verified from the official Samsung ICS sources that the ROM was issuing the buggy erase command. Isn't that proof enough together with the fact that 0x19 firmware can destroy the flash using that command?

    Sent from my GT-N7000 using Tapatalk 2
    Click to expand...
    Click to collapse

    We got more information from Mr. Sumrall, and to brick requires three components:

    1) Buggy eMMC firmware, specifically MAG4FA or VYL00M fwrev 0x19 (KYL00M fwrev 0x19 probably also affected). Confirmed on basically every Samsung Exynos device with 16GB storage. The bugginess of fwrev 0x19 was confirmed by Google during Galaxy Nexus development, and Samsung fixed the firmware in released GNex devices. However they continue shipping known defective MAG4FA/VYL00M fwrev 0x19 in Exynos devices.
    2) MMC_CAP_ERASE enabled in the kernel - confirmed for everything but I9100 Update4 sources - If it's disabled, mmc_erase() will error out if called.
    3) A recovery that causes mmc_erase() to get called in the kernel - This was added by Google to improve privacy (a normal partition format doesn't actually erase your data) in ICS. Robotu semi-confirmed this - later this week I'll work on fully confirming it by instrumenting a kernel to safely trap mmc_erase calls and print when they occur without issuing ERASE commands to the MMC chip. This upstream change by Google is why Gingerbread is apparently safe.
    View
    5
    V
    vijai2011
    Ok I'm ready to brick my phone by ICS and find out what causes it.But for that I need official samsung support(If possible) and support from members like entrophy,ncoder snd others who can guide me to make the brick in a usefull manner.

    Ok guys lets get it rolling for the cause of XDA.....I will sacrifice my device...(Oh cant imagine how I'm goin to live without my note :'( )Will I be able to claim warranty after my device gets bricked???
    View

New posts