Replicant

h1. EMMCFirmwareBugs

{{toc}}

h2. Data corruption

Several devices have fixes or workarounds in vendor kernels for data corruptions in the eMMC. This can lead to non-working devices as it could potentially corrupt the bootloaders for instance.

The bug #2104 has more details for the Galaxy SIII.

h3. Affected devices

h4. VTU00M

*Affected devices*: Some Galaxy SIII (GT-I9300)

*Vendor kernel patch*: "mmc: Soft-patch MoviNAND VTU00M (16GB) eMMC failure":https://git.replicant.us/replicant/kernel_samsung_smdk4412/commit/?id=da8461692362317a8ffce4d4646953985fcf4e1d

*Upstream status*: not upstream

*Replicant >=9 status*: not yet ported

h5. How to check

As this patch shows:

<pre>

+	if (!strncmp(host->card->cid.prod_name, "VTU00M", 6) &&

+		(host->card->cid.prod_rev == 0xf1) &&

+		(mmc_start_movi_smart(host->card) == 0x2))

+		host->card->movi_ops = 0x2;

</pre>

* The name of the eMMC is VTU00M

* Only certain revisions are affected (revision 0xf1)

With Replicant > 6 we can find the eMMC name like that:

<pre>

$ adb root

$ adb shell

i9300:/ # cat /sys/bus/mmc/devices/mmc2:0001/name

VTU00M

</pre>

As for the prod_rev, we have "this code":https://git.replicant.us/replicant/kernel_samsung_smdk4412/tree/drivers/mmc/core/mmc.c?id=da8461692362317a8ffce4d4646953985fcf4e1d#n101 in the Replicant 6 kernel:

<pre>

case 4: /* MMC v4 */

		[...]

		card->cid.prod_rev	= UNSTUFF_BITS(resp, 48, 8);

		[...]

		break;

</pre>

So it's a MMC v4 and uses @UNSTUFF_BITS(resp, 48, 8);@

In upstream Linux we have that instead:

<pre>

	case 4: /* MMC v4 */

		[...]

		card->cid.prv		= UNSTUFF_BITS(resp, 48, 8);

		[...]

</pre>

So we should be able to get the revision in this way:

<pre>

$ adb root

$ adb shell

i9300:/ # cat /sys/bus/mmc/devices/mmc2:0001/prv

0xf7

</pre>

Here I've the 0xf7 revision and not the problematic 0xf1 revision, so I should probably be ok.

Here this has been tested with a GT-I9300 with a work in progress Replicant 10 image that uses a kernel closely based on upstream Linux.

h5. Vendor kernel workaround analysis

The "mmc: Soft-patch MoviNAND VTU00M (16GB) eMMC failure":https://git.replicant.us/replicant/kernel_samsung_smdk4412/commit/?id=da8461692362317a8ffce4d4646953985fcf4e1d patch patches the eMMC firmware at runtime (it patches the firmware in RAM).

The eMMC firmware patch makes the eMMC hang when a corruption is about to happen.

h5. See also

* The "eMMC hacking, or: how I fixed long-dead Galaxy S3 phones":https://media.ccc.de/v/34c3-8784-emmc_hacking_or_how_i_fixed_long-dead_galaxy_s3_phones presentation that has a lot more background on the issue for the Galaxy SIII (GT-I9300).

* The "i9300_emmc_toolbox":https://github.com/oranav/i9300_emmc_toolbox source code related to this talk. Note that while most of it is free software it also contains nonfree code in the sdcard directory.

h4. Other devices

h5. See also

* The "EMMC Bugs page":https://web.archive.org/web/20161224221928/https://wiki.cyanogenmod.org/w/EMMC_Bugs on the archive of the CyanogenMod wiki.

* The "XDA developpers eMMC sudden death research thread":https://forum.xda-developers.com/showthread.php?p=38112844

h5. TODO

* Document this also for other devices, like the Galaxy SII.

* There was a wiki page in LineageOS or CyanogenMod that referenced eMMC firmware bugs. find it and reference it