yashsingh1/xdaforums huggingface dataset:
[Samsung Epic 4G Touch] garwynn:
Well now... that would definitely change the scope of the problem if true. Has anyone tried this on the i9001 as it does have the MAG4FA? I've been trying to find any test cases on XDA but haven't seen anything yet.

Anyhow from what you're posting it seems there is still progress being made albeit slow.

An "EU situation" has me going here:

http://www.jedec.org/sites/default/files/Victor_Tsai.pdf

Note in 4.5 the introduction of a "Discard" feature:

Discard Command

– A variant of the TRIM command that is more memory technology friendly

Is it possible that 0x19 was based on 4.4 standards but not fully compliant and 0x25 may be fully 4.5 compliant (meaning it can use the discard but not secure erase/trim?)

Again, know this is your field more than it is mine and that you might not be able to respond in public... but might be worth asking them the difference for the change.
[Samsung Epic 4G Touch] Entropy512:
EU situation - http://xdaforums.com/showthread.php?t=1447303
[Samsung Epic 4G Touch] niggza:
I have. I odined sfhub ff18 ND got stuck on data.img. But the gnote pit nd eg30 brought me back
[Samsung Epic 4G Touch] KnukLHead:
I also resurrected my other e4gt but when I tried the pit and eg30 together it didn't work. I tried it twice but the I did the eg30 by itself after that and it stuck.
[Samsung Epic 4G Touch] AndroidRocksSocks:
I suggest following the step by step instructions I posted a few posts back.

If you have this certain problem where data.img gets stuck. And you can get into Download mode and Recovery. Then the method should work. You shouldn't run into any problems with the step by step instructions.
[Samsung Epic 4G Touch] KnukLHead:
Did the step by step and it didn't hang up. It passed. Still wouldn't boot so since I figured the pit stuck I just odined the rom and it worked then. Everyone else should follow the step by step I just had different results
[Samsung Epic 4G Touch] tubasteve:
is it possible that the poeple wiping the phone have an encrypted emmc pit? meaning if they are trying to flash with a encrypted internal sd is this the cause? i havent had the issue, just and idea i guess?
[Samsung Epic 4G Touch] AndroidRocksSocks:
The second part of the step by step instructions are similar. I just had to flash the stuff inside recovery and everything booted up correctly.

Would appreciate it if you hit that Thanks Button on the step by step guide. After all, it did guide/help "somewhat." :highfive:

---------- Post added at 02:38 AM ---------- Previous post was at 02:30 AM ----------

All I know is: A solution works.

You can search throughout this thread to see. But I'm not worried about the cause of it. I did a factory reset on AOKP-39 in the settings menu, that was the cause of my E4GT getting messed up.

Find a solution, learn from the mistake. :victory:
[Samsung Epic 4G Touch] sfhub:
I'm not sure how the FF18 NoData got stuck on data.img, it doesn't include data.img. Are you sure you weren't flashing the Full OneClick?

BTW in case it wasn't obvious, you can use custom PIT files with the .tar.md5 files in the 2nd post of the ODIN OneClick threads.
[Samsung Epic 4G Touch] sfhub:
IMO it isn't a standards compliance issue. It is just a bug in their internal implementation, independent of the standard they are supporting (though they may have upgraded standards versions at the same time as fixing the bug)
[Samsung Epic 4G Touch] sfhub:
This is not the issue. This can be proven because Android encryption (at least on our phone) is handled at the OS-level, so ODIN flashes should not be affected.
[Samsung Epic 4G Touch] Entropy512:
Nope. See sfhub's response below, and also reread this thread. We know what causes the damage and that's not it.

It's a standards compliance issue, just not the one theorized. If a device suffers permanent damage when handling a command required by the standard - then yes, it is a standards compliance issue.

Yup. And the EU issue on galaxys1 devices likely has nothing to actually do with encryption - it's just the error that results when /data is completely inaccessible. AdamOutler and I spoke with our contact at Samsung and they said "it's unrelated because we do encryption in a different way than Google" - but I think we ran into a bit of a language barrier with that one as it has nothing to actually do with encryption, the error is misleading.
[Samsung Epic 4G Touch] quick99si:
I began experiencing hangups in Odin after trying to flash the PIT/TAR combo. It would take 4-5 attempts to get the flash to complete, always getting stuck when writing FACTORYFS (oh-oh!).

I can also confirm that Blazer 4.1 can be flashed via the posted EL26 kernel. I did not get any FC or issues whatsoever, but had much different results with Calkulin's GB rom. This may help those who may be under the impression that you have to to go ICS in this situation.
[Samsung Epic 4G Touch] garwynn:
I'm trying not to flood the thread or hound you guys with questions but this definitely piqued my interest.

In order to be a standards compliance issue it would need to be known what standards both the eMMC and the controller were originally designed on. MAG4FA has been noticed in designs since 2010, which means it should have been designed on 4.4 standards (2009).

While waiting to hear more I guess I can chew on this:

http://blog.datalight.com/securely-delete-files-on-flash-media

http://cseweb.ucsd.edu/users/swanson/papers/Fast2011SecErase.pdf

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

..to at least better understand the background of what it is

supposed

to do.

Reason I asked is with Samsung's prevalence in eMMC and memory it would make sense that they may have had a design in place long before the 4.4 standard rolled out - in which case they probably stuck with their solution until it caused problems. Why reinvent the wheel if you don't need to - not to mention probably a little bit of pride in their own solution if they felt it exceeded standards.

Slightly OT:

Since you guys are now into conference calls with Korea I will be taking any responses that I get from TX and asking them to coordinate with you for further assistance... figure that's the best approach for now unless others are allowed into the conversation down the road.

Good luck on today's calls; I'm guessing they've already concluded though or will be later tonight if not this morning.
[Samsung Epic 4G Touch] Entropy512:
Adam's call was 8 PM local for him (9 PM Eastern) - same for tonight if we can figure out the callin number. (last night's was a point-to-point call. international teleconferences are a ***** - we have participants in Louisiana, New York, Korea, and Poland! No matter what, someone is calling in at 3 AM local or something painful like that. :) )
[Samsung Epic 4G Touch] garwynn:
I'm going to post there as well but I would really like to look at the partition table for the Captivate. Between the E4GT and Note there was a range where the lockup appeared to occur so I'm wondering what is in that range for the Captivate...
[Samsung Epic 4G Touch] Pastie13:
Would this fix my phone? My symptoms are about 2 weeks ago the phone started some random reboots, this is on the stock rom, at the same time I notice at each reboot it would reinstall the app updates and lose all my phone and text message logs. I tried to install other GB roms, but non will take. I tried to install the Clockworkrecovery and it did not take. Is this a form of a bricked phone?
[Samsung Epic 4G Touch] garwynn:
My advice before anything else would be to try applying the EL29 Odin one-click package (full, not the NODATA version) and see if the problems persist. If they don't then go from there - if they still do please let us know and can troubleshoot further.
[Samsung Epic 4G Touch] jgaviota:
The problem with the Captivate is not related to wiping, it occurs out of the blue. It completely locks the chip, AdamOutler knows about it, so he should be able to explain to Samsung what is happening.

Also it seems not all Galaxy S variants are vulnerable, the Captivate certainly is but I haven't seen a I9000 with that problem.
[Samsung Epic 4G Touch] garwynn:
Yeah, that person from Poland hopefully doesn't have work early the next morning! (9 pm EST is either 3 or 4 am CET if I remember time zones correctly.)

---------- Post added at 05:38 PM ---------- Previous post was at 05:35 PM ----------

In that case without knowing more of the details it is hard to troubleshoot... will hope that Adam and Entropy can look into it more.

Would be nice if this results in a more official channel between XDA devs and Samsung; one could always hope!
[Samsung Epic 4G Touch] jgaviota:
Also the problem with the Captivate happens "randomly" with ICS and there is no official ICS for it so I don't think it's in Samsung's radar.

I also hope that Samsung starts viewing XDA as partners and not a nuisance.
[Samsung Epic 4G Touch] Pastie13:
I am nearly 100% positive that did that, it was called SPH-D710.EL29_CL852097_ROOTED-oc-sfx. After I did the odin and the rom it rebooted to the lock screen(which I had disabled) and continued to update the apps and had the same issue. It looked like it took the changes but everything on the phone was the same, that did not make any sense to me. Was that the right rom?
[Samsung Epic 4G Touch] garwynn:
OK, if it's booting and you're getting to apps, first good news is that it is not the bug discussed on this thread. Second, can you clarify what you meant by above? After you run Odin one-click and let it restart it should look basically like it did from the factory (minus whatever you have in the /sdcard folder and on any external SD card.) If not then there's something else going on.

You can always try a factory reset but I don't see this being necessary as the full package should basically wipe anything that was previously there...
[Samsung Epic 4G Touch] Pastie13:
I just did this remotely with my wife holding down the needing codes to get into the recovery. I ran the OC -SPH-D710.EL29_CL852097_ROOTED-oc-sfx passed and then it boots back up. Upon reboot the phone asked to be activated again when tried to make a call and will not text(like when it was new), but it is still updating the apps though auto update in the market, it does not look like the it did from factory, it still has the lock screen and has the same photo that I had on it when all this started. I did try a factory reset, it comes back to same lock screen and photo, nothing goes back to factory. Anything I have done it always comes back to the picture I put there a few weeks ago. I even disabled the lock screen in settings, but upon reboot it shows back up.

---------- Post added at 08:16 PM ---------- Previous post was at 08:11 PM ----------

Hey Garwynn I really appreciate you help BTW!:good:
[Samsung Epic 4G Touch] Entropy512:
The range seems to be semi-related to what gets wiped. Which is I think why people who die during a wipe in CWM often have systems that boot, but those who got killed by an update-binary that wiped /system often have dead bootloaders (/system is before /data).

On GalaxyS devices, the eMMC has only two partitions - /data is right at the beginning (as /system and other partitions are on a different storage device). My previous theory was that the whole chip was appearing locked up because the damage hit the location where the partition table was stored, but jgaviota's info below invalidates this theory.

d'oh. That's strange then... Wonder if it's a GPIO sequencing issue then. If it does indeed seem random and sudden and not connected to wipes/resets, then it most likely is something different.

I'm really hoping that the effort Adam is trying to get kicked off will be the start of a VERY productive partnership.
[Samsung Epic 4G Touch] garwynn:
I have an idea on that but you'll see it when you have time - after I get your feedback on it I'll post here if you think it holds water. Problem is that it doesn't really explain the entire eMMC dropping off on the Captivate

unless

the erase operation is being done for the entire eMMC in one swoop (whereas I think it might be doing the eMMC on the Note and GS2 on a partition by partition basis).

I hope so as well... especially if it isn't so exclusive down the road to get the ear of Samsung devs.

---------- Post added at 08:53 PM ---------- Previous post was at 08:42 PM ----------

This may sound as a silly question but when you're flashing the ROM are you doing it from Recovery or Download mode?

If you're not sure, try the following command if you have ADB installed:

ADB REBOOT DOWNLOAD

Or turn off, hold VOL DOWN+POWER until you see it ask to download... press VOL UP and it should show an android with "Downloading... Do not turn off target!"

Sorry if it sounds patronizing but I made this mistake early on as I didn't realize this phone has a recovery (VOL.UP+POWER) versus download (VOL.DOWN+POWER).

Have you tried clearing out the internal memory and removing any inserted MicroSD card?
[Samsung Epic 4G Touch] Pastie13:
This may sound as a silly question but when you're flashing the ROM are you doing it from Recovery or Download mode?

If you're not sure, try the following command if you have ADB installed:

ADB REBOOT DOWNLOAD

Or turn off, hold VOL DOWN+POWER until you see it ask to download... press VOL UP and it should show an android with "Downloading... Do not turn off target!"

Sorry if it sounds patronizing but I made this mistake early on as I didn't realize this phone has a recovery (VOL.UP+POWER) versus download (VOL.DOWN+POWER).

Have you tried clearing out the internal memory and removing any inserted MicroSD card?[/QUOTE]

Vol Dwn+ Home+ Power, then up, then I used ODIN. I think is the correct way, right?

I have no SD Card.

I tried the cleaning options in the stock recovery screen if that is what you speak of.

I just do not get how w/e I have tried it shows the same home screen that was was there before I tried loading the new rom, like it does not want to take a total install. Can I just delete the whole drive and install fresh?

---------- Post added at 09:45 PM ---------- Previous post was at 09:22 PM ----------

What is ADB DOWNLOAD REBOOT?
[Samsung Epic 4G Touch] garwynn:
ADB Download Reboot (if you have ADB installed and USB debugging enabled) will do the same thing - get you to download mode. I just find it easier then shutting down and holding keys :)

In the one-click application there is an log. Can you run one more time, copy and paste the results here please? Something isn't adding up - if it passed it should be back to defaults; there's no way around it unless you're using NODATA; but even this wouldn't survive a factory reset in Recovery.

Can still thankfully say it's not this bug. If it was this one you wouldn't be able to boot.
[Samsung Epic 4G Touch] Pastie13:
I guess I should start a another thread as not to mess yours up, I will after this next post. Where do I find the long I am running OC again right now.

---------- Post added at 10:27 PM ---------- Previous post was at 10:20 PM ----------

I guess you mean this log? I just ran it again.

5> Added!!

<OSM> Enter CS for MD5..

<OSM> Check MD5.. Do not unplug the cable..

<OSM> Please wait..

<OSM> Checking MD5 finished Sucessfully..

<OSM> Leave CS..

<ID:0/005> Odin v.3 engine (ID:5)..

<ID:0/005> File analysis..

<ID:0/005> SetupConnection..

<ID:0/005> Initialzation..

<ID:0/005> Get PIT for mapping..

<ID:0/005> Firmware update start..

<ID:0/005> recovery.bin

<ID:0/005> hidden.img

<ID:0/005> boot.bin

<ID:0/005> Sbl.bin

<ID:0/005> param.lfs

<ID:0/005> cache.img

<ID:0/005> zImage

<ID:0/005> factoryfs.img

<ID:0/005> data.img

<ID:0/005> modem.bin

<ID:0/005> Completed..

<OSM> All threads completed. (succeed 1 / failed 0)

<ID:0/005> Removed!!

<ID:0/006> Added!!
[Samsung Epic 4G Touch] garwynn:
At this point I'll suggest posting a new thread in the Q&A for this issue. It is odd since obviously the ODIN flash was successful, was verified by name to be the full package and yet settings in /data remain :confused:

I believe sfhub and Calkulin both have a utility available that will wipe everything on the card. I haven't used it so you'll want to read up on it to see if that may help. Only thing I can think of was something was in /sdcard and being pulled over /data - but if /sdcard is empty then I'm stumped at the moment.
[Samsung Epic 4G Touch] Pastie13:
Thanks, I need to make a few more posts before I have thread starting privileges. But I am working on it. I know it is a very weird issue.
[Samsung Epic 4G Touch] Entropy512:
VERY promising results from Samsung tonight.

I'm 90% certain we will be receiving the information needed to convert "superbricks" into "traditional" hardbricks (bootloader gone) - which can be recovered via JTAG.

Adam and I worked on trying to get the information required to resurrect "traditional" hardbricks via USB - We're not sure if we will receive this.
[Samsung Epic 4G Touch] sfhub:
Yes, tom-ae-to, to-mah-to, as phrased in your response, standards non-compliance is a superset and includes bug in the implementation, however that was not the context I was responding to (as you alluded to) We know what each other mean, which is what is important.
[Samsung Epic 4G Touch] garwynn:
Just curious if you got any updates after the conf. call. Great news about the JTAG solution but I would ask to keep pushing for a USB/ODIN based solution if at all possible. Reason being the first still requires getting it to someone who can JTAG it - USB/ODIN can be done at home.

So, let's assume we don't get the necessary resources to boot by USB:

Still don't see why you couldn't ODIN a package, reboot - pkg then copies bootloader, download and recovery to memory, wipe/flash/update eMMC, verify, drop memory back to eMMC and reboot to download mode for ROM push. This shouldn't require boot by USB and therefore should already be possible. Won't fix them all but would reduce the number that need to be sent to JTAG for repair.

While it's more a technicality than anything have they mentioned how they propose to fix? Wiping the eMMC and resetting the card status is good but unless they patch the controller function and the kernel (by removing MMC_CAP_ERASE if the offending controller function is left in) we're looking at it happening again. And so far haven't heard much lately if they are officially committed to patching the source kernels and how they intend to do so.

Thanks again for your help (and the other devs) in this matter - will keep looking forward to anything you can provide for now.
[Samsung Epic 4G Touch] Entropy512:
Yeah, this is effectively what Samsung proposed. I raised the issue that this approach has two flaws:

1) I'm going to make a lot of mistakes when implementing it, as I prototype a recovery solution, I'm going to hard brick VERY frequently.

2) There is a significant risk that if the process fails between wipe and repartition/bootloader repopulation, we wind up with a brick.

I still haven't heard much in terms of this. However it seems like in the T989, they removed MMC_CAP_ERASE from the kernels.
[Samsung Epic 4G Touch] REAVER117:
@Entropy512

Let me know if you need any help testing the JTAG solution for the Note, I've got mine soldered to a Riffbox right now. The JTAG pads on the Note are extremely small so it's quite a pain to get them soldered.
[Samsung Epic 4G Touch] garwynn:
#1 should only done with a RIFF box on hand IMHO so that if you do brick you can quickly restore it - and would obviously require the JTAG solution in place before we can work on the script package.

#2 is true - but in those cases it should be sent for JTAG.

The benefit of this two step approach is more for carriers and Samsung support than it is for those of us on XDA. I suspect that most shop tech support will have ODIN on site whereas JTAG will probably only be in the regional centers - maybe some guys from the carrier tech teams will be willing to confirm that understanding. John Doe can then walk into a carrier store with a high likelihood that he'll be walking back out with a working device - either by fixing his device on the spot or giving him a refurb as it is more likely to recover the device than taking it as a loss (which is what most are doing now.)

A win-win for everyone so long as Samsung pushes it whatever solution it agrees with to the carriers as well as us here. Doubt the carrier would say "No" to it either.

Another step in the process, albeit optional, would be applying a custom .PIT file to restore functionality enough to pull the user's files from the UMS partition prior to eMMC wipe/repair.

Just an FYI - I'm expecting a second E4GT in the mail today. If I can't hook it up for my wife (it will be up to the MVNO if they allow it) then I'll have one just for dev efforts. If they allow it then I might go ahead and pick up yet another just so that I can experiment a little more as well; my biggest reason to not do more right now has been the lack of time as well as uncertainty that I could replace my phone without having to buy it from the MVNO at $550 a pop.
[Samsung Epic 4G Touch] jgaviota:
If you are superbricked take a look at this post:

Gt-N7000 Hard Brick -> i9220

He superbricked it; after a wipe couldn't flash, would get stuck on factory.fs

JTag guy tried to fix it and as expected it was a no go, but he could revive it with a i9220 rom and pit through JTag.

I don't know if the partitions are different or if the guy was lucky and it was not a true superbrick.

Good luck
[Samsung Epic 4G Touch] REAVER117:
Hmm, I'll try that when I get home from work. I only ever tried using an N7000 DLL, I guess I'll give the i9220 a shot.
[Samsung Epic 4G Touch] nfribeiro:
I just can not understand why Samsung does not release a fix when the problem is well known?

Can someone explain to me the reason for this long wait?

Is it so hard to fix this? Do they know how? Are they waiting for 4.0.4?
[Samsung Epic 4G Touch] Entropy512:
Samsung seems to really currently have a "don't release information unless we REALLY REALLY HAVE TO" mentality.

It has been very difficult to convince them to release the information required, but they're coming around slowly.

There's a bit of typical large company politics at play here - multiple divisions are involved (Mobile and Storage at a minimum) and they each have their own management chains. In addition, I think we're dealing with some differences in cultural views regarding proprietary information and such. At Samsung, it seems that they try to consider as many things as possible to be proprietary, even things that most other companies wouldn't consider to be proprietary. As opposed to where I work - we can get in serious legal hot water regarding contract terms and conditions for claiming something is proprietary that isn't.
[Samsung Epic 4G Touch] garwynn:
They really have to if they don't want to have this blow up in their faces; it's the nature of the beast. Even if no one from XDA mentioned it and let it go, it would hit critical mass where too many bricks would send the media digging for answers. And they

really

don't need that right now with the cases going on in California.

I don't think that's cultural - that seems to be a more defensive strategy against Apple and quite possibly Google now that they closed the merger with Motorola Mobility. Just look at some of those wide open patents that have been used in the cases between the three - and keep in mind that Apple just got an injunction on the Galaxy Tab 10.1 (although it probably won't mean much since a new one is reportedly due out soon.)

It is part of the reason I fully expected NDAs as a condition to get anything out of them,

especially

information they considered to be exclusive IP - surprised they haven't forced those yet to be honest. And it may still be necessary for individuals (other than carrier techs) to get their hands on this, but let's be optimistic and hope not.