yashsingh1/xdaforums huggingface dataset:
[Samsung Epic 4G Touch] garwynn:
OK, here's my 2 cents on this:

Agat, please correct me if I'm wrong but I heard that you and sfhub worked together to make the recovery safe regardless of kernel. (Sfhub documented how to do this in the eMMC discussion thread - I'll bump it.) Same with your kernel recompile of FF18.

If this is true then the recovery program is not the problem. In all fairness I may have taken this for granted and may rely on the FF18 "safe" kernel + Agat's repack for future restores.

The other 2 sources where a brick could occur are in update-binary and the kernel. The only one where we have kernel source is FF18/FH13 and again, believe Agat removed the offending code.

-----------------------------

OP, can you confirm one thing?

You listed steps as below:

1) I odin'd to Agat source 0.5.4, rebooted.

2) Flashed Calk's format all script to do the wiping (did not even do factory reset)

3) Flashed aokp 3.1 unofficial

4) flashed gapps-jb-20120726

5) rebooted to blue led

Did you reboot after 3 or 4?

Also, according to our notes the original trigger of the eMMC bug will lock up the phone.

If you didn't get this I'm suspicious that something else is at play here.

(Meaning you should have hung on 3 or 4 and then on reboot got the BLOD)

Does anyone know if AOKP runs any operations before initial boot?

For example, factory restores - the ODIN ones - have a script to clear the cache on first boot.

Just wondering if the offending trigger could have happened here.

I'll bump the other thread for reference purposes.
[Samsung Epic 4G Touch] agat63:
Below are couple of PM's sent to me by Sfhub in early testing days:

"7th June 2012

Here are the initial results of the Test Plan for the BRICKFIX

http://xdaforums.com/show...1#post27124691

Esoteric68 ran through it and more.

6 flashes of CM9a5, 3 flashes of AOKP-37, 3 wipe data/factory restores, 3 nandroid restores, 1 mostly stock FF02 flash. All successful.

This is using Agat/chris41g's FF02 CWM repack.

I think we have a good handle on things now.

It should be relatively safe now that one person has run through it. Could we get a few more volunteers? It would be good to confirm she doesn't have a special Super Phone immune to bricks.

BTW ONLY flash the versions listed in the download section of the test plan.

I'm confident we will soon be rid of this annoying requirement to flash back to GB."

"8th June 2012

Quote:

Originally Posted by agat63

Sorry I didn't respond earlier.

Have a vendor in town and was out with them till 1 am yesterday.

This is great news.

It looks like you were right with all your assumptions and analysis.

Great work.

I'll have to meet the vendor tonight as well but it won't be as long as yesterday. So is there anything you would like me to do tonight?

Any changes needed in recovery?

Any way I can assist to finish this testing process and wrap this up I'm up for it.

Just let me know.

Thanks for being so persistant and getting to bottom of this brick story.

A lot of E4GT user can take a deep breath now."

Just keep in mind when reposting this info that the *core* EMMC firmware lockup/superbrick bug is still there and unless that is fixed folks will ALWAYS be exposed to it to some extent.

What we are doing is eliminating the common paths where someone might hit the bug, hopefully to the point most people don't notice it.

We are NOT 100% fixing the problem (ie so that nobody will ever see it again)

People can flash older kernel/recoveries, fake flash CWM Touch, older ROMs, etc. and still superbrick. "

"8th June 2012

Quote:

Originally Posted by agat63

I understand the nature of the bug and where it's located but what is more important I understand how to avoid it.

Yes, I think that is the big takeaway from this process. Knowing what is causing it, backing up that theory with testing, and then knowing how to avoid it.

I wasn't suggesting you didn't understand the issue. It is just when things get posted, just like the old telephone game, as people pass the info from one person to another, it gets slightly modified and pretty soon agat63 cured cancer "

As you can see the problem is taken care of but as it was mentioned above by PhAkEer the gun is still there and it's loaded with the bullet.

It's waiting for a trigger and with new sources (CM10 and JB) we don't know what is triggering it.

If you follow the link in first qoute from sfhub you can see how risky and extensive my kernel/recovery has been tested before it has been deamed "safe".

At that point we coudn't do more.
[Samsung Epic 4G Touch] BluesRulez:
After reading the post, went to click the link and puff .. 404 Not Found. Is it in the emmc brick thread?
[Samsung Epic 4G Touch] garwynn:
Right. The kernel fix was the ideal one as it should protect on the lower levels.

However, recoveries and update-binary can also have offending code to trigger the bug.

Have you considered adding Entropy's code patch to this, the one that notifies if it tries to trigger the secure erase/trim?

Although no one *should* hit it, it would give an opportunity for people to notice and report if they see it.

Long term I'm on the lookout for the code patch proposed by Samsung to avoid the trigger.

Entropy reported it made its way into GS3 source but hasn't been found anywhere else yet.

I'm hoping that Samsung gets it into either the final ICS or upcoming JB builds.

I haven't checked to see if it made its way into AOSP but if not already it should be soon.

This should go a long way towards making it safe.

Here's the latest I could find on the patch:

https://patchwork.kernel.org/patch/1329761/

Note: Samsung refers people back to our discussion thread, which should give a good indication of how well sfhub, Entropy512 and others documented it. I'm glad he convinced me to move that from PMs to that thread...
[Samsung Epic 4G Touch] vanberge:
I rebooted after 4. I flashed AOKP then flashed the JB gapps THEN rebooted. I had Odin'd to Agats source built with a fresh download of the odin tar. My phone did not freeze, it actually said flashed successful for both things. Then i went through the recovery to the reset menu, reset device, to blue led

Again I am not trying to blame anyone, just noting that I bricked flashing AOKP with Agat's kernel. Then, somebody else came forward that had happened to them as well.
[Samsung Epic 4G Touch] agat63:
Yes. It's that thread.

I don't know why it gives 404 error.
[Samsung Epic 4G Touch] garwynn:
(Removed - Duplicate)
[Samsung Epic 4G Touch] agat63:
I did try Entropy's code but that gives the problem of old zip's not flashing.

With that code a new variable added to the binaries and when trying to flash old zip files (pretty much any flashable zip) it gives an error.

"have 3 arguments but need 4".

Every single zip should of been redone to make it work with new recovery with new code.

And since back than my recovery/kernel combo has proved itself to be pretty "safe" I left the code out.

Total download count of all versions of my source/repack kernels is running far over 10000.

2 recent bricks from over 10000 downloads makes me think that it's not kernel alone it's kernel/build combo.

Because up untill CM10 and JB dropped down there were no single reports of any problems leave alone the bricks.

I guess it's time to go back to drawing board and start from scratch to try find a cure for this recent bricks.

And again it looks like only those 2 builds are vulnerable and susceptible for brick as of right now.

I think the risk can be minimised if a CM10 or JB kernel is flashed first and then from a "Native" kernel/recovery rom is flashed.

I guess untill we find a reall answer to this problem that should be the path to walk.

Interstingly enough I made few attempts to make a JB kernel (no dice there) and I have flashed early JB builds from my kernel/recovery.

Either I'm lucky or I have a speciall phone but I didn't have a single problem flashing JB roms. And I did it couple of dozen times when trying to make the kernel work.

And I always used Calk's format all zip not because I didn't trust my recovery but because it makes in one move everything.

To make a full wipe in recovery we gotta wipe data, wipe dalvik, wipe cache.

Calk's zip does all same in one move. That's the reason I always use his zip instead of wiping in recovery.
[Samsung Epic 4G Touch] PoppinJ:
I cant believe youre having to deal with this after 1100 flashes. Kinda worries me all over again. The ICS bricking is hard for me to keep up with since we have learned so much since we first found out. Half the info out there is outdated.
[Samsung Epic 4G Touch] Omar04:
The Return of the MMC_CAP_ERASE Bug/Brick :banghead: I just hope this get fixed once and for all. :beer::D
[Samsung Epic 4G Touch] PhAkEer:
Ya know, I don't know if it is at all but it could be as simple a switch to get those zips working..

I don't know a terrible amount about update binary / updater scripts...

But I was tired when I slapped something together one and used the wrong updater script...

I got the opposite message as a result.. I had 4 args but expected 3...

I didnt really know what I was doing ... but I just opened up the updater script and remove a set of digits from each recursive command... first try after that it worked ..

What I'm trying to say is....

If adding a couple thousand arguments to master copies of commonly flashed modems/roms/kernels..etc is all it would take to maybe catch EC raw and get a little info on it.... I'd happily do my part and suffer through the boredom....
[Samsung Epic 4G Touch] agat63:
It's now over 1200 for last v0.5.4 only.

Total kernel downloads 10586.

Even if only half been flashed after download it makes more than 5000 users for my kernels.

And if every one used the kernel for only 10 flashes (not that much for 4.5-5 months) we can safely assume that my kernel/recovery combo

has been used to perofrm over 50,000 flashes.

And I can't believe myself that we back on this subject after that many successes.:(
[Samsung Epic 4G Touch] garwynn:
Not a blame game here - if it is happening again we want to try and narrow down the cause to squash whatever bug we found... :highfive:

I'm really thinking we're not looking at the eMMC bug in this case. Everyone that had the problem in the past got locked up and then after pulling the battery got the BLOD.

Since I think you said it's being replaced it's a little after the fact but I suspect this may have been repairable by jig and flash or JTAG if the bootloader corrupted somehow.
[Samsung Epic 4G Touch] PhAkEer:
Also, don't forget to consider ECs natural function. Too many flashes or wipes and then the wrong switch-up on an Epic that has flashed a million Roms could still trigger it through the wear-level couldn't it?
[Samsung Epic 4G Touch] garwynn:
You know, I never really did find out if the eMMC bug trigger was related to the WL process. My understanding of this was that the trigger was the secure erase/trim command. I would think that the WL algorithms would use this but wouldn't it follow the kernel and execute by the same rules?

Entropy512 would know for certain compared to my knowledge - he mentions it in the same thought process so I would think they are related.

Having said that..

The WL bug - inserting 32Kb of zeros - could have also done the trick. We often forget about this one but it certainly hasn't been squashed either. And MMC_CAP_ERASE disabling won't resolve this one. (Matter of fact, we'll probably never see it squashed for our devices.)

I honestly started to think that this may be the cause of some people's issues with flashes, meaning another wipe/flash may provide a different result based on WL behavior. Unproven at this point but certainly plausible.
[Samsung Epic 4G Touch] times_infinity:
Samsung would need to write a kernel patch to dump the firmware, patch it and use the patched firmware like they did for the Galaxy Nexus.
[Samsung Epic 4G Touch] garwynn:
Did you see Entropy's post on the GNote thread about that? Would have

loved

to see that GNex with removable eMMC socket... along with the pile of physically damaged chips that got ruined in the process.

Mr. Sumrall suggested that won't happen because they are unsure of the behavior in older f/w revisions - I asked this same question at one point. And honestly I doubt Samsung will do much to test that out, there's simply too many of them out there and they can more easily replace the statistical few that will actually experience a problem due to WL bug.
[Samsung Epic 4G Touch] times_infinity:
Yeah, in the emmc brick bug thread here in the general section, the part of the op that pointed out when you found the commit for the emmc firmware patch. Sucks that Samsung won't really look into it anymore.
[Samsung Epic 4G Touch] umrico:
Mine locked up two weeks ago while flashing AOKP build 2 Rom if that is the information you are talking about just FYI. Battery pull and door stop.
[Samsung Epic 4G Touch] someguyatx:
Some of us have a lot more than 10 flashes in 4 months. I seem to remember talk of only using the format all script in GB kernel based recovery a long time ago but maybe that's just the way I did it.

I have to wonder if everybody verifies md5 before flashing. Also low batteries or faulty SD cards could cause a brick. I have always flashed roms from external SD as a habit, seems to be safer.
[Samsung Epic 4G Touch] elliwigy:
yea or whos to say the ppl saying they waited 15 mins when they only waited a min and pulled battery in middle of a flash or something lol. either way keep the kernels coming.. if ppl dont want to brick then be a sissy and stay with ur stock roms lol.. dont blame an awesome dev for an amazing kernel that has been used safely 1000x more than there are bricks.. and so amazing how someone makes a brick thread then everyone that posts becomes an expert and knows exactly how or why.. there is no definitive brick scenario, like phakeer was saying.. no matter what, even on a "safe" kernel we still risk bricking regardless..
[Samsung Epic 4G Touch] vanberge:
I have said repeatedly that I'm not blaming anyone dude. I have emphatically stated the opposite, and I included Agat's kernel in the first two versions of the Re-calked ROM that I cooked. I think that alone shows that i have no disrespect towards Agat.

I just wanted to prevent the next person from bricking flashing AOKP with Agat's kernel. I stated exactly how I tried to do it, the process I followed for flashing. I've also not seen anyone in this thread claim to be an expert, in fact its been quite the opposite.

So, what is exactly is your point here?
[Samsung Epic 4G Touch] elliwigy:
point is, people have bricked on every os.. if you flash anything u take a risk.. ive bricked but it wasnt with agat kernel and wasnt aokp.. just saying.. i used ur rom :). just trying to say theres not a real "safe".. it could have happened to anyone with any setup
[Samsung Epic 4G Touch] agat63:
I'm not taking this thread as a blame.

It's more like "share your experience for others to know".

And besides. How can we make our kernels/roms/themes/tweaks better if we not talk about them and not share our experience good and bad.

If first users with the brick wouldn't talk about it and wouldn't share what and how it happened we couldn't create "safe" (to some extent) kernels and recoveries.

Let us keep this thread as friendly as possible and work on finding a solution together.

As I said before we all have on goal in our mind. We wanna make our experience with this amazing phone as good as possible and use this phone to it's full potential without limitations brought to us by carrier.
[Samsung Epic 4G Touch] Omar04:
Wise words by a Kernel-demigod :beer::D
[Samsung Epic 4G Touch] umrico:
You failed to read the OP or thread...
[Samsung Epic 4G Touch] MiguelHogue:
I think this thread put alot of things in to perspective as far as Bricking.. Because wheb someone bricks.. What is one of the first things you see on a forum... "ahh you're a noob,.. Smh we told you to flash from such and such kernel".. When in actuality whenever you flash its a risk no matter what.. Sh*t happens ....just a thought out loud

-TeaM VeNuM Like A Boss
[Samsung Epic 4G Touch] garwynn:
Maybe it's because I do support daily as part of my job but whenever I see a brick report my first thoughts are to troubleshoot it. There could still be other issues that we don't know about simply because we can't get enough info after the fact - honestly this was one of the biggest problems in confirming the eMMC bug.
[Samsung Epic 4G Touch] MiguelHogue:
I wish more individuals had this same idea. It would make life alot easier on here and not distract us to get to the common goal

-TeaM VeNuM Like A Boss
[Samsung Epic 4G Touch] times_infinity:
You must be new here.
[Samsung Epic 4G Touch] jordan2333:
so did i and ive been flashing for ever.
[Samsung Epic 4G Touch] lord dredd:
I firmly believe that the community should provide enough support to the great developers that they can provide safer one click Odin packages of their ROMs.

Odin tars are safer for the community to the fullest as far s flashing new ROMs are concerned.

I am sure that I will try and chip on with whatever I can if some efforts in this directions are made.

Sent from the DAD of all S2s - The Epic Touch.
[Samsung Epic 4G Touch] Mattix724:
The international S2 community already has Odin files for their ROMs... I don't see why the devs here haven't started doing the same. Chris41g already made a tutorial on how to make a factoryfs image.
[Samsung Epic 4G Touch] lord dredd:
if thats the case then

we should asllurge and request our devs to have a see and make ODIN tars as well of their ROMs ,

Kernels and rtadios can be flashed without any wipe

would be a totalwin situation if they are willing to go the xtra mile,and of course if the community is willing to help em out .

anyone listening ,plz reply :)
[Samsung Epic 4G Touch] Mattix724:
I think we should start making tars to flash in Odin.

If the older eMMC firmware is still susceptible to the bug, people will still encounter the brick bug, no matter how safe the kernel is.
[Samsung Epic 4G Touch] agat63:
Making tar files to flash in ODIN is not exactly simple.

And it's time consuming as well.

I'm not sure if the system can be packed into factoryfs.img file in windows.

Most of other things if not all to build a rom can be done in windows.

And thus far I was able to create a factoryfs.img and pack it into a tar file only by pulling the system from phone in linux with a dd comand.

Than the factoryfs.img needs to be "decompile" using ext4utils and then packed again.

There is a very nice how to made by Chris41g and I did all the above with his help.

So that's really an extra few miles for devs.

There is another way to safe flash tho.

May be it's not that clean but if you safe to wipe the phone it doesn't matter.

All format() commands in updater-script should be replaced with delete_recursive() thus not format command and no risk of brick no matter what binary is used in

rom zip.

And that's an easy fix. Only few lines in updater_script should be edited.

That has been suggested long time ago by Sfhub too. Can't point to exact thread and post now but it has been suggested as temporary solution until we find a permanent one.

We can fall back to if again especially when dealing with JB roms and I would say same caution should be applied to CM10 builds.

Those are both API16 or API17 builds.
[Samsung Epic 4G Touch] PhAkEer:
I said similar long ago.. only my suggestion obviously took a a shell route.. another way to go about it would be to remove all format and erase commands from the updater script all together and have a shell that rm -f s /system. Clean.. effective. Safe. (Nobody listened...)

Basically... ROM stripper extreme lol
[Samsung Epic 4G Touch] jtadak:
Wow! I sure wish I had come accross this thread sooner. I also was on the same kernel/recovery and now I have the coolest paperweight with a cool blue light. Also going to Slicks AOKP. g_ding84 sent me over here after I posted a question because I was pretty confused for the brick. The messed up part is right before this I had odened to el29 for the first time, ususally I flashed safe cwm. But I had flashed this combo so I could change my splash. Live and learn. Bottom line, el29 from now on!
[Galaxy S I9000 General] jebise101:
Okay so i'm not new to flashing just made a stupd mistake, i have a Bell i9000M and installed CM9.1 and everything went fine and then installed the S3 addon pack that caused a bootloop so went into recovery and flashed back my nandroid here is where i made the mistake and restored back to GB and caused all sorts of problems but long story short I am now 100% stock running GB 2.3.3 and for the life of me cannot get CWM recovery on the phone.

Everytime i install a kernal it bootloops and looks like I can't even get into stock recovery now. I used odin and flashed PDA,CSC,PHONE and tried using 512 pit file.

The phone works just can't get recovery to work or even install a custom kernal like hardcore speedmod.

Tried follow the CM wiki and no luck, that just causes a bootloop on the startup screen.

Firmware:

GT_I9000M_UGKG3_UGKG3_BMCKG3_Sbl
[Galaxy S I9000 General] xsenman:
you need root, use UGKG3 rooting kernel from My Android Collections
[Galaxy S I9000 General] jebise101:
Thanks, I was able to get back to CM9 and finially installed the correct NANDROID using this, which is for my device
[Nexus 7 Q&A, Help & Troubleshooting] encryptioncsta:
Hey XDA

I have been searching for the best Emulators to acompany my new Nexus 7

i already have FPSE installed and running tho only problem i have with such games as Final Fantasy 7,8,9 and Mortal Kombat is theres no menu music/sound also no cutscene sound for FF games and iv tryed to turn on spusync like a 100 times and it still doesnt get sound to work during the games cutscenes...:( if anyone can recommend any help on this i would greatly be greatful for the help :)

anyways iknow FPSE is the best and most support PSX Emulator, but whats the best Sega Genesis emulator and the best Super nintendo emulator? also gameboy and n64?

iknow theres so many cheap bad ones floating around the play store and even worse out there not on the play store, and i havent even been able to find any advice using google search to find the prefered emulators,

hope to hear back from you guys soon and look forward to your replys

thanks in advance
[Nexus 7 Q&A, Help & Troubleshooting] krackerjac:
Try snes9x es is free google it...I think its by far the best and if you like the dev's work (I forgot his name) he has an nes and a gameboy advanced emulator on the play store too
[Galaxy Y GT-S5360 and Duos 6102 Q&A, Help & Troubl] deathviper:
guys last night my device galaxy y s5360 slipped into bucket....

unfortunately, water trapped into screen..... my phone is still off......

:(:crying::(:crying:

attached a pic

need your attention......
[Galaxy Y GT-S5360 and Duos 6102 Q&A, Help & Troubl] -CALIBAN666-:
o no bro.a good tip,dont use bulb or something its make corrosive your mainboard.the best is to put it in a jar full of rice.
[Galaxy Y GT-S5360 and Duos 6102 Q&A, Help & Troubl] deathviper:
thanks,,,,,,,buddy i suppose it work!!!!doin it
[Galaxy Y GT-S5360 and Duos 6102 Q&A, Help & Troubl] Droidlover123:
Bro also place rice jar in sunlight so that water will eveporate and rice would absorb it...

Also remove battery and other accessories.and if possible open the body of phone by removing the screws...
[Galaxy Y GT-S5360 and Duos 6102 Q&A, Help & Troubl] "theviper":
Placing it in a bag of rice wont help much as far as I know just let it dry and after that open the phone and see if there is any corrosion on the board if yes remove that first by a soft brush to remove the corrosion you can also try to dip the main board in alcoholic solution just google it
[Galaxy Y GT-S5360 and Duos 6102 Q&A, Help & Troubl] humaid.locastic:
A few days ago i had the same problem what i did was removed battery and everything and kept it on the top of fridge.....try it