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

Status
Not open for further replies.
Search This thread

nandihno

Senior Member
Jul 22, 2010
1,011
99
Brisbane
as a seniour app dev too..
i respect what the Samsung engineers are asking.
it is not that ROOT is the cause for the bricks
but with ROOT you may give access to things that the kernel was not intended to do under normal circumstances.

I have wipe cache and wipe system on stock on ICS LPY and on LPF with no root..and have not had a problem (had flashed 4 times stock ICS (trying LPY then LPF then LP9 then LPF again)

so ppl take this as an opportunity..because it sounds like they are listening...for once and if anyone has bricked their devices with no root...
then simply send them a logcat.
 

porcusor

Senior Member
Mar 29, 2010
116
26
Bucharest
as a seniour app dev too..
i respect what the Samsung engineers are asking.
it is not that ROOT is the cause for the bricks
but with ROOT you may give access to things that the kernel was not intended to do under normal circumstances.

I have wipe cache and wipe system on stock on ICS LPY and on LPF with no root..and have not had a problem (had flashed 4 times stock ICS (trying LPY then LPF then LP9 then LPF again)

so ppl take this as an opportunity..because it sounds like they are listening...for once and if anyone has bricked their devices with no root...
then simply send them a logcat.

lol how to send logcat with their bricked device? also logcat requires root from what I know.
THey should just reach out to samsung on the link the OP posted. If they only go to service centers they will get their mobo replaced and that's it. It's easy to ask someone who just damaged their pricey device to try and do some additional steps to help others as they are busy with crying over their bricked Note. But maybe there are a few out there who are willing to help..
 

nandihno

Senior Member
Jul 22, 2010
1,011
99
Brisbane
lol how to send logcat with their bricked device? also logcat requires root from what I know.
THey should just reach out to samsung on the link the OP posted. If they only go to service centers they will get their mobo replaced and that's it. It's easy to ask someone who just damaged their pricey device to try and do some additional steps to help others as they are busy with crying over their bricked Note. But maybe there are a few out there who are willing to help..

you can get logcat printed via connecting your phone via adb to eclipse and android plugin has the ability for you to view logcat
the icon for it even has flying cat in eclipse ! lol :D
 

porcusor

Senior Member
Mar 29, 2010
116
26
Bucharest
you can get logcat printed via connecting your phone via adb to eclipse and android plugin has the ability for you to view logcat
the icon for it even has flying cat in eclipse ! lol :D

lol the samsung support guys know about this? I wish.. OK, now we're waiting for someone who actually bricked their device in standard circumstances.. will be a long wait...
 

M3TALLICA

Senior Member
Nov 14, 2011
1,516
500
We don't need to argue or provide any info to these people. They will keep whining about root.
Read entropy's last post, Samsung fixed the bug in gnex fw.
But they still continued sell other devices with same **** emmc fw, kernels and recoveries that triggered the bug.
I hope a lot of people get to know this and samsh!t apologizes publicly.
 

andreww88

Senior Member
Aug 6, 2011
1,301
297
Mobile, AL
www.andrewsthoughts.net
as a seniour app dev too..
i respect what the Samsung engineers are asking.
it is not that ROOT is the cause for the bricks
but with ROOT you may give access to things that the kernel was not intended to do under normal circumstances.

I understand Samsung can't cover users who root because of warranty issues. I understand that totally. And I'm pretty sure ROOT is not the cause of the bricks. I agree with you it may give access to the things in the kernel that do cause the bricks. So my thing is, Samsung should still take ownership and at least fix the bug for those users that DON'T want to remain stock, at least just to keep them around longer and keep them buying Samsung phones.

Just my thoughts.
 
  • Like
Reactions: chasmodo

loloudoudara

Member
Feb 29, 2012
42
15
Software engineer here too. I think what would help in the interim would be the bug fix details to the gnex. If we cant consistently reproduce the bug, we could still integrate the gnex fix to the galaxy note kernel.
 
Last edited:

praetorius

Senior Member
Feb 3, 2012
535
103
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.

Their concern is stock, untouched mobile and firmware. And since this complain is localized in XDA, most of the devices have had a history of flashing non-official roms or rooted. Samsung will have none of that since the fault could somewhere be in the previous flashing procedure or how the rom was 'cooked'.

Zapped through server hops to XDA forums
 

chasmodo

Senior Member
Dec 28, 2011
12,403
41,133
Novi Sad
Their concern is stock, untouched mobile and firmware. And since this complain is localized in XDA...

This complaint is not localized to XDA. XDA is the biggest forum for English-speaking users. There's lots and lots of local Android forums for guys who do not speak the lingo. And this bricking tsunami hit them pretty hard too. I remember a Russian guy posting here that they have had 30-odd ICS bricks reported in a matter of a couple of days in one of the Russian forums.

...most of the devices have had a history of flashing non-official roms or rooted.

And those non-official ICS releases were leaked by whom...? By you and me?
So, Samsung leak b0rked stuff, then they sit back and watch the mess, and in the end claim that it's OUR fault for using something they have leaked themselves in the first place? That's business ethics, I suppose?

Samsung will have none of that since the fault could somewhere be in the previous flashing procedure or how the rom was 'cooked'.

A lot of users got their bricks on stock rooted Roms. And stock Roms were cooked by Samsung, were they not?
 

praetorius

Senior Member
Feb 3, 2012
535
103
This complaint is not localized to XDA. XDA is the biggest forum for English-speaking users. There's lots and lots of local Android forums for guys who do not speak the lingo. And this bricking tsunami hit them pretty hard too. I remember a Russian guy posting here that they have had 30-odd ICS bricks reported in a matter of a couple of days in one of the Russian forums.



And those non-official ICS releases were leaked by whom...? By you and me?
So, Samsung leak b0rked stuff, then they sit back and watch the mess, and in the end claim that it's OUR fault for using something they have leaked themselves in the first place? That's business ethics, I suppose?



A lot of users got their bricks on stock rooted Roms. And stock Roms were cooked by Samsung, were they not?

Can you point me please to an incident where an untouched Note bricked while on official ICS? Thats what they are trying to isolate. Tainted devices and firmwares are not the responsibility of samsung.

Leaked firmwares are just that.... Not meant for the general population.

Dont get me wrong, im all for the resolution of this fiasco. But samsung devs has a point when they cannot replicate the issue on untouched Notes. So, as far as they are concerned, the bug may exist but does not wreak havoc to unmodified units.

Zapped through server hops to XDA forums
 

biliskner

Senior Member
Mar 10, 2006
305
34
London
Xiaomi Mi 10 Ultra
Can you point me please to an incident where an untouched Note bricked while on official ICS? Thats what they are trying to isolate. Tainted devices and firmwares are not the responsibility of samsung.

Leaked firmwares are just that.... Not meant for the general population.

Dont get me wrong, im all for the resolution of this fiasco. But samsung devs has a point when they cannot replicate the issue on untouched Notes. So, as far as they are concerned, the bug may exist but does not wreak havoc to unmodified units.

Zapped through server hops to XDA forums

Well said. I want a resolution to this also. But all bricks have first had their device rooted (then custom rom, and cwm whatever). As ncoder pointed out, we need a stock gb to stock ics, and without rooting. If I remember right, zergrushing my device was at my own risk, so Samsung of course is not going to zerg rush any of their devices to reproduce the bug. That's not to say the bug is nonexistent, it's just Sammy won't do nothing about it....because they don't play starcraft.

It seems the only 2ways about this is:
1. Petition. We go ape about it and force their hand this way.
2. We go through the Android dev who confirmed this bug.

Or... Find an actual post of someone **Non Rooted** using Kies or whatever Sam uses to upgrade gb to ics.

Sent from my GT-N7000 using XDA
 

Alexanderbooth

Senior Member
Apr 5, 2011
437
38
Original poster!!!!! If no one comes forward can you not just ask them to install the German ics, then tell them to wipe the device in recovery 10 times. If that doesn't cause the brick for them then maybe something that is left behind by people flashing other stuff is causing the issue.
 

musashiro

Senior Member
Jul 1, 2011
718
86
Tarlac
Can you point me please to an incident where an untouched Note bricked while on official ICS? Thats what they are trying to isolate. Tainted devices and firmwares are not the responsibility of samsung.

Leaked firmwares are just that.... Not meant for the general population.

Dont get me wrong, im all for the resolution of this fiasco. But samsung devs has a point when they cannot replicate the issue on untouched Notes. So, as far as they are concerned, the bug may exist but does not wreak havoc to unmodified units.

Zapped through server hops to XDA forums

whats wrong with you people?? i posted a link where a person on LP9 got bricked.... check it out..
 

nCoder

Senior Member
Mar 22, 2006
685
59
Dublin
Original poster!!!!! If no one comes forward can you not just ask them to install the German ics, then tell them to wipe the device in recovery 10 times. If that doesn't cause the brick for them then maybe something that is left behind by people flashing other stuff is causing the issue.

I understand that they did that already, also using several devices and several ICS ROMs. :(
 

Alexanderbooth

Senior Member
Apr 5, 2011
437
38
whats wrong with you people?? i posted a link where a person on LP9 got bricked.... check it out..

Havent they rooted or flashed other roms previously though? Thats the smoking gun we need to tinkering wth the phone at all.

---------- Post added at 10:06 AM ---------- Previous post was at 10:00 AM ----------

I understand that they did that already, also using several devices and several ICS ROMs. :(

Oh ok I see sorry, well ist this starting to get a little fishy then, how can it be samsung if its only happening on phones that have been messed around with? I have no idea about this stuff I just come on here to read cause im interested, I don't flash roms I just root and update via mobile odin, so I have no idea about how it all works really. Isn't there something else that could be causing the issue?
 

Markuzy

Senior Member
Apr 21, 2012
529
120
Singapore
As I have read through the numerous threads about this, the issue is that there is a probability of a fatal brick, perhaps Samsung didn't test on a large enough sample size. In fact like mentioned in previous posts, the brick does happen on stock unrooted.

Sent from my GT-N7000 using Xparent ICS Tapatalk 2
 
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://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.
    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???