• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!
  • Fill out your device list and let everyone know which phones you have!    Edit Your Device Inventory

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

Status
Not open for further replies.
Search This thread

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
 
Last edited:
  • Like
Reactions: srmd

Entropy512

Senior Recognized Developer
Aug 31, 2007
14,095
25,088
Owego, NY
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

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.
 

nCoder

Senior Member
Mar 22, 2006
685
59
Dublin
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.

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:

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

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 ;)
 

Ueihtam

Senior Member
Jan 26, 2012
133
56
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

Senior Member
Mar 31, 2011
415
86
43
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

Senior Member
Dec 28, 2011
12,406
41,141
Novi Sad
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 ;)

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

jgaviota

Senior Member
Jan 4, 2008
383
63
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.
 

Entropy512

Senior Recognized Developer
Aug 31, 2007
14,095
25,088
Owego, NY
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.

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.
 

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 )
 

Dragooon123

Senior Member
Aug 18, 2008
1,052
112
National Capital Region(NCR)
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 )

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

Senior Member
Jul 1, 2011
718
86
Tarlac
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.

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

Senior Member
Dec 28, 2011
12,406
41,141
Novi Sad
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.

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

BBFreak

Senior Member
Oct 9, 2009
53
8
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.


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

Senior Member
Mar 22, 2006
685
59
Dublin
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.

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.

Top Liked Posts

  • There are no posts matching your filters.
  • 24
    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.
    15
    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
    No, no no NO - STOP talking about root. It COMPLETELY invalidates the test case in Samsung's eyes (even though it is totally irrelevant)

    So you ppl admit that the brick is connected to rooting?
    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.


    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
    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.

    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.
    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://forum.xda-developers.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 bullshit 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.
    10
    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.
    8
    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

    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.
    5
    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???