yashsingh1/xdaforums huggingface dataset:
[Samsung Epic 4G Touch] sfhub:
So I propose we pursue 2 tracks:

1) continue to analyze and discuss code change

2) in parallel have someone test out the unlocked stock recovery repacked with FE07

If #2 cannot get brick despite trying then that will give us more confidence to expand testing. If #2 bricks, then that is a direct proof that either this fix doesn't fix the /data EMMC corruption issue or if it is meant to, the scope was not made broad enough.

Azrael.arach - I can try to help but not till weekend when my other phone gets here.

pbassjunk - I'll take one for the team if needed. I've been eyeballing the 720p Evo.

azyouthinkeyeiz - I can risk a brick to save future ones. I can help test.

robertm2011 - If need be, will test.

and of course bigpeng from the FE07 OneClick thread.

Let's put together a list of things that should be tested. For example

1) flash FE07 unlocked , then format_all, then flash calk 1.5

2) flash FE07 unlocked, then format_all, then AOKP

...

(removed ROM manager for now)
[Samsung Epic 4G Touch] azyouthinkeyeiz:
I am dl'ing 1.5 and performing (1) right now. Will report back asap.

Step 1

Calk's 1.5 and format all flashed just fine from the FE07 repack. Flash seemed to take about a minute to start, but once going worked perfectly.

/*Just flashed FE07 From Rogue Kernel, Booted back into FE07 Unlocked, flashed format all, and reflashed Calk's 1.5, and then flashed FD26 Modem. All flashed perfect.

Step 2

Flashed FE07 unlocked from Rogue> Flashed format all over Calk's 1.5> flashed AOKP 35 Tablet>flashed Format_all over AOKP> re-flashed AOKP. All flashed perfect.

Flashed Format_all over AOKP> Flashed Calk's 1.5> Flashed Format_all> Booted fine> Flashed FE07 Unlocked> Flashed AOKP> Flashed GAPPS20120429(Will not stick)> All Flashed perfect

/*I have tried 6 or 7 different Gapps, each time flashing AOKP from FE07 Unlocked> booting> realizing Gapps did not stick through flash> Odin EL26CWM> Flash FE07 Unlocked> Format_all> Re-flash AOKP> Re-flash Gapps> Boot */

I'm calling it a night, I'll keep messing with Gapps in the morning if someone hasn't already figured it out.
[Samsung Epic 4G Touch] sfhub:
Just unlocked is fine. That will isolate just the stock kernel with the fewest changes possible.
[Samsung Epic 4G Touch] Esoteric68:
Can I do this on the custom ROM I'm currently on (flashing the unlocked kernel, currently have the plus installed) or should I ODIN the one-click to get me started from a clean slate?
[Samsung Epic 4G Touch] azyouthinkeyeiz:
I'd hold off, if you are just wanting the newest recovery. IF you are wanting to help test, and understand there is a possibility that you will brick, you can try it from the current rom, as I ODIN'ed to EL29 yesterday, and it'd be good to isolate your flash pattern, just make sure to denote all of your steps here in this thread.
[Samsung Epic 4G Touch] Esoteric68:
I'd really like to help test. I recognize and accept the risks and am happy to do my part if it further's development on our device.

Okay, gotcha.

AOKP is saying 5 hours to download. Ouch. Can I go with AOSP instead? Nevermind, I have other ICS ROMs already downloaded so I'll try some of them and work my way back around to AOKP tomorrow. lol
[Samsung Epic 4G Touch] Esoteric68:
One quick question. I flashed clockworkmod touch recovery through ROM manager but uh, now I don't know how to actually access the stupid thing.

FYI, prior to this I've gone through 5 ROM installs using unlocked recovery with no problems. As soon as I've completed the clockworkmod touch recovery step I'll post all my steps/results.
[Samsung Epic 4G Touch] azyouthinkeyeiz:
I think CWM touch should be a very last step. That's almost a sure brick.I'd like to see a couple more get through flawlessly before we say we aren't in the fwrev range. Let's see if we can isolate some more before we go there. We also might try building a cwm touch with the AOSP kernel T.C.P just let out of the bag, before using that one.
[Samsung Epic 4G Touch] sfhub:
So to recap, if the workaround from Samsung is:

1) replacing problematic EMMC firmware, then everything is safe after the firmware is replaced, even older kernels, with no further action needed

2) patching the kernel MMC driver code to avoid mmc_erase(), then anything packaged with the newer kernel is safe, including our existing Recovery and update-binary, no recompilation is necessary, just repackaging with the new kernel

3) patching libext4_utils.a, then none of our Recovery or update-binary *which were compiled against ICS sources* would be safe until they get recompiled against a patched libext4_utils.a. Alternatively we could compile against a GB-based libext4_utils.a and be safe (ie use the GB versions of Recovery and update-binary)

It is important to note that you need *BOTH* Recovery *AND* update-binary to be compiled against a libextr4_utils.a with the ioctl() calls (effectively) removed to be totally "safe"

This can be accomplished either by patching libext4_utils.a when you compile your ICS-based Recovery/update-binary or by using the preexisting GB-based versions.

If the latter, basically take the GB-based Recovery and repack with an ICS kernel, and when you create your update.zip for your ROM, make sure you use the GB-based update-binary from one of the GB OTA releases.

Hopefully my analysis is correct, and we can already be totally safe from this brick issue just by using the GB-based versions of Recovery and update-binary. No need to wait for Samsung.

Also, in case it wasn't clear, there are only 3 problematic areas:

1) wipe date/factory reset in Recovery (this calls make_ext4fs())

2) privacy/factory reset from within Android sets some recovery commands in /cache, then has Recovery perform the actual reset, so by proxy, it calls make_ext4fs().

3) format() function in your edify script (update-binary will read your edify script and when it encounters format(), will call make_ext4fs())

Everything else is already safe.
[Samsung Epic 4G Touch] garwynn:
Q: Couldn't we just check the update-binary on one of the OTA builds and see if the build size differs from some of the previous versions? (I believe kc_exactly can still get ahold of those.) I'd say creation/modification date but that may not be reliable either - the binary size though should be if it was consistently the same on previous builds.

Short of getting the source for that or building it again on our own I'm scratching my head on how we can figure out if it's in there or not. I know it's not like my dev environment at work where I can embed the source in the binary for debugging purposes. Testing may help but only if we can control everything else and make this the only variable.
[Samsung Epic 4G Touch] sfhub:
These are the official GB OTAs and FE22 ICS:

update-binary-ek02 [MD5: 3003ea20117aea6864d158dbc7916f3a Size: 190,496]

update-binary-el29 [MD5: 3003ea20117aea6864d158dbc7916f3a Size: 190,496]

update-binary-fe10 [MD5: 439f2f998616c0ddf7b2f0149d6f7669 Size: 241,036]

update-binary-fe22 [MD5: 439f2f998616c0ddf7b2f0149d6f7669 Size: 241,036]

The one Calk packages with Format_All() is not one of those, but it is dated 12/15/2011 so I assume it is GB-based.

update-binary-calk [MD5: 775e18f61d1442df474cde7844d0ef8b Size: 224,244]

If the update-binary changes with the official ICS OTA release, then it is probably ok to assume it has the change Samsung put in for the EMMC lockup issue as update-binary hasn't been changing often with the various ICS leaked releases.

However, if folks want to be extra safe, just use the update-binary from EL29 when creating their ICS custom ROM update.zip. We know for sure that update-binary is "safe" as it came from a GB-environment. I believe most custom ROM update.zip are probably using it already, which is could be why see fewer superbricks on stock-based ROMs. It is possible AOSP, AOKP, etc. are/were using their own update-binary, I haven't checked. *IF* they were using their own AND it was compiled/linked against ICS libext4_utils.a, then the format() function in their edify scripts is suspect. This *might* have explained the early bricking. I think after the bricks started happening they changed to install procedure to perform the wipes from GB-based recovery, which I assume means their edify install script does not perform format(), which in turn means even if they use an "unsafe" update-binary, it doesn't matter because they don't use the unsafe format() function. All the other edify functions in update-binary are safe regardless of which version or how they were compiled. Only format() is potentially dangerous.
[Samsung Epic 4G Touch] garwynn:
I'll look to see if I find an earlier ICS OTA .zip and pull the update-binary out of it. My guess is that we'll find an identical MD5 in FE16, for example. The big question is what we'll see in FE25/26 - if we see a different MD5 checksum there it should give support to the idea that they changed it again. (Won't tell us *what* they changed but I'm asking thirdcoastraised to see if they can find out for us...)

*Edit* Found kc_exactly's link for FE16:

https://www.dropbox.com/s/tk27wbcstf1ye3l/Union_made_el29_to_fe16_ota.zip

Unfortunately it's in my "no" zone where I'm at now - will look later tonight if I can.
[Samsung Epic 4G Touch] sfhub:
Don't worry about it, I already updated to include the FE10 update-binary and it is the same.

Also keep in mind an "unsafe" update-binary isn't dangerous by itself. It is only potentially dangerous when combined with an edify install script that does a format()

Many update.zips do not perform format() in their edify install scripts, expecting you to perform these operations outside (prior) to running the ROM install.

Also keep in mind update-binary and Recovery are independent of each other. If you use a "safe" update-binary (let's say the one from EL29) to create your update.zip, then run that update.zip inside of an "unsafe" (let's say ICS) Recovery, your update.zip is "safe", even if it performs format(). It would only become "unsafe", if you went to the Recovery menu and performed Wipe Data/Factory Reset (assuming the Recovery is "unsafe")

Similarly if you have a "safe" (let's say the upcoming patched official OTA release) Recovery, but you flash a ROM which uses an "unsafe" update-binary, if the edify install script for that update.zip performs a format(), that is an "unsafe" operation even though your Recovery is otherwise "safe"

If they patch the EMMC firmware itself, then everything is "safe" regardless. If they patch the kernel MMC driver, then everything packed with that patched kernel is safe, even without recompiling/relinking.

What we are discussing above is if we don't want to wait for Samsung and want to be "safe" right now or if the fix/workaround Samsung puts in ends up being in libext4_utils.a
[Samsung Epic 4G Touch] garwynn:
Edit: disregard for now... Still reading your edit. :)
[Samsung Epic 4G Touch] jgaviota:
Superb analysis sfhub,

it explains every scenario I have seen in the Note section.

Also it would explain how the official ICSs roms would according to Samsung be safe, yet there would be bricks with the custom roms (I'm thinking patch in the libext4_utils.a, and Chainfire packaging a recovery compiled against an unpached libext4_utils.a)

I'm also assuming the leaks had unsafe everything.

Now, for all devices

1) Kernel developers should disable MMC_CAP_ERASE to make sure your kernel is safe regardless.

2) If you compile or package a recovery make sure you compile it against a patched libext4_utils.a

3) If you make a custom rom, packed in a CWM zip file make sure you include a GB update-binary

These rules should be stickied for the developers in all the affected forums (fora?)

If every custom rom follows these rules the situation would be essentialy over

Also there are safe test that we can perform. Someone could compile a safe kernel that would log all mmc_erase commands and pack it with stock recovery. Do a wipe and see if mmc_erase is called, that would clear once and for all if stock rom is suceptible to the bug.

Another question: is the source code for Samsung's libext4_utils.a available?
[Samsung Epic 4G Touch] Entropy512:
That's my plan for responding to Samsung's "can't reproduce" answer to Note users.

We've confirmed that the N7000 has the defective eMMC firmware, and that its kernel enables MMC_CAP_ERASE (whereas the I9100 Update4 sources don't - this is why I9100 hasn't experienced this issue with the exception of the Siyah 3.1rc6 incident) - Now with an instrumented kernel it can be determined officially whether Samsung's Note official releases have the "triple play" that leads to danger.

Oh - by the way, there is now evidence that some (but not all) Kindle Fires have a M8G2FA flash chip which is susceptible to the same bug. There was a recent indicent where CWM 5.5.x was deployed on the Fire, and people experienced these exact same symptoms.
[Samsung Epic 4G Touch] ykkfive:
hi sfhub

i agreed with you and i finally found a guy who shares similar thoughts with me. i have read the source codes for /fs/ext4 and some other relevant files last week. in my opinion, it is not a good way to just disable the MMC_CAP_ERASE only, but to, as u quoted before, to return a false when the wipe or wipe_rq function is called and let other old functions to handle the requests. since the wipe_rq and related functions are black boxes actually, we don need to care about the MMC_CAP_ERASE or other variables in other programs since we have stopped every code to call the wipe and format request

hope this helps
[Samsung Epic 4G Touch] musashiro:
just an update guys
[Samsung Epic 4G Touch] jgaviota:
Kernel developers should disable MMC_CAP_ERASE because then, no matter how the wipe is triggered it's safe. It also covers the case of deleting a very large file, which is a case that Entropy suspects could cause the emmc fault.

They cannot reproduce the fault most probably because they fixed it in their recovery. There is a recovery log that they should post, I bet it says wipe blocked. See a post by hardcore and one by me in the Note's speedmod thread.
[Samsung Epic 4G Touch] jgaviota:
I think Samsung opted to workaround the problem in the recovery instead of disabling MMC_CAP_ERASE because of a possible loss of performance over time if the Trim command isn't issued, what do you think?

Also if we knew for certain what are ALL the triggers for the emmc bug in the 0x19 firmware we could determine the best place for the fix.
[Samsung Epic 4G Touch] fslateef:
Great analysis and completely agree with you.

But was wondering that even if Samsung patches EMMC firmware itself then still they can't provide it as a flashable solution for everyone, right ? As according to my understanding flashing of eMMC low-level firmware won't be possible from high-levels and needs some sort of JTAG/programmer to program eMMC. So if it is correct then they will do other workarounds (likely what you mentioned) in upper layers. CMIIW.
[Samsung Epic 4G Touch] Entropy512:
So far, there's only one case where there is evidence that Samsung worked around the eMMC defect - and they did it in the kernel by disabling MMC_CAP_ERASE. (I9100 update4 sources).

With a kernel fix, you guarantee to have fixed EVERY possible method for triggering the bug on the target device.

If you try to fix it in recovery - there are, as sfhub pointed out, 2-4 different places you have to fix it, and in many cases (update-binaries), there could be "dangerous" items still floating out there. This also means that you have to fork your recovery source code from AOSP and maintain THAT as a separate branch and hope everyone else for your device does too (otherwise, the third-party developer community can still give you a PR fiasco). Fix it in the kernel and you fix it for all situations.

As to performance impacts - all of the evidence we have says that TRIM/ERASE simply aren't issued in any "safe" firmware configuration.
[Samsung Epic 4G Touch] jgaviota:
Are TRIM/ERASE commands issued on normal gingerbread file operations?

And is there evidence that anything else but a wipe or format with mmc_erase causes the bug?
[Samsung Epic 4G Touch] ykkfive:
MMC_CAP_ERASE is just a boolean that trigger the bug. yes, it can be disabled but u cant say others wont turn it on later in other functions. so once we return a false in the wipe function, we don need to care about the MMC_CAP_ERASE

eg, your computer wont turn on no matter the swith (MMC_CAP_ERASE) is on or off in the front panel, since the power cord is unplugged (deny all wipe requests). that is to say, there is no way to power it up unless it is plugged (accept wipe request)

i havent check if they exist or working properly in gb, but i can say there were lots of bugs regarding the trim in ext4 before. i dono if these bugs were all fixed already
[Samsung Epic 4G Touch] Entropy512:
This makes no sense. MMC_CAP_ERASE is the lowest-level situation where an erase function can be blocked.

Your claimed logic is EXACTLY why disabling MMC_CAP_ERASE is the best option - It prevents ERASE commands from ever reaching the flash chip, no matter what the upper level software tries to do. Dicking around with wipe functions in recovery means that users are still at risk if someone accidentally slips up and puts in an ICS update-binary in one of their CWM zips.

There is no "other functions" "later" - MMC_CAP_ERASE is a capability flag at the lowest level of the software stack, in the MMC driver itself. There is no lower-level way to disable ERASE commands from being sent to the chip (except ugly hacks like commenting out all of the mmc_erase() function...)

Disabling MMC_CAP_ERASE is exactly how one sanely achieves forcing mmc_erase() to always return -ENOTSUPP - There is NO way to override or work around that change without making another change deep down in the kernel driver (either re-adding the flag or totally rewriting the mmc_erase() function, ignoring all of the checks that are already there.)
[Samsung Epic 4G Touch] ykkfive:
that's exactly what i meant, do it on the kernel driver
[Samsung Epic 4G Touch] jgaviota:
I agree with you that MMC_CAP_ERASE is the safest and thoroughest place to fix this.

Now let's look at all of this through Samsung's perspective:

They have a emmc firmware problem.

They probably sent errata to all the affected partners.

They fixed it on stock firmwares (This has to be confirmed with the help of a kernel that logs if mmc_erase is called from stock recovery, but from all I have read it seems that not one brick is from unmodified stock roms, even on the Note)

No one that stays in stock will brick his Note

If someone bricks his phone with leaked or custom roms tough luck.

Everyone (Samsung) is happy.

What is the problem with this scenario?

Easy Samsung forgot to consider us important partners.

If they had made the firmware errata and their fix public, it would have saved us a lot of headaches.

A suggestion for Samsung, be more welcoming of developers and forthcoming with us.

One thing many would love to see for example is a package containing all the needed drivers and documentation to port the next version of Android when they themselves are working with it.
[Samsung Epic 4G Touch] sfhub:
You can put the workaround in either place, each has positives and negatives. I suggest you take both approaches.

If you do the workaround int he kernel mmc driver, all Recovery and update-binary executables (even if not recompiled/relinked) will no longer trigger the issue *IF* they are repacked with the new kernel.

However in the case that Samusng didn't place their workaround in the kernel mmc driver, you are then forcing everyone to use a "recompiled" kernel to get the "safe" feature, rather than having the flexibility to use "repacked" stock kernels. Some people prefer "repacked" stock kernels.

If you do the workaround in libext4_utils.a, there are 2 ways you can go about it:

1) just use the pre-existing GB binaries for Recovery and update-binary. This doesn't even need a recompile. This doesn't even need ICS source.

2) put the workaround in the ICS libext4_utils.a. You don't need to make changes in 2-4 places. You just need to make the one change in wipe.c mentioned earlier, then *relink* your existing Recovery and update-binary against the patched libext4_utils.a. There is no need to "fork" Recovery or update-binary, since you just make the change once at the lowest "user-space" level code.

The advantage of the workaround in Recovery and update-binary, is it will work with any kernel (even the existing "unsafe" ones) and you can do it right now, even without needing to access any ICS source code.

You would need to have the people who put together kernel images start using the GB-based Recovery binary and also instruct the people putting together ROM packages to use the GB-based update-binary, the latter is something most ROM developers already do on E4GT, except possibly the AOSP/AOKP folks.

If you opt for the source code change, you are going to fork a file somewhere, either a build make file or some include file in the case of the mmc driver workaround, or a single function in wipe.c. It is no more or less difficult to maintain a fork of the build make file as it is to maintain a fork of wipe.c.

We already know having the workaround in Recovery and update-binary coupled with an "unsafe" kernels that do mmc_erase() works fine as most of us have been running this way since the beginning. We never heard of these EMMC lockup/superbricks in GB and the "workaround" in GB was essentially placed in Recovery and update-binary, because the kernel had MMC_CAP_ERASE enabled.

So why don't you just do both methods? That addresses the most situations and gives the most flexibility in producing "safe" environments.
[Samsung Epic 4G Touch] ykkfive:
you are right

and u have pointed out the pros and cons for the 2 approaches clearly

i am pleased with respects (hope i say this correctly)
[Samsung Epic 4G Touch] niko26:
eMMC Bug with ICS + Samsung Note

Hey guys, sorry to interrupt you... I have been reading a lot of threads to gather some information about the issue I am having, and it seems like it has to do with the eMMC issue+ICS+Wipe. My Samsung Galaxy Note has not been bricked yet, but it's acting weird and I suspect some issues with some of the blocks.

This is what I did:

1. Upgrade from GB to ICS using Mobile Odin. I have backed up everything using CWM, Titanium Backup and a tool named BackupEverything (to recover text messages/sms, bookmarks, call log). Before upgrading I wiped everything from within CWM.

2. Downgrade to GB again, wiping the device from within CWM and using CWMs backup. I had to do this because this stupid tool BackupEverything did not correctly backup my bookmarks, texts and calllog.

3. Upgrade back to ICS, wiping the device from Within CWM and using CWMs backup.

Everything has been working so far. However, just recently I wanted to backup my device again, but the backup process always aborts at some point (nearly towards the end of the /system partition), and the device boots.

My questions:

1. Could it be that the eMMC bug affected me?

2. I read that this bug ONLY happens if you wipe your device in ICS directly, or in CWM, but ONLY if CWM 5.5+ later has been used because it really tries to null the blocks, whereas older version just mark the partitions clean (kind of soft format)

3. If the eMMC bug affects me...

a. can I easily fix this afterwards? Is there any hope for it?

b. if not... then I'd like Samsung to repair this device, because the fuc*ed up. But I have to clean the device completely (incl. removing CWM+root), and brick it in such a way that they have to replace the device.

Basically I am trying to gather some more definite statements about the cause. For a novice like me it is incredibly frustrating reading so many posts (I literally spent hours!) and contradicting statements.

Thanks for your time, and of course any help is appreciated!