yashsingh1/xdaforums huggingface dataset:
[Samsung Epic 4G Touch] jgaviota:
About point 2

It depends on how much the person doing the JTAG flashes, maybe they just did what has been done on other galaxy devices? That is flashing the bootloaders and maybe the kernel, and not overwrite the whole eemc chip? I had to buy a JTAG box to fix my galaxy tab, I already sold it though.

Or has somebody here done the JTAG themselves?

About point 3

I still think it would be worthwhile to try repartitioning with Heimdall in Linux. I have a Latin Galaxy Tab that always fails to flash using Odin, but it works with Heimdall.

I know its a long shot, but I haven't seen a knowledgeable person try. What would it hurt? Obviously you have to be able to get into download mode.
[Samsung Epic 4G Touch] sfhub:
According to MobielTechVideos, they dumped the complete memory, everything in the system. According to MobileTechVideos, they had trouble completing the entire flash because of the damaged memory area. They had to have flashed more than what you suggest or the JTAG flash wouldn't have reached the problem areas of memory and had issues as the phone that was sent to them had no problems flashing zImage and bootloader, only trouble was /data partition. Not ODIN, not CWM, not factory reset/wipe data in stock recovery.

It doesn't hurt, someone can try, but we already are able to succesfully repartition using ODIN flash. I just needed to remove the data.img from the tar files being flashed. Even with successful repartition in ODIN, nothing could write to the /data partition.

It wasn't until we "relocated" the /data partition that we could get the phone to boot again.
[Samsung Epic 4G Touch] sfhub:
Yes, I understand that post is explaining why our fwrev is 0x0.

My point above is you are suggesting fwrev being 0x0 is *an error in the kernel source* and it really should be set to 0x19 in the example above. I'm asking how you came to the conclusion PRV should be used to populate fwrev, as there are some inconsistencies with making that assumption and also I didn't see anywhere it says explicitly it should be the case that for v4 MMCA/JEDEC, PRV should be used as fwrev. There are some bit-width differences and also differences in interpretation. Just re-read the post I made and you'll see them detailed.

Could you point me to the post for the good point from Entropy512 you are referring to?
[Samsung Epic 4G Touch] garwynn:
Attached wrong link... how about this instead?

http://xdaforums.com/showpost.php?p=25925957&postcount=56

That should clear that part up. Sorry about the previous link.

Quoted post from Entropy and my reply:

http://xdaforums.com/showpost.php?p=26178306&postcount=232
[Samsung Epic 4G Touch] sfhub:
Ah, ok, that clears things up regarding stuffing PRV into fwrev.

So then based on that, there is a very high likelihood the original conclusion that we have the emmc workaround in our kernel is not correct. Was that still in question? I've lost track of the timeline in the various threads.

If we had the emmc fix in our kernel, then it shouldn't be returning 0x0 for fwrev and instead should have returned 0x19 (because stuffing PRV into fwrev came in the same changeset as the emmc fix). Since it didn't return 0x19, there is a very high likelihood we don't have the other change (emmc fix/workaround)

My reading of Sumrall's response was the filesystem data could not be recovered to the pre-corruption state, after it had been corrupted by the writing of 32KB of zeros.

I didn't read his response as "the emmc is so screwed after the writing of 32KB of zeros that that section of EMMC can never be written to again"
[Samsung Epic 4G Touch] garwynn:
You're reading it the same as I am - perhaps uncorrectable was not the right word to use there. I think it's not possible to correct this at the moment and that it's simply due to a lack of the necessary software solution to manipulate the controller to do what is necessary. (I noted this in the same post that you quoted)

From an experience and educational background I'll admit that I'm probably a lightweight compared to several others involved in the discussion. But the basic premise I remember in my classes should stand - a electronic device is either only limited by physical means or the lack of software solutions to accomplish the goal. There doesn't seem to be a physical explanation for these bricks (which is where I have disagreed with MobileTechVideos on the topic) so the only logical alternative is a lack of software support to correct the issue.
[Samsung Epic 4G Touch] sfhub:
Well, if I program the hard drive firmware to spin faster than the hardware can handle and it crashes, it was a software problem that caused hardware damage that can't be corrected in software.

The firmware on these EMMC chips have to handle low-level stuff like voltage levels, time sensitive operations, etc. If there is a bug in certain operations they can cause hardware issues. If those certain operations are avoided by using alternate operations, then you won't know there is any problem.

I've had bunch of same brand SD cards that would hard crash with a certain card reader only (actually the particular chip set controller in that reader), because the voltage levels were not what it expected during write operations. Switch card readers and everything worked perfect.
[Samsung Epic 4G Touch] sfhub:
Actually I was of the thinking the 32KB zero problem is not what we are experiencing. I could be wrong, and it might still be the cause, but I can't see the mechanism where it would result in EMMC blocks which can't be written to again, based on the explanation of the problem they are fixing. That is making me lean towards thinking what we are experiencing is a different problem, but possibly also in the EMMC firmware.

I also feel, based on the data provided, for our problem, this is either permanent hardware damage, or damage where we won't be able to repair outside of a lab (which is basically the same thing for our purposes)

I know you don't agree with this assessment. Not knowing the true cause can allow for multiple possibilities, and we all have opinions based on interpretation of the data.
[Samsung Epic 4G Touch] garwynn:
There always exists the case that there are multiple issues going on with these eMMCs, but then what we're doing now should help at the least by process of elimination. It would certainly explain why we can't fill all of the proverbial holes with what we know. Source will also help us greatly once we get it - but that also depends on if they'll give the whole thing or hold back on the proprietary code.

Have we gotten any better visibility into the "superbrick" at the time that it happens? Maybe try and have someone run a logcat window while performing these operations?
[Samsung Epic 4G Touch] sfhub:
Well, my take away so far is I'm willing to wipe my system using delete_recursive. Format is a possibilty also but not completely sure. However I will completely avoid wipe data/factory reset. GB-based kernel and ODIN appear to be safe also, but we already knew that.

I'll go out on a limb and just predict that we won't find a "bug" in the kernel even when source is released. We will probably figure out that the ICS kernel produces a different set of commands to the EMMC to achieve certain functions and then we'll revert to the GB way of doing things and avoid the bug. IMO for this type of crash to happen, the likelihood is the core problem is in the EMMC firmware and the best we can hope for is to avoid the problem (which should be good enough for almost everyone)
[Samsung Epic 4G Touch] garwynn:
Morning Update

Well, it's been some time but thankfully Mr. Sumrall from Android did get back to us on our questions. I think the community will find that this was worth the wait.

Issue: fwrev not set properly.

As we suspected the bugfix is not in our build. (The patch applies this unconditionally.)

Question: Revision didn't match the fix

(Emphasis mine in red as it discusses the superbrick issue.)

Question: Why the /data partition?

Question: Why JTAG won't work?

Question: Can a corrupted file system be repaired (on the eMMC)?

So, while the fix doesn't apply to us at the moment, we've been given a great insight into the superbrick issue as well as information that a fix is already developed (hopefully we'll see it released!). The bug likely applies to us and assuming the fix for the 0x19 firmware is given then it would apply to our devices.

On a lighter note, I wanted to include his close:
[Samsung Epic 4G Touch] azyouthinkeyeiz:
I also think (after that last quote, garwyyn) this a good time to explain to those who are constantly complaining about waiting for releases, that these issues are examples of what hold that process up. I always hear, "Oh, Samsung sucks. They are so slow with updates."

Well, innovation takes time. When you are going above and beyond to make quality software, and not keep it as close to the source as you can, it takes time.

Would you guys rather risk bricks, (after updating to unvetted software) than have just a little patience?
[Samsung Epic 4G Touch] Esoteric68:
As eager as I am to have source I'd much prefer they take whatever time they need to get the big issues in hand.

Little bugs I can live with, there are always follow-on updates to correct them or doable workarounds to avoid them but this bricking issue is something we need resolved no matter how long it takes.

I appreciate the immense amount of time you guys are spending on this trying to help the process along.
[Samsung Epic 4G Touch] garwynn:
Now I just hope Samsung will do the right thing and release the fw update method for our eMMCs. It was great to find out that it is able to to be fixed and that the fix exists, but also a little disappointing that they didn't at the least give this to the carriers to try and help them with cost control.

I'm just wondering though - from a legal standpoint doesn't this qualify as a defect? So wouldn't Samsung be required to replace the device under it's limited warranty if it bricks due to the wipe? I know it's a grey area since you're loading other than official software...
[Samsung Epic 4G Touch] sfhub:
Thank you Mr. Sumrall and garwynn.

This explanation finally ties in with the behavior we are seeing with the EMMC brick. The 32KB of zeros just didn't seem to match what we were seeing.

It also lets us see which devices are truly immune to the brick (it seems everyone who has posted is on PRV/fwrev 0x19 though)

It gives us a place to pursue further, the emmc firmware update code. Ideally we could get Samsung to provide this to us.

The only piece it doesn't explain is why ICS-based kernels seem so much more susceptible to the problem, whereas GB-based kernels and ODIN seem immune. Perhaps we are just getting lucky there, but I don't believe so because the reported rates of failure on ICS are just so much higher whereas GB and ODIN seem to have none (I won't say definitely none but seemingly none)

There probably is some change in how the ICS-based kernels handle the erase that is triggering the issue or moving the issue from being something very rare to something seen more often.

I think this thread was an overall win even if this is all we get from it as we now understand the issue better.

To get your PRV/fwrev, you can use this (if you have busybox installed):

If you don't have busybox installed just visually parse the line, match the serial # (0xd3f24fe6 - example only - yours will be different) with the cid, and look at the 2 numbers before the serial #.
[Samsung Epic 4G Touch] garwynn:
I immediately thanked him once I saw these in my inbox this morning - I'll pass on any other updates I get on this.

However, anyone that has the ear of someone at Samsung - it wouldn't hurt to ask them to release this. I can't see this issue getting smaller as official and unofficial ICS builds keep growing. Hopefully the more pressure put on Samsung for this they will release it. With so many devices affected, it just seems practical business sense to do so... unless the update method is extremely convoluted.

On another note it confirms the workaround in place - going to GB kernel for wiping - will avoid the "superbrick" issue. The 32 Kb issue should be correctable based on his responses even if it is experienced.
[Samsung Epic 4G Touch] sfhub:
Sorry I read it fast and will go back an re-read, but I apparenlty missed where he said GB kernel can wipe without issues. I saw where he said in their development of ICS, they noticed the problem, but I didn't take that to mean GB was immune (though it does seem so). Anyway I will go back and read again, I probably just missed it first time around in my excitement to get some new info on the issue.

Ok, I went back and reread what was quoted and I still don't see where it confirmed using GB kernel for wiping was safe. If indeed he did say that, wouldn't it make more sense for them to figure out why the GB-based kernel wiping was safe and forward porting the GB code to ICS? That seems like less work than having everyone update EMMC firmware. Now I'm NOT saying GB kernel is not immune, as it appears it is from our experiences. What I'm saying is from Ken's responses, there was no indication that the GB-kernel was safe and the fingers were pointed on PRV/fwrev 0x19, so they may not be aware of or even pursuing a difference in behavior between the GB kernel and ICS kernel.

Also just to confirm we are talking about the same thing, there are 2 issues

1) emmc lockup on erase

2) 32kb zero corruption

He said #1 is fixed in EMMC PRV/fwrev 0x25 but is present in 0x19

He said #2 is definitely in PRV/fwrev 0x25, but MIGHT also be in 0x19 (he didn't sound sure of it, rather was making the assumption if it was in 0x25, likely it was in 0x19). Also the 0x25 patch for 32KB zero issue likely would NOT work for 0x19.

IMO while getting #2 fixed would be nice, the issue we care most about is #1.
[Samsung Epic 4G Touch] garwynn:
I'm making a assumption based on this:

I can see why they would be doing this during the kernel dev for easy test resets, and it may even part of their official testing scripts (or Google's equivalent). They probably thought the same thing we did - it worked before, why wouldn't it work now?

I'll leave it up to you guys - can definitely ask to confirm if we'd feel better doing so. In the meantime I'm going to try and ask Samsung support to see if they're willing to release that patch.
[Samsung Epic 4G Touch] sfhub:
I didn't make any assumptions about GB for that statement because there was no mention of GB. The reason I didn't make assumption is because since they are developers Google, it is possible the team in question only did ICS development and either some other team or Samsung did the GB development. I wouldn't be surprised if GB is basically stable so all the development is platform level porting and most of the developers at Google are working on ICS and newer. So the statement "during ICS development" might not imply they also did GB development and didn't see the problem then.

Actually thinking about it, if Ken's team was working on just ICS and Samsung was working on GB, but Ken's team discovered the EMMC lockup issue, neither party may have put 2 and 2 together and realized that GB is not (or far less) susceptible to the problem. I could see ways the information could have been passed around where the data sets never crossed.
[Samsung Epic 4G Touch] Entropy512:
Remember - Google has NEVER had direct involvement with Exynos devices.

The Nexus S has a completely different flash memory architecture.

The Galaxy Nexus NEVER saw Gingerbread - it was designed from the ground up for ICS. Based on what he has said - no Galaxy Nexus was ever released with the buggy 0x19 firmware revision, because of this bug. This bug was seen and fixed during the Galaxy Nexus development process (both hardware and software).

His comments about fastboot indicate he is not very familiar with our devices.

As to why Odin is safe - it never does an erase before writing, it just writes.
[Samsung Epic 4G Touch] okantomi:
To get your PRV/fwrev, you can use this:[/QUOTE]

Thanks...the line: cat cid | cut -b 19,20

previously was missing the "cut" and didn't work.

I'm on 0x19 as well. About two weeks ago, I had a bad mobile odin flash and was bootlooping to stock unlocked recovery. I did a factory reset/wipe data through stock recovery and somehow survived long enough to pc odin one of sfhub's one clicks...all fine now, but I can't believe how lucky I was not to trigger the super brick.
[Samsung Epic 4G Touch] sfhub:
The other statements I agree with, but I'm not sure why this statement was relevant. If

1) problem is related to the EMMC and its firmware

2) we have the same model name and PRV/fwrev as the problem EMMC

3) we are issuing the erase commnd under certain scenarios and seeing the lockup

If model name and PRV matches and we are issuing the same EMMC command, then their experiences are applicable to ours, no?
[Samsung Epic 4G Touch] sfhub:
You need busybox installed. If you have busybox installed then you might not have the symlinks setup.

So try

cat cid | busybox cut -b 19,20
[Samsung Epic 4G Touch] robertm2011:
Right on. But do you think that the fix will be able to resuscitate my bricked phone? Not a huge problem (at least, to me), I have my new phone, and the other one makes a really upscale paperweight.
[Samsung Epic 4G Touch] okantomi:
Thanks...I think I might have had some other syntax error...got it now and it's the usual suspect: 0x19.
[Samsung Epic 4G Touch] sfhub:
May or may not. Ken mentioned something about screwing up data structures in the chip. So maybe new EMMC firmware could recontruct those data structures (assuming we don't care about preserving the existing data on the chip and can just reinstall/repartition/reformat everything)

However, at a minimum, I think you'd need to be able to boot into ODIN D/L mode so you'd have a way to get the firmware onto your phone. If I recall correct, your phone couldn't boot into ODIN DL mode either?
[Samsung Epic 4G Touch] sfhub:
Anyway, I added a way to visually parse the CID (just the earlier post from garwynn with more visual emphasis on the parsing aspect)
[Samsung Epic 4G Touch] robertm2011:
If that's the case, you're right; I was (and am) unable to boot at all, so I would call that a definite "super brick".
[Samsung Epic 4G Touch] garwynn:
Reposting the answer when I specifically mentioned our test and the resulting brick:

I don't know how far MobileTechVideos got on JTAG for this case... if he can get to the eMMC even if it wasn't booting, he might be able to apply the wipe/patch code that Ken is talking about. (Only case I heard him mention was where it booted.)

FYI, I've already called Samsung tech support and asked them to fire off an email to the dev team and see if they can patch this in the E4GT builds as it may leave it open to bricks. Supervisor is supposed to fire it off today and it will take at least a day to get a response.
[Samsung Epic 4G Touch] sfhub:
If our understanding of the issue is now accurate, I would imagine they would see a rash of superbricks with the ICS OTA update, because just like the NoData ODIN OneClicks, the OTA will probably work in about 85% of the cases (others resulting in bootloops or random FCs). Some subset of those people will then go into recovery and do a wipe data/factory reset. Then some subset of those will hit the EMMC lockup bug.
[Samsung Epic 4G Touch] garwynn:
Wouldn't this also affect managed devices with a security feature that does the data wipe/factory reset and the standard option on the menu? Imagine John Doe just upgraded and wants to sell his phone - so he does a factory reset.
[Samsung Epic 4G Touch] sfhub:
If they are triggering the same sequence of commands as wipe data/factory reset in recovery then yes. If not, then maybe.

I'm glad we did the testing on a stock kernel with just unlocked recovery as it eliminated all other distractions and if we know for sure the even stock recovery on stock kernel can cause the EMMC lockup (and previously we saw Rogue CWM and CWM Touch cause the EMMC lockup) then we are pretty sure any recovery will be susceptible to the lockup.

The only question is whether we are playing russian roulette with a gun that has a 1000 chambers, 1 chamber, or somewhere in between.

Now if the other methods of reset are using a different set of commands or issue them in a different sequence than Recovery, then we don't know if the EMMC lockup will be triggered. Most likely yes, but cannot be sure. If we had someone testing those scenarios and encountered an EMMC lockup, then we can say for sure that operation is suspect also.

I think if we were able to at least recover from the EMMC lockup, we could make a lot more progress. It is hard to keep asking people to test things and risk superbricking their phones.
[Galaxy Note GT-N7000 Q&A, Help & Troubleshooting] islandmixed:
Hey

Quick question, i have a clock widget which i downloaded a few years ago from the market place and i want to add it to my note. Now the widget no longer is available to download in the market so can i move it over and how? I did this before i believe when i first got my htc hero, i moved it over to my desire so now i want this clock moved to my note. Its a bob marley clock but its banging, i just love it lol.

cheers.
[Galaxy Note GT-N7000 Q&A, Help & Troubleshooting] mendiculus:
Save the app with TB. Copy the TB Folder to the sd of your device and install over TB again.
[Galaxy Note GT-N7000 Q&A, Help & Troubleshooting] devwithzachary:
Yes you should beable to back up the widgers apk via a app like titanium backup or any app that can backup apps
[Galaxy Note GT-N7000 Q&A, Help & Troubleshooting] islandmixed:
I dont have root so i will look for another program to do it. thanx for the help, hopefully it works
[Galaxy Note GT-N7000 Q&A, Help & Troubleshooting] tknguyencsu:
If your clock program can be moved to the SD card then you can copy it: Install the free ES explorer from the Market. Go to the setting of this program and "Enable up to Root directory". Then press the Up arrow until you see the folder mnt, go to this folder you will see the folder asec. Your clock program will be in one of the folders within asec with a name "pkg.apk". However the icon remains the same so you can recognize it. Copy this program to your sdcard and rename it.
[Galaxy Note GT-N7000 Q&A, Help & Troubleshooting] islandmixed:
Thanks for the help guys. All i did was back up the app from a program i used and stored that bk up on sdcard, den put thr sdcard into my note and it was their. Wrking great
[Galaxy S II Q&A, Help & Troubleshooting] wootyv:
Hi, i wanted to root my s2 with cf-root method but i can't find my insecure and original kernel (XWLP4). I read somewhere i can use 1 as close to mine, which would be XWLP6 i think, is that true? won't this have any consequences? i'm using ICS 4.0.3 and i don't know u'll need it but baseband version XXLPS

thanks in advance
[Galaxy S II Q&A, Help & Troubleshooting] wootyv:
thanks, so i'll give it a go with lp6, that's the closest i can find, together with lp2
[Galaxy S II Q&A, Help & Troubleshooting] wootyv:
erm, i've read in the same thread that in version 5.4 of ics versions the sd-card problem i solved, lp6 is v5.2, does this mean my sd-card wont mount? maybe better give lp3 a go since it's v 5.4?
[Galaxy S II Q&A, Help & Troubleshooting] ctomgee:
Same thread, post 8:

LP6 doesn't have *** after it, that would seem to indicate it does NOT have an issue with mounting storage.
[Galaxy S II Q&A, Help & Troubleshooting] wootyv:
oh i'm sorry, must have read over that (better won't when reading flashing instructions ;) )
[Galaxy S II Q&A, Help & Troubleshooting] wootyv:
can be interesting for other users: with lp6 i didn't get past bootscreen, neither on rooted as on original kernel, lp3 did the job perfectly