yashsingh1/xdaforums huggingface dataset:
[Samsung Epic 4G Touch] monoko:
If I would have problem with my eMMC it would be 1st thing to try after finding out obout this bug. without count=1

dd if=/dev/zero of=/dev/mmcblkxx bs=64k

careful this will erease everything on that XX partition.

bs (block size... I thing bigger better, up to max size the driver can send it. I guess no more than 4k.

But I give it 5% chance to help you with that bug.

Ok I am going to test dd and some algos to find bad block. (there is unix binary called dd_rescue which is designed to work around broken HDD, but with eMMC freezing it will not help much.
[Samsung Epic 4G Touch] drnull:
Just to clarify on this point: in this post I listed what finally worked. Basically, I went from having a 2gb datafs partition and a 12.4gb UMS (internal sdcard/emmc/whatever-cm9-happens-to-be-calling-it-in-this-release) to having a 2gb datafs partition and 10.1gb.

DATAFS was: 923MB-3070MB (2147MB)

UMS was: 3070MB-15.4GB (12.4GB)

I had problems accessing anything from 1070MB through 3070MB (923MB - 1066MB was fine, but way too small for the DATAFS partition).

So I removed the DATAFS and UMS partitions and recreated them as:

DATAFS: 3070MB-5217MB (2147MB)

UMS: 5217MB-15.4GB (~10.1GB)

Technically, I recreated the UMS partition as 5217MB-12.4GB in error, but I'm sure 5217MB-15.4GB would have worked fine.

TL;DR

The Data partition was still 2GB, but I lost 2GB of the 12GB available for internal storage, which I wasn't willing to put up with - so I returned it after getting it back to stock (but still locking up).
[Samsung Epic 4G Touch] garwynn:
I haven't asked but I wonder if the position in memory where it locks up is random or fixed - now that others are trying this same method on the int'l Note and it seems to come back to life I've been looking at the breakdown - 1070 would fall in the range of storage area overlapping between our data partition and their system partition.

But one other question (if you remember) - did it freeze the phone when you started poking in the "bad area"?
[Samsung Epic 4G Touch] monoko:
Anyone wants to find how much of the flash is damaged?

You need lots of time and wroking busybox then send PM. to find first block you can use.

dd if=/dev/block/mmcblk0 of=/dev/null bs=1024 & watch -n 1 kill -USR1 $!
[Samsung Epic 4G Touch] musashiro:
sorry for asking (im wondering if i misread anything)

what makes you think Europe devs are aware of it? if that is the case, then its a very good sign..
[Samsung Epic 4G Touch] garwynn:
Small update

I've fired off another change request to Samsung Open Source with the information provided by Mr. Sumrall and asked them to incorporate into any ICS builds for the GS2, Note and any variants. Also hinted that the f/w update would be nice to have but I doubt they have any control on that.
[Samsung Epic 4G Touch] drnull:
YES, extremely frustrating. Any operation into the bad area would lockup (dd, parted, etc), requiring a restart. That's why I didn't narrow it down to the actual bad section - once I found something that worked, I went with it and stopped poking.
[Samsung Epic 4G Touch] Entropy512:
Original GalaxyS devices use a completely different flash architecture.

I need to check on my Infuse, but I think you might be looking at the fwrev of your external SD. (Internal flash/SD is not on an MMC interface.)
[Samsung Epic 4G Touch] Entropy512:
Samsung has been aware of this issue since prior to November - yet they are still shipping devices with fwrev 0x19. At least one Note user got a device back from repair with a new motherboard and it was still fwrev 0x19.
[Samsung Epic 4G Touch] Entropy512:
That position would be a lie, as the following publically released firmware revisions trigger the bug:

GT-N7000 XXLPY, ZSLPF, DXLP9

Also, the Korean SHW-M250S/K/L sources trigger this bug, so we can assume the official binaries do too.
[Samsung Epic 4G Touch] Entropy512:
Correct. I believe what is meant by "calibration data" is the EFS partition.

So if you have a good EFS backup or JTAG can read the EFS data - we just need item 3) (which we don't have currently.)

I believe 1) would be achieved by disabling MMC_CAP_ERASE in the host driver - I'm fairly sure now that this is why I9100 update4 is safe.

Some investigation of 2) will, I believe, tell us why Gingerbread kernels are safe despite MMC_CAP_ERASE being enabled - the recovery's make_ext4fs may not use the ERASE ability even though the driver has it enabled. I'm going to look at recovery source code (both vanilla AOSP and CWM) for differences along these lines this weekend.

This leads me to ask - I remember seeing people talking about bricking with CWM Touch recovery in the past - was this only ICS kernels, or did this ever happen on Gingerbread kernels repacked with CWM Touch?

It might point to there needing to be three things, all combined, for someone to experience this bug:

1) A recovery binary that triggers calls to mmc_erase() (Theory: Gingerbread recoveries don't, which is why they're safe. If CWM Touch was bricking on GB kernels this is more evidence)

2) A kernel that has MMC_CAP_ERASE enabled. If it doesn't, 1) becomes irrelevant because mmc_erase() will never do anything (This is why I9100 Update4 is safe)

3) MAG4FA, VYL00M, or KYL00M fwrev 0x19
[Samsung Epic 4G Touch] garwynn:
True - and as you mentioned they very well may not have been talking about this issue within the individual teams. For example, I'm sure not everything you do gets passed on to other project teams, especially if it was previously assumed to be unrelated. So we know it's at Sammy HQ level now, I've sent something separate to the Open Source team, Mr. Sumrall's working his connections and obviously so is Sprint. AT&T I suspect knew about this because their Notes are shipped with the updated firmware - and seem to be the only case other than the Nexus line.

As being seen with the E4GT they know how to patch the wipe to avoid the lockup (at least that's what I think they're doing instead of f/w update)... now it's just a matter of getting other ICS official builds patched and resolve any bricked devices with customers. That should close the issue unless they decide to look at Jelly Bean - but doubt that will happen officially.

---------- Post added at 06:06 PM ---------- Previous post was at 06:00 PM ----------

Answer was provided by Mr. Sumrall on this - GB is 100% safe because the code didn't exist. (We knew it from experience but didn't know why until explained below)
[Samsung Epic 4G Touch] TerryMathews:
True. I guess I was thinking specifically about the ET4G since that's the forum we're in.
[Samsung Epic 4G Touch] Robotu:
K! I will wait! I trust you and i think you know what you say...!
[Samsung Epic 4G Touch] slick_rick:
So in layman terms (lol) are we getting closer to a possible fix, work around, etc? Thanks guys.
[Samsung Epic 4G Touch] sfhub:
Thanks for the clarification, I must have read an earlier post where you (or someone) had initially got it working with a small /data partition.
[Samsung Epic 4G Touch] musashiro:
one developer on note made a safe kernel by Removing MMC_CAP_ERASE. its franco kernel..:)
[Samsung Epic 4G Touch] prabhu1980:
Is it possible to dump the newer emmc firmware and flash it to the old fw.

I read in n900 maemo forum flashing firmwares.....

thought it might help. ...
[Samsung Epic 4G Touch] musashiro:
update on one of the unconfirmed "safe" kernels around where they removed MMC_CAP_ERASE.

the circumstances of how the bug is triggered gets blurry and blurry as users experiment on their device... damn it, samsung, what are you doing? i hope this bug gets fixed on update 4 of the source... lets hope so..
[Samsung Epic 4G Touch] MR.change:
**** ,see I told you that I'm not convinced it's the MMC_CAP_ERASE that's causing the issue .

I think we need to remove the mmc_erase lines that MR.sumaril describes in his post as well.

Is that Franco kernel ? Hardcore also got his speedmod kernel with MMC_CAP_ERASE disabled so let's see how this unfolds.
[Samsung Epic 4G Touch] globalm:
I don't think any conclusion can be srawn until controlled experiments can be carried out. The wording of the post by eRode is ambiguous and he has not yet had an opportunity to clarify or respond to questions.

We need to continue the brave sacrifice of innocent SGNs until the questions are answered!

However, only one thing should be changed at a time so let's see if eliminating MMC_CAP_ERASE has a statistically significant effect.
[Samsung Epic 4G Touch] sfhub:
Is the Samsung Note kernel source indexed and available to search online? Can someone post the area of code/call chain controlled by MMC_CAP_ERASE that shows mmc_erase() won't be called.

Also for the benefit of others, can someone post what the various names should "mean" to someone not on Samsung Note reading the earlier post.

I gather abyss4.2 is a "safe" kernel compiled with MMC_CAP_ERASE disabled or is it a stock "safe" kernel?

TMT1.3 is some custom ROM?

CF5.3 is a safe or unsafe kernel?

What is the R3 kernel? What is the factor that would make someone feel safe with R3 after reading about EMMC lockup?

These "names" are probably all obvious to Note users, but less obvious to owners of other platforms.

Regarding ODIN, for the package that person is flashing, what is the 1st image that is being flashed? If it is returning right away, it might not be the same problem. Usually we find the stuff flashed in the beginning by the stock tars from samsung or bootloader stuff. It isn't until we get into the flash (data.img) that we find the lockup gets hit.
[Samsung Epic 4G Touch] fenixjn:
Well this is odd. I had this same issue... I attempted to flash a CWM for the note on my phone by mistake thru odin during an update to CM9a4 and I had the same outcome (error writing NAND, phone stuck with kies msg). Since I didnt see the /data error I assumed I just had to flash the right recovery and it would be fine... I was wrong. Even with the right recovery, I could not get odin to flash CWM for the ET4G (same error) but I was able to enter download mode and nothing else. Eventually I took off the battery waited about 5 minutes, entered download mode and odin flashed the recovery properly like nothing had happened.
[Samsung Epic 4G Touch] musashiro:
Abyss is a GB kernel. Therefore it is safe..

Tmt 1.3 is a custom rom. Yes.

Cf 5.3 is chainfire root. Its a kernel based on stock kernel. So any "danger" included on stock kernel is present on it.

R3 is franco kernel revision3. Its a kernel with the mmc_cap_erase disabled/erased.

Sent from my impatient-for-bugless-ICS note
[Samsung Epic 4G Touch] sfhub:
Thanks for the descriptions.

So how did the user below go from TMT1.3 with CF5.3 to R3. Was it just not listed in the description that at some point he installed R3?

I'm asking more details because sometimes people get confused which kernel they are actually running because the ROMs will sometimes install their own kernels and the recoveries can look similar.

One other thing, if ODIN was returning an "error" for that user, he probably isn't encountering the superbrick issue as the symptoms of the latter is that upon access of the bad blocks the phone will lockup. You won't get an error in ODIN, it will just hang and the phone will be unresponsive. That user seemed to indicate they got an immediate error in ODIN.
[Samsung Epic 4G Touch] rigel1326:
First off thank you to everyone here working on this bug corruption.

Been with my E4GT for around a week. Have made lot's of mistakes. Hello noob. I am trying hard not to though.

Here is my output

cat cid|cut -b 19,20

19

and

IMAG4FA

0x0

0x0

0x000015

0x0100

10/2011

MMC

Does this mean I have the bug? Thanks to all again especially sfhub.
[Samsung Epic 4G Touch] musashiro:
Actually, they cant confirm with the person if he is on franco kernel when the brick occured.. people are assuming that he did not flash the kernel carefully, hence he is still on the infected kernel when the brick happened..
[Samsung Epic 4G Touch] sfhub:
It means your emmc has firmware which is susceptible to the emmc lockup/superbrick bug. It doesn't mean you will definitely experience it as there are other factors involved, but you should be careful how you flash things. Don't wipe data/factory reset or do large operations that will reset your partitions using Recovery (or Custom Recovery) that are based on ICS kernels. That means shy away from installing ROMs using ICS-based kernels/recoveries, use GB-based kernels/recoveries for that until we get the patched kernel from Samsung and can verify their fix.

Themes, kernels, modems, and simple flashes to fix problems are ok, even on ICS-based kernels/recoveries.
[Samsung Epic 4G Touch] rigel1326:
Very interesting. Thank you for the update as I am monitoring the situation and reading to learn.
[Samsung Epic 4G Touch] rigel1326:
So glad I'm asking these questions and getting such quick great intel. As for wipe data/factory resets I plan on using your newly posted tool which I haven't yet since I just flashed to fe21 using your Odin file and I am really satisfied with.
[Samsung Epic 4G Touch] sjsharksfan420:
Is it not possible to "extract" the emmc firmware from data already available? Or do we need source code for that?

sj

Sent from my SGS2 Epic 4G Touch on AoKPm5 FE22 OS4.0.4 with dpi @ 128 using Tap@Talk 2.1.1 Pro
[Samsung Epic 4G Touch] sjsharksfan420:
So.. I need a little help with how I determine if my device is susceptible to the data corruption bug..

Can someone advise the easiest/best way to accomplish this task?

TIA

sj

Sent from my SGS2 Epic 4G Touch on AoKPm5 FE22 OS4.0.4 with dpi @ 128 using Tap@Talk 2.1.1 Pro
[Samsung Epic 4G Touch] globalm:
Read first post in this thread and use the code shown in a terminal emulator..
[Samsung Epic 4G Touch] sniper:
MAG4FA

0x0

0x0

0x000015

0x0100

10/2011

MMC

0x1314a208

1501004d4147344641191314a208aead
[Samsung Epic 4G Touch] sjsharksfan420:
Right on, I had read it a few times.. I guess just rereading it again made it make sense this time.. I was able to check my devices susceptibility..

sj

Sent from my SGS2 Epic 4G Touch on AoKPm5 FE22 OS4.0.4 with dpi @ 128 using Tap@Talk 2.1.1 Pro
[Samsung Epic 4G Touch] nCoder:
Found this e-mails of the guys that sign-off the code:

Hyunsung Jang <hs79.jang@samsung.com>

Hyuk Lee <hyuk1.lee@samsung.com>

Kukjin Kim <kgene.kim@samsung.com>

Could you please contact them with the technical details of the problem to see if they at least reply with more technical details, and hopefully a solution?

Cheers
[Samsung Epic 4G Touch] musashiro:
why don't you try emailing them. tell them the scenarios specially the bricking on Open German release since thats official..

i really want flawless ics on my note.. im a stock+root lover and this bug literally f*cks us who love it that way..
[Samsung Epic 4G Touch] nCoder:
My problem, is that I'm not able to have a technical conversation with these guys. :(

If someone familiar with the problem and what Mr. Sumrall says, then would be much more efficient.

Cheers
[Samsung Epic 4G Touch] garwynn:
Forwarded all that I had to them - requested the f/w patch if possible but at least stop using the call to mmc_erase() or replace with a format writing all zeros to the partition. Will pass on if I get a response.
[Samsung Epic 4G Touch] CyberpodS2:
Maybe a stupid question but couldn't a utility be created to just perm map out the bad areas like a low level does on a SCSI drive? I just don't know how you would get access to run the thing if it never starts at all.
[Samsung Epic 4G Touch] sfhub:
The issue is finding the bad areas. You could create a tool to help, but it would require some manual involvement and might not be the most intuitive because as you try to find the bad area, everytime you access a bad area, it will lockup the phone to the point you must pull the battery.

If one were to create such a tool, you could probably simplify it (and make it semi-usable by the general user) by scanning up until the first lockup, then scanning down until the first lockup. then hopefully you are left with enough usable area to remap.

Personally I would still rather get the unit replaced while it is still relatively new as there are probably limitations to this approach that may not be immediately apparent. For example, you might need to create a custom .pit file for ODIN to work or the damage might not be limited to the sectors that couldn't be accessed and further wear-level activities might bring them to surface, even with fixed kernels.
[Samsung Epic 4G Touch] sfhub:
Even with source code for ICS kernel, it likely wouldn't include anything on updating EMMC firmware. We might be able to "guess" how to do it based on similar code, but it is probably a relatively dangerous operation to try and attempt without documentation resulting in bricked phones while testing.
[Samsung Epic 4G Touch] sniper:
So send all of our hate mail to Colin Cross? ;)

Sfhub, thank you again for all your dedicated hard work; you never cease to amaze us. I read through that and I think I understood most of it :) I'm glad we're(you guys, not really me, haha) still making progress with this.
[Samsung Epic 4G Touch] sfhub:
Does anybody have the source code for update-binary that is included in the update.zips?

I want to see how that is built. If it is linked against libext4_utils.a there is a possibility it will have the same behavior as recovery.

I stress, this is not fleshed out by looking at the source, since I can't find it right now, so is pure conjecture, but this *MIGHT* explain why certain ROMs tend to trigger the EMMC lockup/superbrick bug. If their update.zip was packaged using an update-binary that was linked against libext4_utils.a from an ICS environment with the "wipe" change, then the install using that update.zip might trigger the bug.

If instead, folks on other ROMs bundled with GB-based update-binary linked against GB libext4_utils.a, then even though they are installing ICS-based ROMs, the calls by the updater would be GB-based and possibly not susceptible to the wipe problem.

Again this is even more conjecture, but theoretically if people took their GB CWM recovery that was linked against GB libext4_utils.a and repacked with ICS kernels, it would probably be safe. It is only the CWM that is linked against ICS libext4_utils.a that appears dangerous because it has the "wipe" functionality.

I don't build these recoveries myself. Can someone tell me what they did to produce CWM for an ICS environment? Did they just take their GB CWM binary (compiled against GB code base) and repack with ICS kernel, or did they recompile CWM within an ICS environment using the generic ICS code, then repack that with ICS kernel?
[Samsung Epic 4G Touch] biliskner:
Wow. Great explanation. Thanks!

I agree that Sam will just change the libs rather than release a FW rev for their emmc. But one can always hope.......
[Samsung Epic 4G Touch] sfhub:
To clarify, the lockup/superbrick bug is ultimately in the EMMC firmware. This is hardest to change and I doubt we will see a newer EMMC firmware for our EMMC chips.

Given that, there are 2 likely places they will "workaround" the issue:

1) in the kernel mmc driver

2) in libext4_utils.a which is linked into utilities like recovery

I don't think they will put the workaround in the kernel mmc driver. The GB kernel mmc driver called mmc_erase() also, it just wasn't invoked by wipe data/factory reset so the EMMC firmware bug never got triggered. If by some chance, they put the workaround in the mmc driver, then all recoveries would be rendered "safe" when packed with the kernel with the workaround in the mmc driver. This would be the case even if the Recovery binaries were not recompiled.

If they put the workaround in libext4_utils.a (which would essentially be backing out the ICS change) that would also workaround the problem, but only for Recoveries that are relinked/compiled against the libext4_utils.a that has the workaround. It is my opinion Samsung will put the workaround in here.

We'll know for sure once the source is released. I just got tired of waiting so wanted to look into the issue in more detail and consider the different places the workaround could show up.

By looking into the issue I also realized that if Samsung is "working around" the problem in the userspace libraries (#2 above), then there is no reason people who are building CWM/custom recoveries to wait for Samsung. They can make a change in their own source tree right now to implement a workaround.

I hope my analysis of the issue is accurate. If someone feels I'm reading this wrong, please feel free to add your comments.
[Samsung Epic 4G Touch] prabhu1980:
Dear Super Users ;

Case 1 : Reproducing the emmc bug ....

An improperly downloaded firmware uploaded without proper md5 check

when flashed will cause this emmc brick.

(Ex : I downloaded ICS Leaked version of Midnote 1.3 from Hotfile and the file size was supposed to be 800+ whereas the flashed file was 676 MB and I didnt notice it and bricked my Note ...)

This may probably explain why very few people get bugged by this bug....

Stuck at FactoryFS.img and could not be retrieved by using any method ...

Some Get stuck at Data.img .....

Case 2: Now EMMC is locking up the damaged areas (probably soft damaged due to corrupt file copied)

Why cant we dump the emmc firmware and decode it ??

Step 1: Dump EMMC firmware using dd command

Step 2: Decode using a HEX / ARM Decode Tool and disable Lockup ... (Is it possible ?)

Step 3: Reflash the mod EMMC firmware

Step 4: Run fsck to solve the issue.

Please reply without mixing both the Cases ...

Case a) Happened to me ...

Case b) My Theory for debugging

Sorry I am not a developer .... So I cant handle Case 2....

I am just throwing some ideas ....
[Samsung Epic 4G Touch] sfhub:
There is no interface readily available to us to retrieve the EMMC firmware as far as we know and we don't have the documentation for the interfaces.
[Samsung Epic 4G Touch] RainMotorsports:
The eMMC firmware can only be read or written via low level commands to the eMMC controller. It is not presented as a writable storage to the device at any level. Not having access to the documentation eMMC partners pay for and then sign a non disclosure agreement for makes a good challenge.
[Samsung Epic 4G Touch] prabhu1980:
Dear Electronic Gizmos and Most Respectable Developers ,

I have downloaded the documentation and it describes every bit to bit of eMMC.

May be now you can help us ....

It describes Bad Block Management ....

It describes Power Cycling .....

It describes How the factory settings are made ....

I know you guys will now open up your partitions and change the Emmc Bits and help us ... bUT WHERE IS THE PARTITION .....

n900 EMMC DOCUMENTATION MAY HELP ..... sOURCE : google

But I do also know that this information may be already available with you.

But do ask what u would like to have....

Looking for Samsung Insider .....

- tHANKS rAINmOTORsPORTS for bringing this up ....

Yeah when i tried accessing the partition containing firmware, the device pushes me out of the program trying to access it even with root privileges...

But there should be a workaround in the recovery mode ..... I read emmc firmware flash without any complicated tools for N900.