yashsingh1/xdaforums huggingface dataset:
[Galaxy Note GT-N7000 General] Tungstwenty:
Here's some fresh info from the recently leaked I9100 JB rom (XXLSJ).

Looking at the kernel code the 1st thing I quickly validated is that MMC_CAP_ERASE is still enabled.

Then I remembered this link previously shared by jetmarc:

Looking at the fixups array, the binary matches this: http://lxr.free-electrons.com/source/drivers/mmc/card/block.c?a=arm#L1717 which is pretty much the same approach as the bitbucket link.

The models included in the blk_fixups array are:

SEM02G

SEM04G

SEM08G

SEM16G

SEM32G

MMC08G

MMC16G

MMC32G

M8G2FA

MAG4FA

MBG8FA

MCGAFA

VAL00M

VYL00M

KYL00M

VZL00M
​

In red the Samsung ones, which match the latest Linux sources (not in the 3.0 branch though). Mine is of type VYL00M, reported by GotBrickBug? as one of the confirmed bad ones.

The structures are similar to:

MMC_FIXUP("M8G2FA", 0x15, CID_OEMID_ANY, add_quirk_mmc, 0x100)

Since MMC_FIXUP is used instead of MMC_FIXUP_REV, it uses revisions 0 to 0xFFFFF... instead of narrower intervals like the bitbucket link.

0x15 is CID_MANFID_SAMSUNG

As for the 0x100, it doesn't match the MMC_QUIRK_SEC_ERASE_TRIM_BROKEN flag (1 << 10) from linux 3.6 sources, but it does match the 1<<8 value from the patch. And, more importantly, it does coincide with the value tested in the code within the mmc_blk_issue_rq function:

...
BL mmc_blk_issue_rw_rq

LDR R3, [R8,#0x20] ; req->cmd_flags
0xC0623E3C:
TST R3, #0x8000000 ; REQ_SECURE, 1<<27 (doesn't match 3.6 sources)
BEQ 0xC0623E50 ; secure not requested, jump to use _discard_rq
LDR R3, [R4,#0x164] ; card->quirks
TST R3, #0x100 ; Our magic quirks flag for the faulty chips
BEQ 0xC0623FEC ; Not turned on, jump to use mmc_blk_issue_secdiscard_rq (safe chip)
0xC0623E50:
LDR R4, [R5,#0x24]
LDR R5, [R4,#0xC]
MOV R0, R5
BL mmc_blk_issue_discard_rq
...
0xC0623FEC:
... (code for _sec_discard_rq)

After all this, I then remembered Gokhan had merged the latest Samsung S3 kernel sources onto the S2 Siyah version.

The slight mismatches against 3.6 mainstream linux are now explained since it all fits onto Samsung's S3 kernel sources.

__REQ_SECURE is indeed 27: https://github.com/gokhanmoral/siyahkernel-sgs3/blob/i9300-samsung/include/linux/blk_types.h#L118

0x100 is also the right mask for the faulty bit (labeled MMC_QUIRK_MOVINAND_SECURE): https://github.com/gokhanmoral/siyahkernel-sgs3/blob/i9300-samsung/include/linux/mmc/card.h#L209

Those are the links to Siyah S3 sources.

For S2 (5.0.1):

fixups: https://github.com/gokhanmoral/siyahkernel3/blob/master-3.0.31/drivers/mmc/card/block.c#L2302

and secure discard test: https://github.com/gokhanmoral/siyahkernel3/blob/master-3.0.31/drivers/mmc/card/block.c#L2022

Which if I understand correctly, makes it now safe to put back MMC_CAP_ERASE into mmc->caps.

Also, this stock kernel in S2 XXLSJ should be safe, despite the presence of MMC_CAP_ERASE.

Any comments on this logic?

Later on I'll try to peek at earlier (4.0.4) S2 kernels to see if the same kind of "quirks protection" is there, since so far I had only looked for the MMC_CAP_ERASE bit.
[Galaxy Note GT-N7000 General] cool-face:
So if i flash jb leak XXLSJ on my i9100, and i wipe data from stock recovery i dont get a brick?
[Galaxy Note GT-N7000 General] Tungstwenty:
I *think* it is safe, but probably it's a good idea to flash a custom kernel instead :)
[Galaxy Note GT-N7000 General] shoey63:
+1

Actually the same as wiping on stock ICS. Ie:"non-secure erase*. Difference is that stock JB kernel will no longer accept "secure erase" commands (the deadly one)! Will revert to "non-secure" if format/wipe commands are sent to kernel by recoveries or zips with updater scripts coupled with update-binaries that don't have "wipe via secure discard suppressed "(If I understand correctly).

@Tungstwenty. I would like to thank you for your hex patching method of disabling eMMC_CAP_ERASE. (ie. changing the offending byte from a 1 to a zero without having to recompile from source). Phil3759 has adopted this method and his kernels are running rampant through the XDA community! And guess what? Not a single superbrick wiping or flashing in recovery:thumbup: All because of your idea.:D
[Galaxy Note GT-N7000 General] Phil3759:
Thanks a lot Tungstwenty for this very informative post :good:

Now, what I understand is that cwm6 will always issue a classic format command

What happens in JB once patched, probably is what you suggest: the secure erase mmc_blk_issue_discard_rq(...) errors

TRIM / DISCARD / ERASE and performance: TRIM sounds not used, unless it is called by mmc_blk_issue_discard_rq(...). And in fact, Entropy512 quote suggests that TRIM is used for our affected chips

In anycase, that performance gain will be lost progressively on usage and as /data is filling. Simple deleting of files on ext4 partition, I am not sure informs system to not read block before next write unless enabled with special settings. I am not sure this is enabled by default as it can lead to a greater risk of data loss on hangs / unexpected reboot. On vfat, it doesn't have any impact as far as I know, and exFat I do not have a clue

So, to have a real performance gain, one would have to regularly format /data + do it outside cwm6, since cwm6 issues standard old format command...

At the end, for people on cwm6, no real impact in any case since they will never get the TRIM erase on /data, be it on a patched or non patched kernel, where the theoretical performance gain could be interesting. From phone, we can only format sdcards, where the vfat / exFat file system probably doesn't benefit from this TRIM, performance wise. Formatting /data can be done only in recovery, and CWM6 will never issue any TRIM or secured format command

Am I getting it wrong?
[Galaxy Note GT-N7000 General] Tungstwenty:
Having TRIM working properly would help the /data partition in the situation where its contents are still growing - faster writes and also when the housekeeping (garbage collection / wear leveling) occurs, since there's space that's truly "free" from the eMMC point of view, not only the filesystem's.

As for whether the FS informs the card that certain blocks are no longer in use, the answer is NO unless the "discard" option were to be used in the mount command, which it itsn't (as it also would impact performance negatively due to its synchronous nature).

It is possible however to use the fstrim command whenever you feel like it, to inform the card of the blocks which the FS does not use at that moment - provided MMC_ERASE is not disabled.
[Galaxy Note GT-N7000 General] Phil3759:
Thank you again for all these info :good:
[Galaxy Note GT-N7000 General] shoey63:
So it seems Samsung has assumed that no-one will bother disabling eMMC_CAP_ERASE anymore, on the basis that they have patched JB kernel to cause secure-erase commands to default to "non-secure". ( which THEY believe is 100% safe, in spite of Entrpy512's reservations). Otherwise they would allow suppressed user space "USB formatting" to default to "plain old format" instead of failing. (I think)
[Galaxy Note GT-N7000 General] wickedcairo:
Should I rejoice or not?
[Galaxy Note GT-N7000 General] porcusor:
I have the bad chip and didn't brick my phone after wiping in stock ICS but that doesn't mean I'm safe. You can never be too careful. I suggest you take the safe approaches when flashing. It's not that hard.

Sent from my GT-N7000
[Galaxy Note GT-N7000 General] tankista19:
YES!
[Galaxy Note GT-N7000 General] :
You should be careful as if you have a bad chip regardless.

Sent from my GT-N7000000000 using Tapastalker 2
[Galaxy Note GT-N7000 General] Akiainavas:
I've recently read on SamMobile that the newest leaked 4.1.2 firmware still has the brickbug - so i guess we can say that Samsung is NOT working on EMMC bug after all... That's quite disappointing to say the least.
[Galaxy Note GT-N7000 General] tozneno:
some feedback with the xxlsc say that they can do wipe with stock kernel without probleme.

this information is to be taken lightly... i didn't test it myself... i don't want my precious to be a brick.
[Galaxy Note GT-N7000 General] DeHAWK:
Well, I got the JB sources for the GT-I9305 and the GT-I9100 JB sources was also there to, more or less. The sources HAS been fixed. I have the bad chip but I have compiled my kernels using a mix of the GT-I9305 and GT-I9100 sources. I have tested on my Galaxy S2, all kind of wipes formats etc. and I have still not been able to break it. The program that checks for bad code might alert you, this is because MMC_CAP_ERASE function is still present in the mschi.c

Samsung has made thier own changes to the code. As allready told, they now check for the bad chip. If installed, it will skip the secure erase. And as I said, I have testet this...also with CWM and Chainfires programs. I will therefore consider the JB code for the SGS2 for safe.

Regards.
[Galaxy Note GT-N7000 General] :
Nice scientific method. Keep testing until you end up with a paperweight.

I'll wait for entropy to chime in
[Galaxy Note GT-N7000 General] :
remember there are many with original bug that wiped and said, oh this on is safe. Hardly scientific proof following the I tried and didnt brick logic
[Galaxy Note GT-N7000 General] mailings:
Is it possible to know if firmware is "safe"?

Hello,

First thing first, I hope this is the right place for asking this, If not, please let me know.

I have a P6810, still running Honeycomb that have the problematic emmc chip.

I have seen in sammobile a stock 4.0.4 firmware from November (P6810XXLPP) that I would like to flash into my tablet.

The procedure I would follow would be, flash this stock firmware with ODIN, then boot into the stock Recovery and do a wipe (I don't have CWM). I want to start with a fresh 4.0.4 install.

I have been reading contradictory reports about people that bricked his tablet using stock recovery, so I would like to know if there is any way I could check if this last firmware is "secure"? I mean, I will not brick my tablet doing the wipe.

Thank you.
[Galaxy Note GT-N7000 General] shoey63:
Wiping on stock ICS, you are "unlikely" to brick. If you use CWM.zip 5.x, you are "highly likely" to brick. If you flash a custom kernel with eMMC_CAP_ERASE disabled or a Temp. recovery 6.x (which has "wipe via secure discard suppressed...), you are SAFE:thumbup:
[Galaxy Note GT-N7000 General] mailings:
Thank you for your answer.

One last question, Any temp recovery 6.x for this tablet? The only one I have found is 5.x based
[Galaxy Note GT-N7000 General] shoey63:
Go here http://xdaforums.com/showthread.php?p=28178105

There is a selection of safe "Temp CWM's" (4.x is also safe). It says for I9100 but actually they work on multiple devices. Go into stock recovery and "apply update from external storage". If it flashes on your device, you can wipe. If not, no harm done. Just be careful about flashing ROMs with it. Incorrectly prepared zips can still send bricking command. But for factory reset - yes, safe.:thumbup:
[Galaxy Note GT-N7000 General] kishd:
This recovery is safe for all operations except zips with bad embedded commands.

http://xdaforums.com/showthread.php?t=1927097
[Galaxy Note GT-N7000 General] neier24:
i would be happy to read good news
[Galaxy Note GT-N7000 General] XxPixX:
It seems to be fixed in JB.
[Galaxy Note GT-N7000 General] :
Don't make statements like this. EVERY kernel dev is still disabling emmc secure erase function on their kernels because we don't know if its fixed or not.

Warning to all not to listen to people that say stuff like this - you may brick your device.
[Galaxy Note GT-N7000 General] rraaka:
there is enough evidence in the forum to raise that thought....

taste of the pudding is in the eating...
[Galaxy Note GT-N7000 General] shoey63:
Aah yes, but wipe on stock JB kernel is still the same as wipe on stock ICS kernel. JB just suppresses secure erase,
[Galaxy Note GT-N7000 General] bhatia.mani:
Many times i have done wipe from stock kernel in ICS and luckily never faced this problem

Many times i have done wipe from stock kernel in JB and luckily never faced this problem

Hope for the same in future. My note is up and running.
[Galaxy Note GT-N7000 General] shoey63:
It seems stock wipe isn't as dangerous as first thought. Most of the problem stems from people flashing and wiping with temp CWM zip which uses dangerous secure erase, and then claiming they were on stock kernel after they brick.
[Galaxy Note GT-N7000 General] :
This is pure science. They teach this empirical theory at Cambridge.
[Galaxy Note GT-N7000 General] XxPixX:
Perhaps you should read what I said again? I said it seems to be fixed. And that is the truth, they have made a fix of their own to this bug. How effective it is is another question, time will only tell.
[Galaxy Note GT-N7000 General] garwynn:
Every Samsung JB source seen so far has a code fix in it to disable secure trim/erase by eMMC ID. Disabling using the ICS method is probably overkill but whatever people feel safe with. Haven't checked AOSP yet for fix.
[Galaxy Note GT-N7000 General] :
its not a fix, bug is still there, just not triggered,its not the same as fixing it
[Galaxy Note GT-N7000 General] Phil3759:
No one will now until you keep running a clockworkmod v5.x old version, format/wipe under it and install zip files that do a format of /data while they have an old binary-update, and all this under a stock kernel :rolleyes:

In short, really unprobable unless you want to test it personally like shoey63 did

So, yes, there were many things done by cyanogenmod team to secure our devices (fixing CWM and binary-update). This prevention will make it hard to tell now if Samsung fix is really effective. Personally, seeing all the issues they are making on many devices and adding to JB kernels data corruption issues on i9100 and n7000 they never fixed, I won't trust them and will continue to patch kernels as all reliable custom kernel coders do
[Galaxy Note GT-N7000 General] shoey63:
+1. I hope Sony are a little more trustworthy.
[Galaxy Note GT-N7000 General] rraaka:
theres definitely a change in the scenario for the better since official JB entered

Samsung is very poorly represented in these forums, if they thought it worth it they would come down to clear dogmas

Shoey , you subscribed to this thread still ?

when choices are made

its time to let go
[Galaxy Note GT-N7000 General] shoey63:
Yeah, still lurking. I may have ditched Samsung but my experiences with Note1 are still relevant. Not to mention my insane tests. including :-

Wiping with i9100 temp CWM 6.x.x on stock ICS to prove it is safe.

Using dangerous CWM.zip 5.8.1.5 (wipes/formats) on JB stock kernel to see if Samsung patch is effective.

Signing CM10 ROM so it can be flashed DIRECTLY from stock ICS recovery to verify patched update binary suppresses format commands. (don't think I told anyone about that stunt).

Not to mention introducing Phil3759 to the Note community and helping him develop for a device he doesn't own.

Now. if I could only encourage him to develop for Xperia Z......
[Galaxy Note GT-N7000 General] osm0sis:
What file in the source has the patch to disable secure erase based on chip id? Can someone point me to an example on github? I'd like to double check whether the workaround is included on some GN kernels. Thanks in advance. :)

Edit: Nevermind, hunted one down! /drivers/mmc/core/mmc.c and quirks.c mostly but a few other changes as well.

https://github.com/franciscofranco/Tuna_JB_pre1/commit/3c57a612f12b069bbc863ec0c74a26850d76a9e8
[Galaxy Note GT-N7000 General] chasmodo:
~/cm10.1/kernel/samsung/smdk4210$ grep -ir MMC_CAP_ERASE

include/linux/mmc/host.h:#define MMC_CAP_ERASE	(1 << 10)	/* Allow erase/trim commands */
[COLOR="Blue"]drivers/mmc/host/mshci.c:[/COLOR]	[COLOR="Red"]* removed MMC_CAP_ERASE to avoid killing faulty emmc chips[/COLOR]
drivers/mmc/host/mshci.c:	* mmc->caps |= MMC_CAP_SDIO_IRQ | MMC_CAP_ERASE;
drivers/mmc/host/omap_hsmmc.c:	MMC_CAP_WAIT_WHILE_BUSY | MMC_CAP_ERASE;
drivers/mmc/host/sdhci.c:	mmc->caps |= MMC_CAP_SDIO_IRQ | MMC_CAP_ERASE;
drivers/mmc/core/core.c:	if (!(card->host->caps & MMC_CAP_ERASE) ||
drivers/mmc/core/core.c:	if ((card->host->caps & MMC_CAP_ERASE) &&
arch/arm/mach-exynos/mach-nuri.c:	MMC_CAP_DISABLE | MMC_CAP_ERASE)
[Galaxy Note GT-N7000 General] osm0sis:
Right. Thanks! That's the "heavy handed" way though right?
[Galaxy Note GT-N7000 General] chasmodo:
That's how Cyanogen team did it.
[Galaxy Note GT-N7000 General] nmm1716:
thanks
[Galaxy Note GT-N7000 General] tontonflach:
thanks sir...................................................
[Galaxy Note GT-N7000 General] nukeman239:
I hard-bricked my Note due to this bug and had to replace the Motherboard.
[Galaxy Note GT-N7000 General] :
Very helpful info.
[Galaxy Note GT-N7000 General] SpyderTracks:
You got an s7?!! :p
[Galaxy Note GT-N7000 General] :
Yes running dual boot with Ubuntu and your build of Firefox os :)
[Galaxy Note GT-N7000 General] SpyderTracks:
Rofl :p
[Galaxy Note GT-N7000 General] :
Here I updated by signature for you.
[Galaxy Note GT-N7000 General] se1988:
That's xda love right there
[Galaxy Note GT-N7000 General] Rivan_92:
lol, why is this thread still alive? Samsung still working on a fix?..
[Galaxy Note GT-N7000 General] se1988:
Oh noes, zombie thread!!:eek:
[Galaxy Note GT-N7000 General] straycat:
samsung? working?

Enviado desde mi BlackBerry Runtime for Android Apps usando Tapatalk 2
[Galaxy Note GT-N7000 General] chasmodo:
Well, Crapsung is most certainly not working on fixing this fiasco, but there have been some breakthroughs. Entropy:

https://plus.google.com/101093310520661581786/posts/2eEd95oN1ZP
[Galaxy Note GT-N7000 General] :
wow, I thought it would take expensive equiptment to flash that stuff. that was a nice read. To bad we cant boot from pc without bootloader thought, yet
[Galaxy Note GT-N7000 General] View92612:
You are not alone... I just bricked my HTC Amaze 4G due to the bug. It was lagfix that killed my phone. The messages say successful but actually it's not. It turned out HTC Amaze has KYL00M revision 0x20...

It's not completely bricked (actually it sometimes boots successfully but then dies.) but it is so unstable that it is totally unusable. Even recovery is not stable. Since the phone has very limited value now (probably $120 or so or less) it's not worth replacing the motherboard...
[Galaxy Note GT-N7000 General] damador:
i killed note yesterday too ... hope to get it working in service but that kind of hardware bugs shouldnt happen
[Galaxy Note GT-N7000 General] :
you could try to apply on your htc some of the unbrick tricks used here. But make sure you apply the htc files and not the n7000 when trying to tinker on it.
[Galaxy Note GT-N7000 General] RovG:
I am wondering if the knox warranty void flag is stored somewhere on the emmc, and if this is maybe the real reason why samdung didn't want the world to know how to reformat the emmc and repopulate the bootloaders? Perhaps the flag is written to a specific area that can only be accessed under certain conditions? http://xdaforums.com/showthread.php?p=46004963
[Galaxy Note GT-N7000 General] MR.change:
you're very lucky ,but I wouldn't test this again ,me myself have wiped twice on stock rooted LPY and (barely) got away with it ,as the second time gave me some serious malfunctioning in the emmc ,and boot looping ,but luckily I got it working again by some miracle

it was my birthday though ,and apparently someone up there still loves me :)

of course this was on the first day LPY was released and before all the superbricking news began.I never touched anything that isn't cm9 based ever since.

also ,I have a friend who bricked on a full stock ICS ROM yesterday ,which means no one is safe .

you have been warned.
[Galaxy Note GT-N7000 General] Darkhaven:
I'll rather give it a week or two as I am sure it will be resolved soon. GB still works much better that a N7000 door stopper ;)
[Galaxy Note GT-N7000 General] captainhakan:
I been using Safemod kernel for a few days now with no problems at all. It has the ERASE command disabled which triggers the Emc firmware bug. Just in case u guys are not aware. Since Samsung would never update our emmc chip firmwares, kernel update seems to be the only solution. We don't have to wait for Samsung to do it as we already have it with speedmod kernel.
[Galaxy Note GT-N7000 General] PoisonWolf:
Bingo. Some of you who have wiped already...you don't even know if you have problematic NAND....UNTIL the ROM tries to access that section of the NAND. When that happens, your phone will freeze, and reboot. So even if you have "no issues" right now after 20+ wipes....good luck. :rolleyes:
[Galaxy Note GT-N7000 General] Beretta93:
Safer does not mean secure. Chainfire said that even with erase command disabled, avoiding hard brick is not 100% guaranted.
[Galaxy Note GT-N7000 General] krazman325:
In other words, When you least expect it.......EXPECT IT!
[Galaxy Note GT-N7000 General] M3TALLICA:
This is how I tested it yesterday.

Usually superbrick corrupts system and/or data partition. Few people said that data partition must have some data in it.

I roughly use less than 30 apps and +1.6 GB free space on data partition.

So

I copied a large movie file to data partition, still some space was left, I copied few MP3s there.

Then I performed wipe data/factory reset with CF-Root Gingerbread kernel. Luckily recovery did not crash.

I'm not an expert but I think by this method you can make sure all the blocks are accessed.
[Galaxy Note GT-N7000 General] Lakshay Sethi:
After reading through the whole thread,the one question that comes to mind is that buying note is a risky option then? Since i ws planing to upgrade to the galaxy note,im really worried about it now? should i go ahead and buy the galaxy note?
[Galaxy Note GT-N7000 General] abhijit038:
I appreciate your endeavour.

Although I did wipe many times without failure on stock Non rooted ICS, I did notice a notice one weird thing; It takes a lot longer to erase USB storage from backup and reset menu on ICS than on GB. I wonder if any one has tested though
[Galaxy Note GT-N7000 General] PoisonWolf:
Yeap, that's probably the way to go! =) To ensure that you have no corrupt NAND blocks...you can probably fill up on the data and system partitions as well. IF it's close to the brim and your phone is fine...you're good to go.

Might I ask where and how would you fill up the data and system partitions? I have root explorer and just need directions on where. I'm going to try filling up my partitions as well and seeing what happens.
[Galaxy Note GT-N7000 General] M3TALLICA:
To be frank, this is the BEST device but I feel like samsung betrayed us.

eMMC firmware bug was corrected in G Nexus but they still kept it in other devices.

We all who have warranty ought to brick our phone and make samsung pay for that :mad:

Imagine 200,000 devices getting MoBos for free. All the profit - Money For Nothing
[Galaxy Note GT-N7000 General] cdmackay:
There is no reason at all not to buy the Note, and it's a great phone.

No guarantees of course, but the problem is now well understood, and it's easy to avoid, as long as you follow the simple rules, the main one being: do not flash/wipe your phone until you have read up on this issue and understand when it is, and is not, safe.
[Galaxy Note GT-N7000 General] M3TALLICA:
Use root explorer.

Go to system - that's system partition. See above there's

xxxxMB used, XXXXMB free

Data is data partition.

See above there's xxxxMB used, XXXXMB free
[Galaxy Note GT-N7000 General] Lakshay Sethi:
Well i would follow the instructions for sure. Have people experienced the emmc bug on gingerbread aswell? Or having the phone on GB is completely safe?
[Galaxy Note GT-N7000 General] PoisonWolf:
Sweet mate. I just loaded it up until it was 1mb remaining...and my phone is still fine! The phone didn't reboot or crash or anything. Awesomeness.

I was testing to see if I had corrupt nand partitions in the data sector....as I had run and wiped on Imilka's AOSP back in the day several times. Glad to know that my internal NAND is still ticking! :D
[Galaxy Note GT-N7000 General] adv1sory:
Maybe that 1mb left is the one thats corrupt. :o
[Galaxy Note GT-N7000 General] PoisonWolf:
Ran it all the way down to 0k following your comment. I'm satisfied =D