yashsingh1/xdaforums huggingface dataset:
[Samsung Epic 4G Touch] agat63:
Below is a copy of the post I made in my kernel thread:

I don't think it's kernel related.

Guys I'm not saying I'm perfect nor I'm trying to defend myself.

my v0.5.4 has been downloaded:

tar format 569 times

zip format 587 times.

This totaling over 1100 times.

If kernel/recovery wouldn't be safe we would of have more of this problem.

More bricks.

I think there's something went wrong.

I can't say what and I can't say why. But knowing that the kernel has been used so many times without any hick ups or problems

makes me think there should be something not kernel related.

I really feel sorry for the brick and I hate the fact that it happened wile using my kernel.

I'll gladly fix any problem and/or brick cause.

Just checked source on my laptop.

CAP_ERASE command is not there.

Unless something went terribly wrong and it came back somehow it should not be there.

End of quote.

I might be wrong. I need any input I can get.

Please let me know if you thing there something wrong in my logic.

I wanna help and I wanna fix any possible problem but it looks like I can't do it alone.

Chip in guys and help me make our experience as safe as possible.

Thanks in advance for any input/idea/thought.
[Samsung Epic 4G Touch] revamper:
I've used calks format all multiple times on unsafe recoveries before I knew about the brick bug and my phone was fine. I remember reading a lot of people used calks script and their phone didn't brick...
[Samsung Epic 4G Touch] Dchibro:
It could be the same reason why chris41g's AOSP kernels were vulnerable to the brick bug for a short while. You may want to reach out to him to see if he's able to provide some advice as to why it happened. Also, entropy is one of the most knowledgeable people on the brick bug, so you may want to reach out to him as well.

OP - I'm sorry you bricked man. This is the reason that even with all of these "safe" recoveries, I still do all of my flashing from stock EL26. It's tried and true and it only takes an extra 30 seconds at the most to flash using Mobile Odin.
[Samsung Epic 4G Touch] mjs2011:
Yep. Seeing this thread is enough reason for me to keep using that method as well.
[Samsung Epic 4G Touch] PhAkEer:
This is the first Ive heard of an Ecap on an Agat.. That being said,

Its something we are all always at risk (SLIGHTLY) because the negative effects of EraseCap a built into the phone. ICS software just so happens send a command that makes it more likely to be triggered...

El26 is only and can only be as safe as an ics source built kernel IF the source kernel has the Ecap hair trigger removed.
[Samsung Epic 4G Touch] Dchibro:
And therein lies the rub. The only way to know it's truly safe is to dig into the code and actually know what to look for. Most people, myself included, either don't or don't want to take the time. Also, things change, kernel bases change, and since we're all human, mistakes can get made. There's no mistake that can be made when flashing from a GB based kernel.

I certainly wouldn't mind the days when I could use my current recovery for anything I wanted to do, but for me, those days are over on this phone. The alternative is barely an inconvenience anyways.
[Samsung Epic 4G Touch] PhAkEer:
I dont think your quite hearing me....

the damage is done by mmc firmware that is on a level too deep for us to alter. It has been in every single epic touch since it was a wee little memory card on a little moving belt with the others...

Fy,gb,ics,jb has nothing to do do with it. If it were an Android issue it wouldve been fixed immediately and if it were a simple removal of a single line Samsung wouldve dealt with it just based on XDA forum knowledge...

It is embedded in your device.

As said, ICS just had an aspect that made it considerably more likely
[Samsung Epic 4G Touch] times_infinity:
the only way to keep the bug from being triggered is to remove the function that causes it in the mmc driver source.
[Samsung Epic 4G Touch] Dchibro:
Naw I'm hearing you fine, and understand the bug exists at the emmc firmware level. I'm just not communicating my point well, which ain't the first time.

My point is, the offending function that can trigger the bug does not exist in the GB kernel source, while it does in the ICS kernel source. As times said, the offending function has to be removed manually, thus subjecting the environment to human error. When working with my device, I prefer to limit human error as much as I can.

I know you already knew what I said above, but it's the basis for my original post... I think. Often times I'm playing with my 4 year old, then pick up my phone and post on these forums. Yeah you can probably imagine how that usually works out. I usually can't carry a thought to save my life.
[Samsung Epic 4G Touch] lord dredd:
I am a newbie ,

and came here from the unbrickable ( if you have faintest idea about what you are doing ) FASCINATE.

after reading a lot and asking a bunch of good guyz i felt safer with agat's kernel and recoveries combos plus the format all script.

But this latest BRICK thingy is frustrating and scary

sorry for the OP really.

hope there is someway out and people can use and flash this awesome phone without the fear of bricking .

Regards
[Samsung Epic 4G Touch] PhAkEer:
Lmao only reason I break it to the special level is because I ALLWAAAYS have a hard explaining myself on xda...

Even though in person Im fully social and and can hold a conversation with anyone.... Lmao

Id avoid the FH13 from what seems.. It looks like a big boo boo imho but
[Samsung Epic 4G Touch] stonesaber:
I'd like to add one thing. There are several who had the B.L.O.D. flashing the GB CIUI port that was posted then locked down because of the bricks seen here.http://xdaforums.com/showthread.php?t=1883383 I have bricked several of these phones and the last one was with the CIUI port flashing from the safe EL26 kernel. I was very surprised that it bricked from EL26 but it did. So since that happened, I don't think anything can be considered "safe" for these phones. Although that hasn't stopped me from flashing...
[Samsung Epic 4G Touch] agat63:
This is a copy of my post in my kernel thread.

Hopefully it will help to understand the problem better:

Let me try to explain how the recovery works.

When we were dealing with brick back sfhub gave me a nice lecture to this subject.

In recovery:

1. When using tasks from recovery menu like wipe cache, wipe dalvik wipe/factory reset recovery is using binaries packed into recovery.

Since recovery has been compiled with CM7 (GB) source the bug is not present in recovery and any task is safe.

Thus that many successful wipes using my kernels with tREC.

2. When flashing zip files.

Any flashable zip has updater script and updater binary packed into it.

Recovery will read updater script and execute it line by line.

To execute commands from updater script recovery needs binaries and will use binaries packed into zip file.

At this moment your current kernel and/or recovery binaries are not that important since those are not used.

As you can see there are 2 sides to this problem. 2 major components.

You need safe recovery/kernel to perform tasks in recovery and you need safe binaries packed into zip to make it safe to flash.

So if updater script has format() command in it it will use binaries from zip to perform format() and if binary not safe it might cause the brick.

Please someone correct me if I'm wrong here because that's how I understand the process.

Many ICS rom zip files had GB binaries packed into them so we haven't seen any bricks since CM7 (GB) compiled recovery has been used for wipes.

AOSP/AOKP/CM/JB are coming with their own binaries and I can't say if those binaries are safe.

Crhis41g has created a safe recovery that would use binaries packed into it no matter what binaries are coming with zip.

But since it has an additional argument to use it's own binaries most of old zip would not work with it.

Updater scripts should be edited for that additional argument for recovery to work.

I think we should check with rom dev's and make sure they have safe binary files packed into zips.

Id they have than we should look closer to how ICS kernerls/recovery flashing JB and may be there's something that we need to do to make that process safe.
[Samsung Epic 4G Touch] Omar04:
I soft bricked 7/10 when flashing Calk Format All and then JB (any) I stop using it and now doing it manually no a single soft brick anymore (EL26 always) I mentioned it few times but most of the time, I got flamed or told it was user error. I don't understand everything not a linux/java dev but not a noob either.

TG I'd never Hard Bricked. Can't afford a new device at the moment.
[Samsung Epic 4G Touch] lord dredd:
One thing thats coming to my mind time and again.

pardon me if it sounds stupid ( i donno crap about developing stuff )

but over at Fascinate forums a lot of devs were also putting up Full ODIN tars of their custom ROMS.

I understand that using ODIN also means wiping everything but i am sure it cant set off that mmc bug , can it ?

If flashing one click odin tars is safe then why the developers aren't putting up one click odin tars for their custom roms here at epic touch forums

can save a lot of bricks and paperweights

just my 0.002 , again i donno if making ODIN flash tars is easy or possible with epic touch CUSTOM ROMS, but this was repeatedly puzzling me so thought of asking here.

regards
[Samsung Epic 4G Touch] rovar:
I've heard of at least other person bricking after using agat recovery and flashing from sd card.

Qbking77 flashes JB using agat recovery. But he always flashes roms from the internal storage.

Tappin' Typin'
[Samsung Epic 4G Touch] agat63:
Making one click tar files is possible for our devices.

Chris41g has made a very good tutorial "how to" and I've successfully made a factoryfs.img file for one of my roms and rwilco12 has created a one click executable from it.

That factoryfs.img can be packed into a tar and be flashed via ODIN as well.

All that has been tested and confirmed working.

The process is not too long and not too complicated thanks to Crhis41g, his tools and tutorial.

But to make it every dev would need a linux machine (VM, dual boot).

However there is a catch to that.

We can pull img from phone which means the rom should be flashed first. At least one person (dev I would guess) will have to flash the rom via recovery and then make/pull the img from it.

So, long story short - It is possible.
[Samsung Epic 4G Touch] vanberge:
I flashed from sdcard as well... so, that would at least be consistent.

At any rate I'm never flashing anything again unless it's via EL26
[Samsung Epic 4G Touch] Omar04:
I always flash from sd card, I heard internal cause bricks. Also try not to use Calk Format All for ICS or JB and do the wipe manually from EL26 always.
[Samsung Epic 4G Touch] patrick_1:
I've flashed both JB and MIUI/AOKP, both with agats and el26 using calks format all scripts. I ALWAYS flash from internal storage and haven't encountered an issue. Not saying this method is impervious, but like vanberge stated, it's consistent....but then again I could be EXTREMELY lucky.
[Samsung Epic 4G Touch] Mattix724:
What version eMMC did your device have?

I have the newer version, MAG4GA or something like that, I just woke up... and I have used the wipe data factory reset around a hundred times so far without issue. I do not, I repeat do not use Calks format all zip.

I don't think it was Agat's recovery, something went wrong with the way you were flashing the new ROM.

---------- Post added at 09:16 AM ---------- Previous post was at 09:14 AM ----------

Oh yeah... the FI25 recovery is NOT built from source, it is a repack. FI25 kernel source is not available since it is a leak and not official.
[Samsung Epic 4G Touch] robertm2011:
I suspect that the internal/external storage of the rom.zip is a bit like crossing your fingers, it has no real effect on the outcome of the flash...the hard-brick occurs when the EMMC_CAP_ERASE() is called, it then erases a random sector on the chip itself ( "The chip doesn't lock up until a sector is referenced that has corrupted wear leveling data inside the chip." Ken Sumrall - Samsung), and since it is random, there is no way to tell when this will occur. When an attempt to reboot is made, the brick shows up.
[Samsung Epic 4G Touch] vanberge:
I have no idea what eMMC I had.

If I had to guess, it's a combination of the kernel, me flashing from SD, and the updater binary in slick_rick's AOKP build.

Why is everybody saying not to use Calk's formatter? When these blue LED bricks started happening, the answer by many was to actually force this formatter instead of the factory wipe. When did something change?
[Samsung Epic 4G Touch] BluesRulez:
He meant use this app and get the rev of your chip - https://play.google.com/store/apps/...sIm5ldC52aW5hZ3JlLmFuZHJvaWQuZW1tY19jaGVjayJd
[Samsung Epic 4G Touch] sniper:
It's a little hard to use an app while your phone is bricked ;)

Click here for custom mods for your E4GT
[Samsung Epic 4G Touch] vanberge:
Precisely...

Lol.
[Samsung Epic 4G Touch] Mattix724:
The reason I asked about your eMMC version is because I thought when everyone was seeing bricks with early ICS leaks that pretty much everyone checked their firmware revision.

When did you buy your E4GT? It might have been a MAG2GA which is known to have the bug.
[Samsung Epic 4G Touch] vanberge:
I got mine literally on release day in the mail from pre-ordering.

Was like september of '11 I think
[Samsung Epic 4G Touch] vanberge:
Just an update here,

Sprint was really cool about this. Didn't ask many questions, and actually was glad to have my phone to use for repairing some other dudes cracked to **** screen.

My replacement will be here tomorrow; 35 bucks well spent.
[Samsung Epic 4G Touch] Mattix724:
That's cool, it's good to see that Sprint doesn't always suck at customer service.

When I bricked back in May I went into a Sprint store and they told me I had to file a claim with insurance and pay $100 for a replacement.

I ended up sending it into Samsung for repair and they sent me a brand new E4GT.

---------- Post added at 10:30 AM ---------- Previous post was at 10:14 AM ----------

I mixed up my firmware versions earlier, MAG2GA is the newest version. MAG4FA is the version that is known to have the bug.
[Samsung Epic 4G Touch] Dchibro:
Just to add to this discussion, I recently flashed Slick Rick's AOKP ROM from stock EL26, used Calks format all script to wipe, and flashed from external storage. Granted I may have just gotten lucky, but I highly doubt that. I've used this exact method to flash just about every AOSP ROM released for this phone to date and never had one single issue.

My guess is the brick occurred from the combination of Agats kernel and Rick's updater script.
[Samsung Epic 4G Touch] BluesRulez:
lmao. oops.
[Samsung Epic 4G Touch] vanberge:
NP Blues, we still love you. =-D
[Samsung Epic 4G Touch] vanberge:
Yeah neither thing on their own seem to be an issue... I am going with this theory as well.
[Samsung Epic 4G Touch] PhAkEer:
People don't seem to understand erase cap very well...

Please read sfhubs thread about it .

Absolutely nobodies lack of brick is an indication of a safe kernel.

It is the opposite

People that are getting erase cap IS an indication of an unsafe kernel.

400000000 "it didn't happen to me"s

Are irrelevant to the fact that IT IS happening.

I'm only saying to be clear.. If you choose to keep putting yourself at risk (like I do) than you should be realistic and flash less often because the fact of the matter... is you are at risk of getting Ecap...(like I did)...

Just saying ..

(And no, mine was neither recently nor on an Agat kernel.

I've been as lucky as the majority of you)
[Samsung Epic 4G Touch] vanberge:
Dude you totally should have posted!

I'm not mad or anything but you posting your experience could help prevent the same thing happening to another person.

IE, if I had read that you did that, I probably wouldn't' have flashed AOKP with agat's kernel.

But, in the end it seems confirmed that Agat's kernel flashing AOKP is not a safe combo;regardless of the cause.
[Samsung Epic 4G Touch] times_infinity:
Also, if flashing from internal sdcard were the cause of these new bricks, then I would've been through 50 phones already.
[Samsung Epic 4G Touch] vanberge:
I guess I'm not quite sure of your point here. Are you saying that no kernel/recovery is validated as "safe" and everyone's only option is to flash less often?

..edit..

This comes of a little a-holish; not trying to... Honestly just asking for more info. Where/how'd you get your eCAP? Bricked?
[Samsung Epic 4G Touch] PhAkEer:
No. I am simply saying if you choose to use an Agat kernel...

Expect the worst, hope for the best.

When I got Ecap very little was known about it... but people were doing this same exact thing.... it's this... it's that.... I didn't happen to me... its touch recovery... it's aosp...

I've already seen the conclusion of this story...
[Samsung Epic 4G Touch] vanberge:
That is what I thought! (hence the thread title)

This brick just seemed to come out of the blue (LED)
[Samsung Epic 4G Touch] PhAkEer:
H a ha you behreee punneee

Sorry, didn't see your question...

I got mine from factory reset... on a Rogue kernel..

But at this time it was said that of you aren't on touch recovery it wouldn't happen to you.
[Samsung Epic 4G Touch] umrico:
I totally agree with you, but I didn't want the lashback saying I did this wrong or I did that wrong :)

I am on RE-CALKED again and want to update to the latest RE-CALKED 0.2.1....but I totally am scared ****less of messing with it (mind you I have flashed like every day since my Hero and Evo Shift 3 years ago). I always ODIN EL CWM26 and the one time I didnt (which I was on AGATs being lazy to AOKP using the format all script (and NO I AM NOT BLAMING AGAT HERE)), I brick. If anyone cares to comment, is the proper way of backing this up at this point

1)ODIN CWM26

2)backup current ROM

3)flash format script

4)wipe dalvik and cache

5)flash latest Re-calked on top of older version

If not, can someone please correct me for when I have the courage to update it :)

FYI I am currently on

Modem FI03

kernel 3.0.15-1083465 se.infra@sep-68 #3 (comes with the recalked I have IIRC)

Re-Calked.E4GT.0.20.FI03
[Samsung Epic 4G Touch] vanberge:
As the initial person that cooked that rom, and one of the two putting it together still, I confirm that your proposed 1-5 steps are the way to go.

I'm going to do that the very minute my replacement phone comes in tomorrow.

..edit..

But after you run the format all you wont be flashing 0.2.1 on top of the old, it'll be a clean install.

Just to hopefully make you feel better I have never seen anyone on here brick when flashing from an EL26 kernel and going to an ICS stock based ROM.

You up your risk by going AOSP/CM/AOKP/etc (source built ROMs).

Does that help?
[Samsung Epic 4G Touch] umrico:
I am sorry as I just confused the past with the present. upgrading the recalked, id odin cwm26, backup, clear dalvik and cache, then push updated rom...correct?

as much as I like AOKP on my hp touchpad and want jellybean, I dont see myself every doing this on my phone again :) (i.e. AOKP/CM/ETC)
[Samsung Epic 4G Touch] crawrj:
Has anyone tried this recover method yet? http://xdaforums.com/showpost.php?p=26428986&postcount=1
[Samsung Epic 4G Touch] Mattix724:
That is for a /data brick. If you have a blue LED with nothing on the screen, you cannot flash a PIT file using Odin.
[Samsung Epic 4G Touch] vanberge:
I'll try it when I get my jig...

But as of now i can't get my phone to recognize on either windows or linux to even start this.
[Samsung Epic 4G Touch] crawrj:
Yeah I know. I am saying in general as it relates to the emmc bug and not this particular hard bricked case. Sorry for not being clearer.
[Samsung Epic 4G Touch] elliwigy:
i was under the opinion calks format all was based on a gb kernel so didnt contain the same bug that the ics kernels had that caused bricks.. so even on an unsafe kernel calks format all would not have caused a hard brick.. it was only when doing the data/ factory reset through the recoveries.. i could be wrong :)

edit: ,his thread is also funny.. i made the mistake of flashing from a chris41g aosp kernel that was said to be safe and wasnt.. then when i got replacement went on xda and sure enough it was all over that it wasnt safe.. i used calks format all first from sd like always and it didnt brick.. but then i didnt like the rom so used the supposed safe recovery and got blod and didnt use calks format all.. point is, many have used agats kernels and if he says its safe i believe him.. i have used it many times.. think about the early ics leaks before source with all the bricks.. once they removed what was calling for the emmc bug the kernels were deamed safe.. you have to admit the bricks have drastically dropped with the newer safer kernels.. not to mention there are so many variables and different ways someone can brick.. it could have bricked due to anybodiez theories.. what matters is, the devs here do an awesome job and i strongly disbelieve it was due to agats kernel and hope devs co tinue to do awesome work so we can continue our addiction :)
[Samsung Epic 4G Touch] PhAkEer:
According to Sfhub (per Agat) the update binary in the zip + the kernel itself must be free of the trigger. If I understood Agat correctly it seemed he was suggesting that update binary was potentially not fixed for some of the Jb content we are getting and since Agats kernel calls on the zips binary instead of the kernels binary....

The result would be the same as using any other ics kernel...

unsafe.

I don't know if that's accurate... or even if I understood correctly.... bit not knowing is an even bigger reason to urge caution..

I honestly recommend Chris41g kernel for flashing... as (also per Agat) chris's kernel forces the use of its safe binary.

Make sense?
[Samsung Epic 4G Touch] elliwigy:
only time i bricked was on chris41g kernel lol. but later was posted that all his kernels before a certain date were not safe.. it wasnt caught before it was realised.. on one of his kernels now and flashed fro. kuban kernel with calks format all to miui.us jb
[Samsung Epic 4G Touch] Mattix724:
Chris41g, sbrissen, times_infinity, darchstar, PhantomPhreak, etc... all have been working on the kernels for AOSP ICS and JB.

I doubt there is anything left that could potentially cause an eMMC brick. All of the AOSP ROMs that are built from source are using the same device trees, correct me if I'm wrong, but I thought Chris41g made the smdk kernel compatible with both ICS and JB.
[Samsung Epic 4G Touch] oscarthegrouch:
Good guy Agat
[Samsung Epic 4G Touch] timmetal6669:
I was about to say the same thing. Also when i flashed paranoid Android i noticed that my led light was reversed. It would go blue to charge and red to power down. Hope you're not bricked pal. That $hit really does suck! Have you tried to get into DL mode?
[Samsung Epic 4G Touch] PhAkEer:
I wasn't suggesting that what had been said was necessarily true,,,

but I do stand by the affirmation that the safest way to flash is probably chris's kernel, and probably any of the above mentioned are equally safe as they are real devs and those of them that I know genuinely care...

but I can't believe I'm still seeing this type of stuff ...

"doubt...anything left that could..."

If your phone has factory mmc than something is there that can cause it..IT.

I have said this over and over and people don't seem to hear it...

The problem is not only the known trigger, for what is a trigger without a gun (your phone) and a bullet... (your mmc firmware that is not fixed)

The gun and bullet still exist and if you think you absolutely positively need THAT particular trigger you are mistaken.. it only decreases the risk .. granted its a near 100% but it is not quite 100... so yeah.. and stuff..