yashsingh1/xdaforums huggingface dataset:
[Samsung Epic 4G Touch] vov120:
Regarding the second case:

when new PIT was flashed, didn't you try to flash kernel etc. in the new partitions?

After I finish with data recovery, if my emmc is writable, I probably will play with custom PIT's to get kernel working and when run bad block scanner.
[Samsung Epic 4G Touch] Lanchon:
fair. good luck with that. take care
[Samsung Epic 4G Touch] @anonymous94:
How to fix hanging issue even in stock after wiping everything, phone keeps freezing and force close.
[Samsung Epic 4G Touch] :
It means there are damaged blocks in the are you are writing to.

---------- Post added at 11:08 AM ---------- Previous post was at 11:08 AM ----------

It means there are damaged blocks in the area you are writing to.
[Samsung Epic 4G Touch] Entropy512:
It formats the partition. My current suspicion is that something in the kernel misbehaves when performing a bulk erase. Normally formatting a partition doesn't erase unused blocks, but on flash memory it does with modern flash controllers. (TRIM, etc.)

There was some evidence that this was connected with ICS kernels enabling MMC_CAP_ERASE, but GB kernels have this too - unless there's a negative interaction of MMC_CAP_ERASE with something that was added in ICS.

What we known:

Gingerbread kernels with MMC_CAP_ERASE are safe

ICS kernels without MMC_CAP_ERASE are safe

ICS kernels with MMC_CAP_ERASE set are dangerous

Whether it is actually connected to MMC_CAP_ERASE - don't know. Right now that's the most obvious difference in the MMC drivers between I9100 update4 (safe) and SHW-M250S update5 (dangerous)

It may explain why flashing CM9 seems more dangerous than flashing some other firmwares. To ensure that /system has a fresh clear partition without journal cruft or anything else, CM9 formats the /system partition during install. Some other firmwares only do a recursive delete without reformatting.
[Samsung Epic 4G Touch] sfhub:
Well Calk's format all script just does format() from a recovery update.zip edify script (cache, system, data) and it is what most on e4gt have been using. Most people use it from GB-based kernels/recovery but quite a few do it from ICS-based kernels/recovery and I haven't heard of any issues. Wipe data/factory reset, on the other hand tends to usually be involved. That is why I was going with the theory that wipe data/factory reset was doing something different or more extensive.

However since wipe data/factory reset is often done along with flashing a ROM, it is possible the install of the ROM itself is actually the one triggering the issue and that could explain why CM9 stuff seems to be in the picture all the time also.

I guess we can look at the AOKP install scripts to see what they are doing there and how it compares to stock ICS install scripts.
[Samsung Epic 4G Touch] Entropy512:
http://xdaforums.com/showpost.php?p=26046849&postcount=140 - First confirmed eMMC blowup from stock recovery
[Samsung Epic 4G Touch] cescomanto:
Note fail

excuse me, i lost in the words... I was using 2.3.6 stock rom then upgraded with LPY ICS download rom. All ok. It was a bit laggy and full of software so, i saw my Cyanogenmod rom's friend and i load it with root+cwm. I load it by cwm touch and load the rom and then its gapps. I wipe cache and recovery but in wipinf recovery its blocked all and i shut off all. Then nothing works (yes download mode and recovery stock) but with all rom i try never start . All in loop mode (at start screen when show : AGALXY NOTE N7000 or with SAMSUNG ANIMATION). I have to install linux e make something? ahhhhh
[Samsung Epic 4G Touch] kahm:
I'm not sure that I saw anywhere that the firmware on the EMMC couldn't be updated because it was unwritable. Who knows if samsung even wrote the firmware for that? Who knows if they have access to the source of the firmware for it, in order to make changes? Re-doing a low, low, LOW level firmware like an EMMC chip isn't something that could be done easily over this many devices, I would think. Especially if the firmware is a little out of Samsung's control. It would probably need to be done through recovery, which a good 50% of SGSII users might not even know exists, and even then it would have to be done outside of a carriers' update path (eg: not OTA), so it might just not be as easy as you'd think. Hence why it's actually kind of a common thing that zeros are just accidentally being written to the wrong place.
[Samsung Epic 4G Touch] garwynn:
At the moment it looks like this may be the fix... but we're having a problem reconciling the fact that it's not properly identifying our device. It's why I've sent a post to the Android team and asked the folks I know can submit stuff to Samsung to do so as well. It may be that the fix itself is bugged, or this isn't it and the problem still isn't resolved. We won't know until we get something back from the devs working on the kernel source.

The link that I originally provided appears at face value to be the "in development" kernels for Samsung, which have used variations of tuna as the codename. This particular fix though has been rolled into the current Android kernel as of 4.0.4_r1.1.

---------- Post added at 06:24 PM ---------- Previous post was at 06:22 PM ----------

Most likely you are a victim of the file system corruption that we think this fix was designed to address. At the moment no fix is available once the file system is corrupted.
[Samsung Epic 4G Touch] cp320703:
DO NOT FLASH VIA CWM TOUCH, but you know that now, unfortunately! from everything i've read you've made an unrecoverable brick, but you probably want to check the forum specific your device, insofar as GSll E4GT i've not seen anyone able to recover, You'll want to try to flash the ODIN OC stock restore for the note, but if it's the same problem we're having (/data borked) here you'll still be stuck in a bootloop at best and likely have to replace the device.

Thank you for taking the time to reply to my post, however you seem to be mostly addressing sfhubs question that i (improperly, sorry, new) quoted wondering if he had found anything further on that. Q & A with Mr. Sumrall posted (page 3 or so of this thread) by garwynn address this somewhat as well, or at least demonstrates that a. samsung is aware of it and 2. they've developed a rather imperfect patch that needs to run at every boot because they could not alter the firmware itself. I simply was seeking clarification on whether on not he (sfhub) had found anymore information on this, because if samsung needs to patch it in an impermanent way because they can't write to it (sfhub's presumption) how is that same area getting corrupted during wipes?

thanks garwynn, you're posts have been extremely helpful in my attempt to follow whats going on here and i take it from your reply that my basic understanding is at least mostly correct... If possible could you explain a bit further insofar as 1.how/where its not properly identifying the device and 2. why this is important, I've read through the thread but did not understand that aspect of it, or if you could just tell me what to google i'm glad to do my own research, just don't know what to look up!
[Samsung Epic 4G Touch] cp320703:
garwynn, thanks for the quick reply and explanation, i think its starting to click for me fwiw i ran my eemc id info, the values it returned were

MAG4FA

0x0

0x0

0x000015

0x0100

01/2012

MMC

I'm running the FE10 kernel with AOKP build 35
[Samsung Epic 4G Touch] garwynn:
In the same way you got that information can you do the following?

In the same directory please do a "cat cid" and please paste here.

Or, look for the serial (starting with 0xE70C3B19) and copy/paste the two characters immediately to the left of that in the cid string?

For example, I do a "cat cid" and get the following:

1501004d4147344641191e67496ebe63

Now my Serial number is 0x1E67496E.

Don't count the "0x" as that's just a hex identifier.

So I look in the string above, get the two to the left of 1E and get 19.

That's a hex value, so it's 0x19 or 25 in decimal value. (16 * 1 + 9)

If I'm right you should see something like this:

1501004d414734464119e70c3b191f##

What the last two (replaced by ## for the sample) I'm not sure but don't apply to what we're looking at.

Thanks!
[Samsung Epic 4G Touch] cp320703:
as requested...

0xe70c3b19

1501004d414734464119e70c3b191f0f

happy to help out more with whatever as needed, about to be late for work though!
[Samsung Epic 4G Touch] garwynn:
That's 2...

Ok, 2 for 0x19

(Where I found it)

1501004d414734464119e70c3b191f0f

Anyone else that can check theirs? TIA as I'm trying to get a larger sample size.
[Samsung Epic 4G Touch] Esoteric68:
I would give my right pinkie toe to understand half of what you guys are saying here, but in lieu of understanding I'd like to give my heartfelt thanks for all the work you are all doing in an attempt to understand this issue and get to the bottom of it.

If I can figure out how to do the above check I'll get back to you with my information.
[Samsung Epic 4G Touch] todivefor:
I have 19 as well:

# cd /sys/class/block/mmcblk0/device

# cat name hwrev fwrev manfid oemid date type serial

MAG4FA

0x0

0x0

0x000015

0x0100

10/2011

MMC

0xc80a8c89

# cat cid

1501004d414734464119c80a8c89aedd
[Samsung Epic 4G Touch] garwynn:
Modified sfhub's instructions from adb shell:

Then just post them here. Thanks!
[Samsung Epic 4G Touch] im0rtalz:
MAG4FA

0x0

0x0

0x000015

0x0100

08/2011

MMC

cat serial

0xd3f24fe6

cat cid

1501004d414734464119d3f24fe68e8b
[Samsung Epic 4G Touch] fenixjn:
serial: 0x839f401b

cid: 1501004d414734464119839f401b9eb5

Currently running CM9a3
[Samsung Epic 4G Touch] longhorn65:
I have 19 as well:

# cd /sys/class/block/mmcblk0/device

# cat name hwrev fwrev manfid oemid date type serial

MAG4FA

0x0

0x0

0x000015

0x0100

09/2011

MMC

0x7f0f5c98

# cat cid

1501004d4147344641197f0f5c989ed7
[Samsung Epic 4G Touch] garwynn:
Well, I've run out of thanks for the day so thanks again to all who post. I've also cross-posted (which I normally would not do...) on the Nexus and Note forums to get some of theirs. The one Note response that I have so far has the same fwrev of 0x19 if done by hand.
[Samsung Epic 4G Touch] fenixjn:
Got you covered :)
[Samsung Epic 4G Touch] kahm:
Understood - but all I'm saying is that it's unlikely that the people who wrote the firmware for the EMMC are writing code for android kernels. I would think those were two separate teams, and if the EMMC team got an 'OK' of sorts from the people doing android that this bug could be squashed without re-flashing EMMC firmware, I'd think they'd take that opportunity.
[Samsung Epic 4G Touch] cescomanto:
ok i think my /data was left died with wipe data cwm ICS. So is really this because when i reload my rom with ODIN, CSC, MODEM AND CODE is all good but at the end all blocked around WRITING DATA. I would try the fix but i don't know waht i have to do properly... I have to tryng load kernel FE07 / FE10 ON ODIN WITH "PDA STRING" ?
[Samsung Epic 4G Touch] blackroseMD1:
Yeah, you're bricked. You'll have to get the phone replaced. The /data partition has been damaged. Even if you get your phone to boot, it'll hit that spot on the partition and stop working.
[Samsung Epic 4G Touch] musashiro:
VYL00M

0x0

0x000015

0x0100

09/2011

MMC

0x22692a64

15010056594c30304d1922692a649ee3

im on note... GB rom
[Samsung Epic 4G Touch] garwynn:
Ok nighttime update...

Two Note devices from AT&T have fwrev manually found as 0x25 but still not set in field. Checking their build version. eMMC in their case is KYL00M. All other results so far are fwrev 0x19.

Will update Mr. Sumrall... Those contacting Samsung, please pass this on as well. Thanks again for everyone's help!
[Samsung Epic 4G Touch] musashiro:
so mine is international thats why its 0x19?
[Samsung Epic 4G Touch] EdgaBimbam:
galaxy note, LPY firmware rooted with CF

VYL00M

0x0

0x0

0x000015

0x0100

02/2012

MMC

0x3a211d71
[Samsung Epic 4G Touch] weboide:
E4T:

MAG4FA

0x0

0x0

0x000015

0x0100

08/2011

MMC

0xb6015cad

....44641*19*b6015cad8e9d
[Samsung Epic 4G Touch] garwynn:
Only one of the 3 eMMC models - KYL00M - has been found to have the revision specified in the code. So far I've only found these in the AT&T version of the Note. The other two - VYL00M and MAG4FA (ours) - everyone has reported back with a revision of 0x19 - and that seems to be regardless of where the phone is.

Wonder if they tested one case and then copy/pasted the other two. :confused:

Just a note - I haven't gotten a response from anyone with a Galaxy Nexus yet. So any of you with friends that have one, please ask them to help us out.

Thanks again for everyone's help!
[Samsung Epic 4G Touch] keithatoz:
Here's my info updated with my serial and cid:

MAG4FA

0x0

0x0

0x000015

0x0100

10/2011

MMC

serial: 0xc1142ce6

cid: 1501004d414734464119c1142ce6aea3

Doesn't look like anything too different than the rest. I can't thank you all enough for all the high quality testing and info.
[Samsung Epic 4G Touch] griffen97023:
http://www.jtagbox.com/

Says as of the 11 epic touch is now supported for dead boot bricks.
[Samsung Epic 4G Touch] garwynn:
I am curious what they mean by the RIFF box can resurrect these, I'll have to find out more.

Question to pose out there:

Let's assume for a second that the bug affects our devices and is random as mentioned. It's controlled by WL logic so it's going to most likely hit the spaces first that are have data writes the most. Still don't know the trigger either, but suspected to be a wipe operation.

So here's the question - we know that /data is affected but only because we can still get the device to start up. For those cases where it isn't, do we know where the corruption took place? It would be interesting to see if we could somehow peek at the filesystem after corruption and see if a pattern arises.

In the meantime I'm going to fire off an update as to what users have posted. With well over 100 responses the sample size is large and consistent enough where I feel comfortable asking them to look into it further. We'll see what happens from there.

Thanks again for everyone's help!
[Samsung Epic 4G Touch] cp320703:
I would be interested in seeing their success rate, if any, in a earlier thread about this same topic user connexion2005, the guy behind mobile tech videos, attempted to JTAG several /data bricks. He reported back that not only was he unable to resurrect via JTAG, at best acheiving a boot loop, but it appeared to him that there was actual h/w damage to the eMMC on these phones...one of his last posts on the topic was as follows...

A note, he later reported back he would not be replacing eMMC's for hire, he was just exploring the option for personal edification... Garwynn, who has been doing alot of the heavy lifting as it were on this thread feels that its not actually hardware failure, but regardless whether it is or not (I tend to agree that it's not, but my opinion is of limited value) it will not respond to JTAGing if you have the /data error. If I am erroneous and have missed a bunch of JTAG fixed my /data brick!!!!!!1!!!11! posts please correct me as I do not wish to mislead, but afik /data is still an unrecoverable brick

this is the thread i was referencing with connexion2005's post, inability to JTAG back to a usable state talk begins about here http://xdaforums.com/showthread.php?t=1504808&page=27
[Samsung Epic 4G Touch] Entropy512:
Meaning the classic "corrupted bootloader" brick situation. As I understand it, while they're just announcing support now they've had the capability for a while (potentially just by treating the device as an I9100...)

The thing is - other devices "supported" by RIFFbox have been unresurrectable when hit by Superbrick.

What that announcement is talking about is the classic "resurrect from corrupted PBL/SBL" hardbrick.
[Samsung Epic 4G Touch] jgaviota:
What I think is happening is that the information about the partitions is being corrupted by the format, in a way that cannot easily be recovered.

As far as I can see ALL the bricks resulted from a format, either via a wipe from recovery or from the install script of Stunner rom for the Note.

Was there any change in the way a format is made from a GB kernel to an ICS one?

If the partition info that gets corrupted is from a partition that does not hold the pbl or sbl then the phone can get into download mode or recovery, but if the partition info that gets corrupted is for any of those two then you have a black screen hard brick.

Has anyone that has a bootloop brick (where you can still go into Download mode) tried repartitioning from latest Heimdall from Linux?

If it is not the partition info it's something like that, maybe some kind of access table...

Anyone has any technical info on the emmc chip used here, and how the partitions are stored? Also any info on the booting process for our exynos? Has AdamOutler made an UnbrickableMod for any of the afflicted devices?

An UnbrickableMod could help us by giving lower level access to the boot process.

BTW I'm an electronics engineer, but I don't have access to the documentation, or to the right tools, and also I don't have the soldering skills to try to develope an UnbrickableMod.
[Samsung Epic 4G Touch] musashiro:
thats what im thinking, if they can use the amora filemanager - its a file manager that can be executed in recovery, to peek at the system, it might help...
[Samsung Epic 4G Touch] cp320703:
Yup, currently cannot be recovered at all, once the damage is done no currently available method can undo it...In fact the brick one of the testers in this thread had was likely the result of the wipe, and while that's a super small sample it serves to help confirm that line of thought

It seems that the ICS kernels that support MMC_CAP_ERASE (http://xdaforums.com/showpost.php?p=25385420&postcount=69) are capable of causing a brick and those that don't aren't, however it was present in GB so that may just be a red herring. The prevailing theory seems to be that its a problem with the eMMC firmware itself that's potentially just exasperated by certain builds, hence the bugfix this thread was started in response to.

That seems to be the case, the most commonly (only?) reported partition thus far has been /data, leaving ODIN/recovery accessible. Insofar as those with black screen bricks no one thus far,at least that I've seen, has been able to get into the device to see exactly which partitions are borked, but your assumption seems likely

At least one person (http://xdaforums.com/showpost.php?p=22769452&postcount=156) with a bootloop brick has posted that they've tried Heimdall and were still unable to recover, I would assume more have ,no one has yet to report any degree of success, even JTAG fails, hence the current assertion that affected phones are completely unrecoverable,

yup, from garwynn's interview with the android developer that signed off on the bugfix being researched here... "No. *The 32 Kbytes of zeros have already been inserted into the filesystem (usually in a particularly bad place, like the inode or block bitmaps, or the inode table) and the filesystem is now corrupt." http://xdaforums.com/showpost.php?p=25885701&postcount=19

We currently do not have an UnbrickableMod on this device, however it does not seem likely it would be helpful to those that have already bricked even if there was one since the eMMC does not respond to JTAG, which is about as low level as it gets, ya know.... Insofar as technical data on the eMMC/partition structure/boot process I'll leave that to someone more knowledgeable than myself! hope this helps!
[Samsung Epic 4G Touch] fl4r3:
I did come across a post where someone actually managed to recover using Heimdall even though CWM and Odin kept failing (link to post.). He could only access recovery and download mode apparently.

Maybe this just shows the location of corruption is quite variable (if indeed this is what is happening) and therefore possibility of un-bricking is dependent from case to case??
[Samsung Epic 4G Touch] jgaviota:
Relevant post:

That attempt was made on Feb 20 or before, and on March 31 there was an update to Heimdall:

Heimdall Suite 1.3.2 Released

Because the error glass330 had is the one that Benjamin Dobell fixed, if there are more bootloop bricks I think it might be worthwhile to try repartitioning with latest Heimdall from Linux.
[Samsung Epic 4G Touch] sfhub:
Sorry folks, was out of town for a few days. Updated OP with cat serial cid and sample output.
[Samsung Epic 4G Touch] sfhub:
The scenario you described was explored early on. The reason it does not appear to be what is happening is

1) we can repartition to get the phone booted, but nothing has been able to resurrect the damaged blocks. If you include the damaged blocks in the new partition table for /data, writes to those blocks will fail

2) JTAG should not care about the partition info. It will just blast over it. JTAG is unable to write to the damaged areas.

3) ODIN repartition does not get the system working again. The damaged areas are still damaed.
[Samsung Epic 4G Touch] garwynn:
While you were gone the discussion ran between multiple threads - I want to link this one so people following here can read a continued discussion on another thread without reposting here:

http://xdaforums.com/showthread.php?t=1648362&page=24

I'm not sure how I'm going to get the time but I'm going to set up a VirtualBox to create a build environment for Android. Got as far as installing Ubuntu 11.04 on it before and I know my PC will handle it without problems - just finding the time to do it will be the challenge. It will also allow me to pull the AOSP builds instead of the cloned Nexus builds that we've been referring to.

Reason for doing this is for several reasons. First, let's confirm in AOSP which releases had the fix. (I've seen the changelog but I want to check the branch sources for myself) While I've sent two messages to Mr. Sumrall it's odd that I haven't gotten a response yet. Also, it gives us a benchmark to see what custom ROMs may have this in where we could test again. For now just getting the fwrev to properly identify should be the goal - that's a first step in confirming the fix is in the build. (We should at least see this even if the fixup is not applied.)
[Samsung Epic 4G Touch] im0rtalz:
I'm wondering does the phone support SPI interface? I'm not knowledgeable since I'm more of minion type of people to the engineers. Well for our testing at our company the memory chip we manufacture does have jtag support but it seems the engineers use SPI and programs are written in tcl onto the chip. I'm pretty certain it wouldn't be the same nand that is in samsung phones any how but it just have me thinking.
[Samsung Epic 4G Touch] Entropy512:
Nearly all MMC/SD cards support SPI as a subset of operation. Problem is that the SPI lines are a subset of the MMC lines wired directly to the CPU.
[Samsung Epic 4G Touch] sfhub:
I added this in the "Related threads" section of the first post.
[Samsung Epic 4G Touch] garwynn:
@sfhub,

Typing this real quick while the little one is sleeping. #1 answer is here:

http://xdaforums.com/showthread.php?p=25925957

Missed it the first time by reading the source at the wrong change level. But your post picked up as to what that really is... Glad I got people to post the results.

But if that is there, why isn't it picked up? That is why I wanted the other thread linked as Entropy512 brought up a good point on that... And why I changed my approach for now.

Will try to start the virtualbox setup tomorrow morning to pull AOSP.