yashsingh1/xdaforums huggingface dataset:
[Samsung Epic 4G Touch] Robotu:
Well, this is another thing, i am not a developer nor a programer but i understand almost everything, i have a virus called IT, whatever that means. So in general i give up only when i understand why is that, what is and what is not. Most of the things come to me through intuition, so what you just said already was in my mind for a few days by connecting all the info known and unknown, that are all over around as... And here i am not joking.

My questions are as follow:

1) I do not think that the emmc is hardware bricked, just it can not allow acces to it (maybe because, as a russian guy said, of the 32 kb of zeros wrighten wich can not be read it anymore...), that if it can be formated, at a low level with the right tools, it can be revived; or changing the firmware so the controller could wipe and rewright everything....

2) If yet the emmc is hardware bricked, i think it can be repartitioned, eliminating that section that is corupted; that means finding the exact place where the first bad sector starts and where the last bad sector end, livit blank, non formatted, so the controller never read that section, and moving all the partition in the safe area, i think is need it a lot work for somebody to convince me that non of this theory are not possible...

I do not have enough english to say everything but yet.........

Sent from my SGS2 HD LTE SHV-E120L
[Samsung Epic 4G Touch] mobilevil:
even if this fix can make the system boot,

imho sooner or later the wear leveler will try to use the corrupted area again and freeze
[Samsung Epic 4G Touch] garwynn:
No worries - you're asking the same questions that have been tossed around here for quite a while. I too was a big supporter of the "it's not firmware, it's software..." side of the story until we got some significant information from Mr. Sumrall of the Android team.

There is a misunderstanding - which I also believed until it was proven otherwise - that the 32 Kb of zeros was somehow corrupting the file system to cause the "superbrick." It didn't make sense to anyone... now we know why. I'll repost Mr. Sumrall's summary here:

A locking issue means that we're beyond just file system at this point and back to the embedded controller. If the controller causes a lock up even by trying to access that memory you can't even flag the sector(s) as bad - which is why drnull's solution worked of just repartitioning and avoiding it altogether. There are potential problems when flashing or using ODIN to put something else on as it may try to restore that area and then cause the device to lock again, so flashing would be out. It would also be susceptible to the same problem (in theory) so one could end up corrupting the data system even further... that's bad news.

Possible? Drnull showed it was. Good idea? If you're in a situation where you need a device until you can replace it in the short term, yes. Long term - not recommended.

I'm by no means an "expert" in Android or these devices - many out there have much higher qualifications than I'll probably ever see. But I'm willing to spitball ideas like you are - as well as being open to listening to those more experienced (and honestly probably smarter) than me. It's how I learn as well and improve. And as long as we move the conversation forward I doubt anyone will go against you for doing so. Just please be willing to understand their position as well and why they're coming to these conclusions.
[Samsung Epic 4G Touch] Robotu:
Thank you, very much! I do not know you but i already like you, mostly for your pragmatism...

Out of shame question, who is mister Sumrall, and what is his position, cause i guess he is some kind of Samsung employe...?

Sent from my SGS2 HD LTE SHV-E120L
[Samsung Epic 4G Touch] garwynn:
No shame in asking a question. I know he's a programmer for the Android kernel (works for Google) - a quick look at his Linkedin profile indicates he's been there for a few years but been in the industry for a LONG time. I contacted him in particular as he was the one who checked in the source for the original bug fix we were investigating - which meant he had to have enough knowledge on the issue to at least sign off on the code change.

One thing that I have to give to most developers - they're willing to share their knowledge so long as they have time and it doesn't violate any Non-Disclosure Agreements that may be in place. I also think they make great teachers/professors based on my experiences; I've even thought about it when I get much older but still want to share what I've learned.
[Samsung Epic 4G Touch] Robotu:
Guys, another guy followed the instructions of forest and he have a fully functional device, camera is working, video recording, voice calls, as far he is saying everything is fine...
[Samsung Epic 4G Touch] sfhub:
It has already been known that you can change the partition tables to work around the bad area. We did that early on (ie months ago) in the odin hangs on data.img thread. The issue is so much of /data was unwritable that we effectively ended up with a few mb of /data. I'm sure we can create kernels that remap /data to the external SD if we wanted to, but I don't consider a real "solution" as you won't be able to get any upgrades. You'll have to always wait for someone to give you custom kernels to workaround the problem.
[Samsung Epic 4G Touch] sfhub:
Garwynn, not sure if this is in your followup questions, but I would like to make sure Samsung and Google are aware that whatever bugs are in the EMMC firmware, they don't appear to be triggered by the sequence of EMMC commands issued in the GB kernel. They can theoretically avoid all these problems if they spend the time to investigate what changed between GB and ICS for the code path generated by wipe data/factory reset in recovery.

I think most of us are aware of this on this thread, but it may not have been obvious to Samsung and Google because we have been asking specific questions about a fix that got checked in rather than spending time describing the history of the problem we are seeing.
[Samsung Epic 4G Touch] Robotu:
I understand what all of you are saying, it is very specific and comprehensiv, and maybe if i would have had enough time to read the entire thread i would have come to the same conclusion, but i read it only a few posts (in so many threads) cause trying to understand/fix this phone already charged me more time/money than changing the motherboard... So i am trying to end this adventure cause i am losing more money like this. So please, related to the few posts above, and more specific, what is your frankly and directly diagnostic and recommendation for this situation, i would like to here a few profy and straightly opinions?

Mi device still can do anything else, CWM, DM, adb....., except it can not boot.

Considering what garwynn seize, even if samsung and google will give you more info about firmware and stuff..., even so, the only solution for mine or other Note in the same situation is to replace motherboard, or after you (devs) will have that informations (if ever) you can (and/or you will) certainly find a solution for devices in that stage?

Thanks in advance!
[Samsung Epic 4G Touch] garwynn:
This is the #1 question that I'm going to add. I just want to go over Entropy's notes and see what he's noticed already and then sum it up so we can hopefully point in a direction without telling a long story. I'm still waiting for a response from Samsung and I left a VM for the person at Sprint - I'll be passing this on to them as well. (From Sprint's angle using the GB code is a good solution if they want to go OTA - patching the eMMC would probably be better in the long term if possible.)

I'll give it until tomorrow around 9 am CDT in case anyone else has some lingering questions - then send it off. Figured it was better to make sure everyone gets a chance to catch up after the weekend before doing so.
[Samsung Epic 4G Touch] jgaviota:
Sorry garwynn, I did not make myself clear...

Please relay those questions to Mr. Sumrall

1) Doesn't have to do with Android source, but actual commands sent to the emmc to reset it.

2 and 3) He should have access to that documentation or know some way to get the documentation.

Also ask him if there is documentation for the development board of the SGSII or Note

Again: with the emmc documentation a fix can be made, ask him if there is some way to get it, even if he cannot release the firmware upgrade
[Samsung Epic 4G Touch] garwynn:
Got it, sorry for any misunderstanding.
[Samsung Epic 4G Touch] Entropy512:
What I've been able to figure out so far:

The main difference between I9100 update4 source and SHW-M250S Update5 source is that in I9100 update4, MMC_CAP_ERASE is not enabled in either the MSHCI drivers or SDHCI drivers. The MSHCI driver is the driver for our internal storage.

Even before Mr. Sumrall's responses, based on the fact this usually happened during a wipe/format, I suspected it was MMC_CAP_ERASE.

However, in Gingerbread kernels for I777/I9100, the MSHCI driver also has MMC_CAP_ERASE enabled. The driver does appear to be heavily customized with Samsung code, however. So I'm kind of baffled as to why MMC_CAP_ERASE seems safe on Gingerbread - Either the customization in the driver works around fwrev 0x19's bug, OR there's something elsewhere in the kernel that causes ERASE commands not to get fired at the chip even though it's enabled in the MSHCI driver.

The fact that Gingerbread was safe caused me to move away from MMC_CAP_ERASE until Mr. Sumrall's response regarding the ERASE bug in 0x19.

Either way, I believe that removing the MMC_CAP_ERASE from the MSHCI driver will render it safe. I'm just curious as to why Gingerbread isn't dangerous despite having this feature flagged as enabled in the MSHCI driver.

What I know for sure:

GT-I9100 Update3 - Gingerbread - MMC_CAP_ERASE enabled but still somehow safe

GT-I9100 Update4 - ICS - MMC_CAP_ERASE disabled and safe

SHW-M250S Update5 - ICS - MMC_CAP_ERASE enabled and dangerous

What we really need at this point is a way for the JTAG services to do a full reset of the chip - Even if they can't update the firmware past 0x19, as long as they can recover the chip to a normal working state, then people can have damaged devices repaired for $30-50 instead of $200+.
[Samsung Epic 4G Touch] RootTheMachine:
I think this explains the issue we are having on original Galaxy S phones (i9000, Captivate, Vibrant etc.) and other devices & tablets that are getting the ICS "Encryption Unsuccessful" error (having nothing to do with the use of encryption), and in the process, losing /data and the internal sd card. We have already sent an affected device to Adam Outler for UBM, and it wasn't recoverable. Since yesterday, I have been asking people for their fwrev, and they all seem to be 0x0. Mine is also 0x0, but I don't have the issue. We have also had cases where people reboot and everything they once lost is back in place, or at least the partitions are accessible. Is there anything we can do to investigate this further on our devices? We aren't very well informed of the information discussed in your thread, and how it's relevant to us.

These are our threads

http://xdaforums.com/showthread.php?t=1447303

http://xdaforums.com/showthread.php?t=1649613
[Samsung Epic 4G Touch] garwynn:
The eMMC models - at least, those posted so far - don't match the ones that were identified in this discussion so it would be a guess at best if these were included at the moment. I'll try to dig more into those threads when I have a chance - saw one was 60 pages long.
[Samsung Epic 4G Touch] sfhub:
If it were me, I would just get the m/b replaced. Things may crop up later you don't realize at first with these workarounds and I'm actually not that confident we'll even see something that can repair a damaged unit anytime soon. I think a realistic goal is just to get some changes made so it doesn't happen in the future, but that wouldn't help an already damaged unit.
[Samsung Epic 4G Touch] Entropy512:
The original GalaxyS series has a completely different flash architecture than Exynos devices. They don't even use eMMC, they use oneNAND instead.

Whatever issue they are encountering is something completely different.
[Samsung Epic 4G Touch] garwynn:
Thanks - explains some of the information being posted.
[Samsung Epic 4G Touch] Robotu:
Thank you! I will follow your advice. This phone does not even worth this time i spend for it, using again other phones that i throw before in the desk drawer, i realized that the heat issue was causing a premature discharge every time, even though controlled with setcpu but with the cost of performance, yet even so still was hapenning the same thing eventually... Bleah!

And about the brick..., in the future i will be more cautios, read more and do less till everything is clear, no need to be the first in the line, no need to be a beta tester. I am involved in to many other things that depend on me, and me on theme. My time is to precious. Thank you all! I would like to be part of your world but we can not do to many things in one life, we do not have enough years so we have to filter, split, choose and set priorities.

Sent from my SGS2 HD LTE SHV-E120L
[Samsung Epic 4G Touch] musashiro:
Im just an IT student but as far as i have read, the number 1 question in my head for mr. Sumrall is how the gb differs to ics regarding wipe operations??

@garwynn, how did you contact samsung??

Hope we get a fix soon
[Samsung Epic 4G Touch] Entropy512:
That's more of a Samsung question, since they customized the MMC driver a bit in GB kernels but it seems like they did it less so in ICS kernels.
[Samsung Epic 4G Touch] carhauler1969:
Here's mine:

MAG4FA

0x0

0x0

0x000015

0x0100

11/2011

MMC

0x4f0e171b

1501004d4147344641194f0e171bbe25

Fwiw, I had been flashing with the ICS repack kernels until about three weeks ago, at which time I started utilizing the recommended el26+CWM repack. I've only been flashing the Touchwiz ROMs as the bricks seemed to be more prevalent when flashing the AOSP releases. I never EVER use the factory data reset option in recovery, & always wipe with Calk's FormatAll. Knock on wood I've not even had a soft brick yet :eek:

Wiping with reliable software has always been the way for me. FormatAll has never failed me on my EVO 4G, or either of the E4GT's I have rooted. Reliable software is... Well, reliable software. ;)

Sent from my E4GT packed full of "The Goodness" of TNz Blend ICS on Tapatalk 2 Pro
[Samsung Epic 4G Touch] musashiro:
this may be irrelevant, but there are new ICS ROMs on n7000. can anyone with the capabilities to investigate, conduct a proper check if this is indeed, affected by the "oh-so-tiring" eMMC bug?
[Samsung Epic 4G Touch] Entropy512:
As there is no source, there is no way to investigate other than sacrificing a few devices.

Assume it's dangerous until proven otherwise. At this point, I wouldn't trust binary kernels coming from Samsung until they explicitly acknowledge the issue and declare a kernel safe... Which you know they won't ever do. They will try to keep ignoring this issue and hope that it goes away like they always do.
[Samsung Epic 4G Touch] garwynn:
Morning Update

Probably not a surprise to many but without friends in high places it was a matter of calling and sending emails until I got someone who could confirm - both at Sprint and Samsung - that they can reach the appropriate team with this info. Sprint was a little easier because I remembered the old ads where they say you can contact Dan Hesse (dan@sprint.com) - which means that will be usually a second or third tier CSR answering instead of a first tier by phone.

So as far as I am aware both Samsung and Sprint are aware of the problem and I have requested them to patch the firmware. I also sent a request to the Samsung Open Source group to have Mr. Sumrall's fix added to the E4GT builds, which they responded and said they would review. (Figured this might help get the communication going at least within Samsung...) So I've approached this from every angle that I could; now it's a little bit of waiting to see what materializes.

I'm going to send that update to Mr. Sumrall and specifically note the fact that this firmware bug appears to cover the entire GSII line and Note line

except

the AT&T version; since they found this using Nexus devices I'm going to guess it's already been fixed on those. That might help him try and work it from his side, either to push Sammy to release the fix or if not possible to find the difference between GB and ICS and implement a workaround based on these chipsets. It's broad enough that hopefully he can justify it going into the kernel if they won't fix by patching the firmware.

---------- Post added at 03:18 PM ---------- Previous post was at 03:13 PM ----------

I'd be much more interested in trying to find where the change is in ICS versus GB kernel builds when it comes to eMMC wipes and try and work that in with the help of Mr. Sumrall than wait for Sammy to fix it. I heard there's an Eclipse extension that will pull kernel source, so I'm going to try that today after sending the email. Figure it's better to keep working on this in case we don't see the fix after all...

---------- Post added at 04:14 PM ---------- Previous post was at 03:18 PM ----------

OK, just fired off the email to Mr. Sumrall... main question is what the difference was between GB/ICS. I suggested that it might be a good idea to use his code to pull the revision and then use this to use a "safe" erase method for this particular revision - assuming we don't get the patch from Samsung. Also summed up the other questions but didn't mention JTAG just yet as I'm not sure that's really Google's domain - to me that's more of a Samsung question.

And for reference on contacting Samsung (without any inside connections): I found the easiest way to get stuff passed to the dev teams is either through Samsung's voice support - supervisors can send emails directly to the dev teams. (Thanks to their chat support for passing that nugget on!). If it is part of the kernel, such as this one, we can also make recommendations through the Open Source channels.

Will pass on if and when I get a response.
[Samsung Epic 4G Touch] nCoder:
Hi Guys

I'm in contact also with someone from Samsung Developers team (that is been very quick in the responses and seems very helpful), that asked me for test scenarios.

I sent these two:

Test 1:

- Have Latest official ICS ROM on Galaxy Note or Galaxy S2

- Start device in Recovery (Volume Up + Home + Power)

- Perform Wipe Data / Factory Reset

- Reboot System

Test 2:

Some reports also on other users performing a factory reset in the Settings Menu had the same resut.

Settings -> Privacy -> Factory data reset

Anything else?
[Samsung Epic 4G Touch] sfhub:
I have a suggestion, if it takes too long to figure out what the difference is, they can consider intercepting the erase command somewhere in the codepath and replace it with writing zeros. I don't know if this will work for every situation, but I imagine for most situations, this would work fine, and I'm sure they would have the information needed to decide whether it is a reasonable drop-in replacement.
[Samsung Epic 4G Touch] sfhub:
Though it is most likely possible to elicit the EMMC brick using menu->settings->privacy reset, on e4gt I don't remember reading about someone doing so. It might be because every here does their resets from recovery so we don't have a good sampling of resets from Android.

I think they will have more chance seeing the bug if they flashed a full ROM then wipe data/factory reset. It seems to help trigger the issue when you have more writing going on to the EMMC (might have to do with the trigger for the wear-level EMMC firmware bug). That might just be coincidence, but I thought it worth mentioning. It would be nice if they could reproduce this problem as people tend to feel a problem is more "real" if they can reproduce it.
[Samsung Epic 4G Touch] nCoder:
Hi,

Thanks, we'll give it a try and see what happens.

I'll write back here in a couple of days with my results.

Regards,

Adam Panasiuk

Samsung Developers

http://innovator.samsungmobile.com/...Lines=10&searchTextForm=&searchTypeForm=TITLE
[Samsung Epic 4G Touch] sfhub:
Could someone give me a link to the thread where users with Official released ICS firmware for Note are seeing the EMMC brick? If you could point to the section where the bricks on Official ICS start being described that would be good too, so I don't need to read through pages of comments to get there.

I would like to include it in the first post on the assumption that when talking to Samsung the first response is that you are running leaked ICS firmware so that is why it is happening and they take no responsibility for leaks.

To be clear, we are not asking them to take responsibility for leaked software.

We've identified a problem

while testing their leaked software

, which if left unaddressed, could cause a lot of issues

when they release their Official ICS software

.

This is the whole purpose of having people test leaked software. We discover problems before something can hit the general population and cause bigger issues.

We are trying to save them (as well as ourselves) headaches going forward.
[Samsung Epic 4G Touch] garwynn:
You are awesome! Didn't know about that but will start watching here as well.
[Samsung Epic 4G Touch] nCoder:
Just trying to help :)

I contacted Samsung Mobile Ireland, which is also following up on this issue:

https://www.facebook.com/SamsungMobileIreland/posts/449594815054690
[Samsung Epic 4G Touch] MR.change:
Here you go ,this one wiped from stock rooted LPY and from stock recovery .

http://xdaforums.com/showpost.php?p=26046849&postcount=140
[Samsung Epic 4G Touch] garwynn:
Here ya go:

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

(Sorry for double post... guess I got beat to it.)
[Samsung Epic 4G Touch] musashiro:
wooo.. Seing all the collaboration and initiative makes waiting on GB a pleasure...

Keep it up. Imma try and do my part in monitoring threads...

Hope the samsung dev reproduces the issue since if he cant, we wont see any light on this problem..
[Samsung Epic 4G Touch] garwynn:
Hopefully giving him the name of the developer who provided the original fix that we investigated will help. It's probably a matter at this point of getting the right people to talk to each other.. in a company as big as Samsung that could be quite a feat. (My company has several IS offices globally and I still don't know all the other developers in the other regions.)
[Samsung Epic 4G Touch] Entropy512:
Just disabling MMC_CAP_ERASE in the MMC driver should be enough. That seems to be why I9100 Update4 is safe.

I'm still a bit mystified as to why MMC_CAP_ERASE can be enabled in the Gingerbread kernels yet not cause problems, other than that it seems like the GB kernel has the erase operations somewhat customized. Either that or formatting a partition in 2.6.35.x does not cause the MMC driver to perform an ERASE command if the host driver flags itself as being capable of erase.

I'm 90% certain that kernels that simply don't enable the MMC_CAP_ERASE flag at all will be safe.

I'm fairly certain, based on Mr. Sumrall's info, that this is the line that makes M250S Update4 and Update5 dangerous compared to I9100 Update4:

https://github.com/Entropy512/kerne...59551eaf5afc3d68f2da96b0249937bd5e13#L10L1873

Without that line, the kernel will NEVER fire an erase command to any device attached to the MSHCI controller.

Here's evidence that Samsung is already aware of the issue, trying to fix it, and failing due to:

1) Not catching all situations that could generate an ERASE command

2) The development team responsible for that kernel being unaware of the underlying fwrev 0x19 issue (if they had been aware of it, the above line of code wouldn't be there).

https://github.com/Entropy512/kernel_galaxys2_ics/commit/d069cc5cb9f0fd9409ea10d4037e4c0e68701b8e (They disabled TRIM, which stops many ERASE commands, but appears not to stop ERASE commands from being created during a partition reformat.)