yashsingh1/xdaforums huggingface dataset:
[Galaxy Note GT-N7000 General] travis82:
it could but tbh ive given samsung a bricked cm9 note and my wifes and they dont care one year warrenty is one year warrenty is what they told me.
[Galaxy Note GT-N7000 General] lindvalll:
Great news!
[Galaxy Note GT-N7000 General] dbreloaded:
If the phone hard bricks i think even Samsung will have a hard time telling if it was rooted or not. We should be careful of the advice we give as i can see there are some really lucky people who have wiped many times without the problem however a large number of people have actually bricked their phones doing this. From what i understand of what the devs are saying all official ICS kernels are effected whether rooted or not. Best way to avoid bricking your note? Do nothing at all until the new firmware is released with the bug fixed. Don't root or wipe or flash or even delete massive files as all of these things are speculated to cause the problem. Dont get me wrong i cant even begin to fully understand the complexity of this problem but i can follow the easily accessible advice provided by the devs and experts on this forum. They have done extensive research for us on this matter and we should be super thankful to them. Imagine just wiping your device and it bricks and not knowing why? Imagine how worried you would be? These guys have found the cause and I really appreciate it.
[Galaxy Note GT-N7000 General] musashiro:
finally someone who understands the situation...:D
[Galaxy Note GT-N7000 General] Zlacker73:
i was running rom "KingDroid_ICS_NoteMania_Edition_v2.1" did a wipe data/Factory reset with no problem,Flash rom RocketROM ICS LPY V3 did a wipe data/Factory reset and did not boot efter that.Can't get eny rom running stock/custom rom true Odin/CWM don't matter what i do.CWM error E:Can´t mount /emc/.Is this the "Samsung BUG Brick"?
[Galaxy Note GT-N7000 General] onehundredbullets:
Call me paranoid, but I don't care if 1,000 people have successfully wiped 100 times. The fact that the EMMC fault exists means that I won't be wiping unless I'm on a safe kernel.
[Galaxy Note GT-N7000 General] musashiro:
if you flash a GB rom, does it get stuck on factoryimg? or somewhere??

i think that your situation is the classic brick bug .
[Galaxy Note GT-N7000 General] Zlacker73:
Yes it freeze in the beginning of "factoryimg".Tried PIT: Q1_20110914_16GB-patched.pit and PDA: N7000XXLPY_N7000OXALPY_N7000XXLPT_HOME.tar.md5 and it worked ones but no more.
[Galaxy Note GT-N7000 General] musashiro:
thats a super classic brick my friend..:(

i hope you still have warranty..
[Galaxy Note GT-N7000 General] prasad.adam:
+1.
[Galaxy Note GT-N7000 General] prasad.adam:
Don't want to put your efforts down, but it is obvious from Google kernel developers response (and devs out here) that Samsung exynos eMMC chip with fwrev 0x19 has a serious problem handling erase command. Once they upgraded fwrev to 0x25 , GNexus did not have issue while wiping. Since note has the same chip and same fwrev it is only logical that upgrading fwrev to 0x25 or later should put this issue to bed, once and for all.
[Galaxy Note GT-N7000 General] volvo940seturbo:
So why oh why if Samsung were aware of the issue with the galaxy nexus did they go and do the exact same thing with the note??? This issue seems to be also on other Samsung devices with the same chip, so surely an update to the chip would as with the nexus cure the issue, and if so why do Samsung need to work on the issue, instead of just fixing it. I spoke with Samsung UK yesterday about the issue, and was told there was no such issue with any Samsung device. Seems very strange that they would claim this then tell the devs they are aware and working on a fix for it. I asked Samsung to send me a letter confirming no such issue which they refused to do. Which in my opinion means they know full well about the issue but don't want to let their customers know this, just in case like myself they want to return or have their devices replaced.

I feel very let down by Samsung over this issue, if they had the balls to admit to it and let everyone know there is a fix on the way fine, but to make out there is nothing wrong is not good for customer relations.
[Galaxy Note GT-N7000 General] PoisonWolf:
It boils down to cost (if the motherboards were already placed into phones, it means that they needed to individually flash the phones which would be expensive as hell in terms of the number of man hours needed for the job). CEOs want the manufacturing process to be as cheap as possible to rake in profits. All companies do this.
[Galaxy Note GT-N7000 General] senectus:
Unfortunately all I would expect from Samsung is to remove the trigger from the kernel. I doubt this will be a proper fix.

For everyone not loading custom roms, this will work fine but I suspect loading a new firmware will be too difficult or expensive.
[Galaxy Note GT-N7000 General] prasad.adam:
Man hours you refer to are needed to come up with generic fix across board. Once that's done it's a matter of managing their build & packaging process. Don't seem to me like a substantial effort.
[Galaxy Note GT-N7000 General] smsmasters:
I just did a factory format *2767*3855# and it went well! No problems!

My phone is unhacked and on the official LQ2 UK ICS ROM.
[Galaxy Note GT-N7000 General] dr.ketan:
Once it was wiped sucessfully, it doesn't mean you are immune

it can brick even after 15 wipe too. Or many time it won't show this time, if smthing error happens, It can appear next time when you flash.(odin stuck at data.img/factoryfs) so just dont make test, wipe only if ithere is genuine reason.
[Galaxy Note GT-N7000 General] Entropy512:
Not true. The existence of the a method for repair/update was first hinted at by Ken Sumrall months ago:

Now, when we all read this, we assumed the underlined comment meant "gotta JTAG it if it fails" - After talking with Samsung, it turns out, easily more than 50% of the time, something DOES go wrong and it's not just "you need to JTAG it" - it's "the chip is totally and completely fried now" - While it's not how we initially interpreted Ken's words here, this is also consistent with his wording.

That's the main problem - the repair process completely kills a large percentage of chips even when done by a trained engineer in the lab. Samsung is, understandably, scared ****less of putting this in the hands of users, many of whom will probably decide they are Superbricked when they're not, and then killing their devices unnecessarily.
[Galaxy Note GT-N7000 General] garwynn:
Not that I'm sure you're able to elaborate on that but did they determine the cause of the physical damage? It seems so... random, which is hard to find in this kind of stuff. Unless, of course, "killing" or "frying" the chip just means that the memory state is so corrupted or unknown where even if a hard reset by the controller is possible.

Sorry, I know you have a lot more info than I do - but I remember before I started asking Mr. Sumrall about this that people told me the eMMC lockup damage was truly physical in nature and I was bewildered at that time as well. There are a few things that I can think of that would damage electronics - high EM, heat, physical damage (drop/hit), and power surges - but it piques my curiosity to think that a command from the embedded controller could cause any of those.
[Galaxy Note GT-N7000 General] dekelm8:
you're right ....

In case of the "hard break" we all talking about in this post, The JTAG cannot fix the issue because there is no way to complete format the emmc and repartition it.

The partition via ODIN (using PIT file) just repartition the emmc but still you're not loosing your data, so i'ts mean you're not format it completely.

I think to fix the problem you just need to make real repartition of the chip and make "full format" (by full format i mean to erase the sectors records too) and you cannot make do it right now with any JTAG box.

And not with any other tool even not with adb because all of the existing ways are using USB, and n to do that you must use JTAG.

But as i know the guys from JTAG are working on way to make "plugin" that can do that, like they do for other devices that already have it.

If they will success to do that -> you can fix your emmc problem with only JTAG, and you're not must to replace the emmc chip like i did.

One more thing: i don't think that you can really "fried" your chip because i had some "shorts" when i connect it in the first time and after split the wires good, i'ts works fine (even after the chip get worm because that shorts)

and you always can use the safest method and solder a connector on the PCB board and then using the adapter for it, so no damage can happen to your chip in any case.
[Galaxy Note GT-N7000 General] PaulF8080:
It's a ram disk. There are no physical sectors. The partition table is in the ram in logical block address zero (LBA 0) and could maybe written with JTAG.
[Galaxy Note GT-N7000 General] garwynn:
No but there is a command that can reset the eMMC. Just don't know if that does the trick and that info may not be able to be shared..
[Galaxy Note GT-N7000 General] Eric-Mod:
But if the Emmc would be reset, would I need a JTAG for that??
[Galaxy Note GT-N7000 General] dekelm8:
Yeah my mistake I ment partition table but some how wrote sectors.

Anyway right now there is now way to rewrite that.
[Galaxy Note GT-N7000 General] dekelm8:
There is NO way to make REAL format to emmc right now... "delete" the data is not format.
[Galaxy Note GT-N7000 General] Entropy512:
I'm fairly certain this is the case - see jetmarc's stuff below. If the process is interrupted at the wrong time, the chip goes into la-la-land and can't be brought back out. Maybe "frying" is the wrong word, even though for all practical purposes it's fried/dead. Think of it as an even lower-level form of hardbrick - you've corrupted it so badly that it just immediately locks up before you can even get it in a state where you can reload it.

This wouldn't surprise me - there is likely a way the factory can program/configure chips that is not available once the chip has been soldered to a board. Also, this alternative programming method is probably something the memory division guys think is even more highly proprietary than the commandset to do a fullchip wipe/firmware upgrade via the standard eMMC interface.

For example, the chip may have a JTAG interface for boundary scan/testing purposes that can also do initial factory reprogramming, but is not part of the system JTAG chain (and may not even be wired to any PCB traces) when the chip is installed in a final system.

Kind of like how Atmel AVRs become unprogrammable via in-system programming (ISP) if you accidentally burn the wrong fuses, but there is a special "high voltage programming" mode available that can resurrect AVRs killed in this way - but HVP can NOT be done when the chip is installed in-system.

Yeah, I think the problem is that between "erase whole chip" and "reprogram" there's an extremely dangerous gap. We previously thought this was just a state in which the phone was traditionally hardbricked (no bootloaders) but it's starting to sound like it often results in the chip being so badly "bricked" that you can't talk to it over the eMMC interface.

That's an interesting thought - whether it is possible to load a special eMMC firmware image into SRAM that allows for partial damage repair without doing a full-chip wipe... I'm guessing it probably isn't for various reasons. We will almost surely never know as these are going to be closely kept secrets by the memory/storage division. (My contacts have been with the mobile division - just like any large company, frequently divisions within a company don't necessarily get along, and I'm fairly certain the mobile guys do NOT like the storage/memory guys. The mobile division may be under intense pressure to stick with in-house suppliers, and the storage guys know this and use it to get away with murder. I've personally seen this happen at other companies on a regular basis.)
[Galaxy Note GT-N7000 General] garwynn:
I may have misunderstood previous discussions but I thought the only way known to resolve this - assuming the "superbrick" is more accurately the block of memory becoming an unknown state - is to reset the entire eMMC. The command is there to do it - but there are some obvious issues even if you find a way to trigger it:

1) You have to load NVRAM data and a bare minimum set of binaries (bootloader, odin mode) to SRAM in order for this to even be possible. This in itself isn't hard compared to some of the other steps.

2) The JEDEC standards mentioned that if a timeout occurs and an error is triggered that a power cycle is sometimes required. Hit one of these errors and without a way to capture it, bypass the power cycle requirement and at least reload certain data back onto the eMMC it's game over. (Looked again and couldn't see from the eMMC specifications whether the reset command had any conditions or is susceptible to the timeout like the erase commands are.)

And double-check the mail from me a few months ago - while you and Adam were working the Mobile contacts I got ahold of storage and they said that Mobile has the ownership for mobile eMMC products and to please ask Mobile. Might be worth asking your contact about...
[Galaxy Note GT-N7000 General] jetmarc:
Yes, the single most probable reason is that they won't help us. And the second most probable is that maybe it's not so important after all.

I'm sure it is possible to crack the riddle with just the information available (and lots of patience). But then again, my own Note is not affected yet (knock on wood). And if it went dead, I'd probably get a Note2.

If someone prepared one of those EMMC chips (good or superbricked doesnt matter) reliably soldered to a breakout board with 2.54mm access to all relevant pins, then I could probably figure it out. I'm good at reversing, but not so much at managing my time (so stay clear who is desperate!).

---------- Post added at 06:02 PM ---------- Previous post was at 05:49 PM ----------

Todays part of the talk isn't about the phone and the EMMC. Rather it's about the MCU, SRAM and the NAND array inside the EMMC chip. Those form a system on its own. Reread with this context for the characteristics I assume this system to have, and sorry for confusing.
[Galaxy Note GT-N7000 General] garwynn:
OK, so for the purposes of this discussion we are talking about the individual components inside the eMMC only. Didn't know about the SRAM inside there - thought the specs only mentioned a controller and a storage array, which I suspect is the NAND array you are mentioning. Glad you guys are willing to be patient with some of us lacking the experience :)

Wouldn't the MCU (assuming controller) have to normally follow the command structures in the JEDEC eMMC specification? If so, could you possibly elaborate, at least in your experience, how the reset command would function? My reading of this was that it could reset the state of even unknown memory back to a clear state - something that could possibly be read or written to.

It's an older version but I suspect it's not that different between the 4.4 and 4.5 standard:

http://rere.qmqm.pl/~mirq/JESD84-A44.pdf

I thought I had seen a command there that resets the entire card state but apparently I am mistaken as I can't find it again.
[Galaxy Note GT-N7000 General] jetmarc:
Sure: https://bitbucket.org/franciscofranco/android-tuna-omap/changeset/cea631bdac53/raw/

The value 0xD20228FF looks suspiciously like

cmp r0,#0xff

bcs there

...

...

...

there:

...

The other value 0x000000FF looks suspiciously related to that interpretation, too.

There also seems to be code to dump firmware, which is necessary to analyse where to hook, to learn how to do IO and raw array access inside the chip, and also to make sense of the existing data structures. We could also compare vulnerable firmware to fixed firmware, highlighting which portions are relevant for the damage mechanism.
[Galaxy Note GT-N7000 General] garwynn:
That's what I thought - this is the same change that got the discussion moving forward again and ended up getting us a good deal of info. Let me dig into the emails from Mr. Sumrall and see how he described it.

If you want, PM an email address and I'll forward what I can of the discussion. I can give you for certain the exchange between myself and him - when it involved others I'll have to get permission.
[Galaxy Note GT-N7000 General] PaulF8080:
It is all guessing because there no debug of a brick. I find it very hard to believe that the eMMC spec is implemented in FW. I worked on an interface that was infinitely more complicated (QPI)and it was implemented with Verilog. Verilog is a HW description language not FW. Just because the eMMC spec is very complicated does not mean it needs FW to implement. That's my guess and I'm sticking to it.
[Galaxy Note GT-N7000 General] friedje:
So why various generations of this very same chip have different FW versions ?

Since there is no FW according to your beliefs. ;)
[Galaxy Note GT-N7000 General] garwynn:
Paul,

JEDEC standards specify the requirement for an embedded controller as part of the eMMC package, thus why a standardized command set. (Edit: At least as far as I have read and understood it - I can certainly be wrong here as proven already today)

(Sentence following this removed as it was offensive and did not take into account Paul's background and experience, which is far, FAR more than mine in these matters. My apologies for posting it in the first place and hope this will not detract from the discussion any further. )

---------- Post added at 01:32 PM ---------- Previous post was at 01:21 PM ----------

Refresher: Back and Forth with Mr. Sumrall (5/22/12)

Bold is me, non-bold is Mr. Sumrall's response:

A couple of things if I re-read this:

1) I suspect this is what jetmarc and Entropy are suggesting can only be done once (maybe CMD26 is a part of this?). But if so how did they develop a patch for it in the first place to update to revision 0x25? And if it was that unstable did they burn through a lot of chips or GNex phones just to fix this for Google to continue their kernel development? That seems awfully... cost insensitive.

2) Don't know if what Mr. Sumrall is mentioning is the same thing that Entropy was given access to. It's never been definitively confirmed nor can I assume it will be.

Regarding the fix mentioned above, on 5/8:

It was my thinking at the time that this was being patched into RAM outside of the eMMC (since I thought it didn't have any usable RAM, just the controller and storage) - but if I put it into context as jetmarc suggested then I can see that his analysis makes more sense to me.

Question though: Would you have to re-patch the eMMC firmware again upon wake if indeed the patch took place in the SRAM (perhaps this is like a cache?) for the eMMC?
[Galaxy Note GT-N7000 General] PaulF8080:
When the QPI spec is printed out, it is an inch thick. We did the embedded controller in Verilog. Intel paid me so I guess I made my living that way. What's your point? The two hex digits for the chip revision in the CPU id referred to the chip stepping which included Verilog changes, speed enhancements etc. In my world there was very wide instruction microcode for things that were slow, but not for high speed interfaces. If you don't like my guess that's fine with me. Try not to make it personal, though.
[Galaxy Note GT-N7000 General] garwynn:
Thank you for the clarification - I've made it more than clear that I'm the amateur in the group. You are certainly right to criticize those remarks and I was wrong to post that, no matter what your opinion or background was. (Actually in this case it embarrasses me far more than you for clearly showing ignorance and a lack of knowledge on the subject)

I will revise that statement with an apology immediately.

As for further comments from me I think I'm better off holding any further comments/questions for now while the experts in the room hash out the more technical aspects. I've made myself look stupid enough for the day, no?
[Galaxy Note GT-N7000 General] Mario1968:
Hi Paul, what do you think about this fix/code? Is enough to prevent the eMMC brick? And what about the bricked devices, can this code used to revive those devices?

Sorry for the noob questions, but I prefer to know the expert thinking about this fix.

Thank you

Mario

Inviato dal mio Galaxy S2 con Tapatalk2®

XWLPF Stock

Siyah 4.1.5

Jkay V14.1
[Galaxy Note GT-N7000 General] aletheus:
+1

you guys have a few readers trying to wrap their heads around this problem. superbricked my p6800 a couple of weeks ago.... it was like loosing a pet.....

definitely interested in understanding this problem here.
[Galaxy Note GT-N7000 General] PaulF8080:
Please do not be be embarrassed. I always tell people HW debug is a very weird job. You are wrong 90% of time. Debuggers always have their own guesses. The rules are: there are no stupid guesses and listen to everyone. I was trying to get off the FW is borked track.
[Galaxy Note GT-N7000 General] Entropy512:
I wasn't given access to anything. The original hope was that Samsung and I would be providing this information when we met - but the guy working with the fix (He was at the meeting) was experiencing a very high failure rate. I think back in Korea he had a fairly large pile of dead chips. (They had an I9100 and an N7000 with socketed eMMC. It was pretty cool tbh.)

The problem is we'll likely never know exactly what Google had access to and if it even was the same as what the storage/memory guys gave to the engineer that was at the meeting with myself and my primary contact. (There were a total of three Samsung people there.) This stuff is all considered highly proprietary by the storage guys and there's also clearly a lot of issues with internal coordination/communication at Samsung (even within the same division, let alone cross-division.)

The eMMC standard allows vendors to implement proprietary extended commands, the update/repair process likely used one of these. (I'd link to the relevant kernel patch but I can't find it at the moment... drivers/mmc has a LONG changelog...)

The internal controller within the eMMC (which translates MMC commands into whatever the underlying memory technology understands) appears, based on all of these patches, to have SRAM. It seems like it shadows its firmware image to SRAM on powerup. You won't see anything about this in the JEDEC spec because this is all internal manufacturer-specific implementation stuff.

That code will do nothing for the eMMC bug. Here's a summary of what we know from Ken for the VYL00M/MAG4FA:

Fwrev 0x19 has two bugs - one that can cause the eMMC's internal data structures to get severely corrupted when a secure erase is issued (Superbrick), and a second one where the wear leveller will occasionally insert 32kb of zeros that shouldn't be there.

Fwrev 0x25 has one known bug - the 32kb of zeroes one (it's immune to the secure erase issue). The patch that is changing the firmware in SRAM is issuing a fix for this bug. It won't fix the secure erase bug and in fact cannot be applied to fwrev 0x19.

The problem is, we know for a FACT that it is the firmware that is borked.

Seriously, you, as an I717 owner, could fire secure erase commands at your eMMC all day long without ever worrying, because all I717 units that shipped contained updated eMMC firmware that is immune to this bug.
[Galaxy Note GT-N7000 General] garwynn:
I want to bring this up again because I'm noticing something that

might

be explained away by this.

Lately on flashes people are reporting random hangs - and it's not quite certain what the cause is. But if I think about the possibility for corruption by the above WL bug... a corrupted apk could definitely cause it to crash.

So if people are noticing odd behavior with an application it may be worth reinstalling just to make sure this bug isn't to blame. Just a thought for consideration.....
[Galaxy Note GT-N7000 General] alvinasnow:
Well.... looks like all this 2-3 months wait is gonna go astray. I am losing hope to find any solution for my superbricked eMMC. The best thing is that now, people have stopped giving us hope too :(