yashsingh1/xdaforums huggingface dataset:
[Galaxy Note II, Galaxy S III Developer Discussion ] E:V:A:
In case someone else like to join in on this, here are some eMMC basics for

reference. (That I cut and pasted from various sources.)

Also, I found it useful to understand, that from the low-level point of view, an eMMC and SSD are

essentially the same. An SSD is basically a huge eMMC, but where the NAND chips are used in

parallel with an added DRAM cache buffer and a SATA interface operating at 5V. So the

wear-leveling etc. works in the same way, eventhough the microcontroller in an SSD is much

more advanced. (I.e. For a Samsung SSD 840 Pro, there is an 3-core Cortex R-4 running @

300MHz!) Thus, any problem you encounter in the FTL of an eMMC, you will likeely also have

in an SSD if using similar NANDs, and vice versa.

The most important and relevant documents are those of the JEDEC standard.

However, our device conforms to (JESD84) v4.41 and not v4.51, AFAIK.

"JEDEC: Embedded MultiMediaCard(eMMC) Product Standard..." (JESD84-A441)

"JEDEC: Embedded MultiMediaCard(eMMC) Electrical Standard" (JESD84-B451)

"eMMC v4.41 and v4.5" (JDEC presentation by Victor Tsai)

2013-02-09: ORIGINAL POST MOVED!

As was pointed out in the subsequent post, this is somewhat OT,

so I decided that a better home for it would be HERE.
[Galaxy Note II, Galaxy S III Developer Discussion ] DualJoe:
Correct me if i'm wrong... the firmware NAND you're talking about is the same like the eMMC (not a separate one), right?

If so, can you provide some signature bytes (maybe the first 32bytes) and the firmware length so we can dump the whole NAND with a Riffbox (AdamOutler?) and extract the firmware ourself?
[Galaxy Note II, Galaxy S III Developer Discussion ] AndreiLux:
EVA, what exactly are you trying to achieve? Seems more off-topic than actual on-topic discussion to me.

And SSDs have absolutely nothing in common with eMMC chips, there's a wholly independent controller on SSDs which simply doesn't exist in embedded devices. The firmwares we're talking about here are not even in the same device category.
[Galaxy Note II, Galaxy S III Developer Discussion ] E:V:A:
@AndreiLux: Yes, you're right, that was a bit over ambitious OT. But I'm also preventing more OT by people who will eventually post speculations about wear-leveling, and giving them the document and links to go research the topic by themselves. Increasing public knowledge will hopefully up the level speed of this discussion.

Also, the above can help explain why there are often large "empy" (non-user) partitions on Samsung phones. It could be that these act as moving "holes" to improve eMMC life. Thus if we remove them or keep our eMMC maxed out, we'll get problems much sooner than someone who has lots of space left.

But more importantly, I'm showing you that with a P/E of ~3000, it could very well be easily reached by any excessive writes, especially with eMMC firmware bugs. Also, I completely disagree that "SSDs have absolutely nothing in common with eMMC chips", they certainly do have much in common, as I stated above. An SSD basically consist of N x M Raid-0 like array of MLC NAND's, and each of those conforms to the exact same criteria as our eMMC in question. At the low-level the individual wear-leveling must be the same or very similar. (Mind you, I'm ignoring the SATA "controller" + cache memory.)

I could of course be completely wrong, but then I suggest that you provide some backup of your statement...

---

We should make a comparison of the "Smart Reports" from a working and a problematic eMMC. If these are very different, we could learn more...

Could someone dump such a report?
[Galaxy Note II, Galaxy S III Developer Discussion ] E:V:A:
Not sure if this helps, but if there is any dependence on kernel version, we might figure it from this list of kernel emmc patches...

[SIZE=2]2.6.36
• ERASE, SECURE ERASE, TRIM, and SECURE TRIM operations (JEDEC 4.4)
• mmc_block: Discard and secure discard support
• SD-combo (IO+mem) support
• Performance tests
2.6.37
• New sdhci-pxa driver for Marvell SoCs
• MMC 4.4 DDR support
• sdhci-pltfm: Platform driver for imx35/51
• USB SD host controller (USHC) driver
2.6.39
• mxs-mmc: MMC host driver for i.MX23/28
3.0
• MMC CMD+ACMD passthrough IOCTL reliable write support
• MMC boot partition support
• New VUB300 USB-to-SD/SDIO/MMC driver
• SD: Support for signal voltage switch procedure
3.2
• Enabled HPI for MMC cards that support this feature
• Cache control for e·MMC 4.5 devices
• e·MMC hardware reset support
• Random fault injection
• General-purpose MMC partition support (JEDEC 4.4)
• SDHCI: e·MMC hardware reset support
• sdhci-pci: Runtime PM support
• mmc-test: e·MMC hardware reset test
[/SIZE]

In the meantime I'm waiting with great expectations on the code for that kernel module...
[Galaxy Note II, Galaxy S III Developer Discussion ] koalauk:
I am sorry yes I know I am not spouse to post here as I am not a developer but I thought I ll share my little finding about SDS,

Users having SDS always confirming with the Red sensor LED staying on, As I have been a bit worried about SDS (4.1.1 UK BTU no update as of now) Everytime I rebooted (or started from switched off) I can see that bootloader checks HW as this red led comes on for about 0.6second and boot sequence continuous. But now I couldnt wait any longer for the BTU OTA update and now updated to N7100XXDMA6 N7100OJVDMA2 TURKEY rom and I can clearly see that during the startup process Red LED does not come on or HW is possibly not checked ! I hope I dont sound daft !! and SDS can be malfunctioning of Sensor board ?
[Galaxy Note II, Galaxy S III Developer Discussion ] E:V:A:
The possibility of eMMC firmware updates is determined by "Update_Disable" bit-0

of the FW_CONFIG field, which is located in CSD-slice [169] of the CSD register.
[Galaxy Note II, Galaxy S III Developer Discussion ] Entropy512:
So it sorta looks like in the original firmware, it's (bear with me, this is really fugly pseudocode)

if( !some_sanity_check_here())
{
crater_the_chip();
}

(where, obviously, crater_the_chip() is not actually a function, but it is what happens if that sanity check ever fails when called from that part of the code...)

Now it's

if( !some_sanity_check_here())
{
hang_chip_until_reset();
}

It's possible to boot from the MMC1 bus.

SDS is still not fixable since at this point, the internal eMMC is hosed at a very low level - unless we can figure out how to do a full reset/wipe of the eMMC chip from the main eMMC interface (we know that this is theoretically possible as Ken Sumrall of Google had access to such a procedure but was not able to provide us the info on it due to NDAs, but do not have any examples of performing this procedure due to aforementioned NDAs). Same reason Superbricked devices can't even be repaired using JTAG.

Some SDSed devices behaved similarly to how many Superbricked devices behaved - parts of the chip worked OK (including the bootloader), others were hosed. Quite a few people who suffered from SDS were able to boot into download mode but not write to any part of the chip.
[Galaxy Note II, Galaxy S III Developer Discussion ] exge:
Hi, my S3 bricked and even a JTAG could not save it. Yes, the eMMC was bricked at the very low level.

Samsung replaced my board and i checked it is now running 0xf7 revision, the sammy engineer also told me this is a safe fw immune to that superbrick. After further questioning and hardcore probing - the engineer revealed that the eMMC fw of 0xf1 has a bug in its wear leveling algorithm, which causes the sector containing the BIOS to be damaged, and this fw will fix that.

Will a dump of my firmware help you guys?

I tried a df,dmesg,lsof and other commands and could not find the mount point for the eMMC, so if you can tell me how to dump the fw, i will glady do it and hopefully it should help you.

PS: other threads on xda say samsung replaced their boards with the same defective ones; it seems that in my country, samsung actually replaces it with a newer revision.
[Galaxy Note II, Galaxy S III Developer Discussion ] Product F(RED):
Finally, a response from Samsung. Do you still have contact with the employee? Maybe he can guide us in the right direction for updating the firmware.
[Galaxy Note II, Galaxy S III Developer Discussion ] exge:
it wasn't exactly an official response from samsung, but because the repair guy and me are both computer engineers, i used that "brotherhood" to mine this data off him.
[Galaxy Note II, Galaxy S III Developer Discussion ] Product F(RED):
Gotcha. Do you think you could contact him at all, off the record? Tell him that we're trying to fix the issue on XDA (he'll definitely know about XDA) and we could use some [anonymous] help.
[Galaxy Note II, Galaxy S III Developer Discussion ] exge:
well .. i can try .. but how do i go to the service center and find that guy lol..

for now lets not put too much hope on him :(

just try to use the clues he told me :)
[Galaxy Note II, Galaxy S III Developer Discussion ] Rebellos:
Some phone repair guy from Samsung service won't know for sure what can help us, what you said is nothing we didn't know for quite long time. ;P

Unless he can tell if Sammy does something with the returned chips back in factory, or just reflow boards with new eMMCs or so. But even if they do repair them - I'm sure it's done out of his scope.
[Galaxy Note II, Galaxy S III Developer Discussion ] esat-net:
AW: eMMC sudden death research

Could there be a connection between the SDS and the Samsung Laptop Bug:

http://mjg59.dreamwidth.org/22855.html
[Galaxy Note II, Galaxy S III Developer Discussion ] E:V:A:
There are several ways to trigger a reset and at least one of the resets also triggers a full wipe... One is from JEDEC std CMD, another from bootloader, another (probably) from GPIO, another from mmc-tools...

Anyway, since we're not seeing any *.ko modules coming out of here, perhaps someone could provide some pseudo code for the fw dumper code? (We can compile & dump ourselves!)
[Galaxy Note II, Galaxy S III Developer Discussion ] Rebellos:
You have misunderstood something here. There are no documented nor known ways for formatting Samsung eMMC internal data. And this is what Entropy's talking about. Wiping user data from emmc is not any help.
[Galaxy Note II, Galaxy S III Developer Discussion ] Oranav:
Actually, to be more precise, it used to be:

void *val;
set_val_and_return_whether_succeeded(&val);
crater_the_chip_if_val_is_null(val);

Now it is:

void *val;
if (!set_val_and_return_whether_succeeded(&val))
halt();
crater_the_chip_if_val_is_null(val);

The Movi's BootROM is small enough to reverse entirely. I also saw some eMMC command handling there, so I think we can somehow talk with the BootROM even on superbricked devices.

This can be very interesting!

Excuse my laziness. For now, I don't mind to send you my own RAM dump; I'll write that .ko when I have a little more time.
[Galaxy Note II, Galaxy S III Developer Discussion ] Rebellos:
To give a little sum-up:

Theoretical solution for superbricked devices would cover disabling eMMC for a while to trigger MMC1 boot (tweezers/paperclip/pencil should do with some luck and steady hand)

Then code from external sd would do factory format and eventually permanent patch of eMMC.

For devices where eMMC is capable of booting up to the kernel we'd probably use some kexec.
[Galaxy Note II, Galaxy S III Developer Discussion ] Oranav:
WARNING: The attached patch is dangerous as it sends low-level commands to your eMMC chip. Please, use it ONLY if you know what you're doing.

I'm not responsible for anything!

I've attached a kernel patch which allows you to read the eMMC RAM.

Usage:

# cat /proc/devices | grep mmcram
248 mmcram
# mknod -m 0444 /dev/mmcram c 248 0
# dd if=/dev/mmcram of=/storage/extSdCard/mmcram.bin bs=4K count=128
128+0 records in
128+0 records out
524288 bytes (512.0KB) copied, 31.813499 seconds, 16.1KB/s

No lseek support if you wondered.

There's a memory hole at 0x20000-0x40000, so you'll get zeroes. Just ignore this part of the dump.

The patch also includes a rewrite of Samsung's patch to properly use the MMC quirks mechanism. I'll submit this part of the patch to CM someday.

* I'd like to get a dump of firmware 0xf7. If someone has a test device, you should be able to dump firmware 0xf7 if you move the "init_mmc_ram(card);" call to the top of the "mmc_movi_sds_add_quirk" function. If someone dumps firmware 0xf7, send it to me please. :)
[Galaxy Note II, Galaxy S III Developer Discussion ] AndreiLux:
Works here, extracted the 0xf1 firmware without issues. 0xf7 firmwares seem to be mostly prevalent in newer phones and non-white and non-blue models, so not many devs might have access. If somebody with 0xf7 wants to contribute, feel free to PM me for the kernel.

Oranav, mind if I keep the patch as is in the kernel with just the char device disabled for the public?
[Galaxy Note II, Galaxy S III Developer Discussion ] Oranav:
AndreiLux - no problem.

However, note that:

1. I didn't test the "other" part (quirk mechanism) thoroughly. After I test it enough, I'll submit it to CM. There might be some changes, so maybe you'd like to pull it instead of using the one I've attached.

Besides that, I saw that the SGS2 brickbug fix was merged into mainline; maybe I'll submit it to mainline as well.

2. The chardev code is very ugly (no conventions at all) and somewhat buggy (e.g. g_page is not thread-safe). Maybe it's better to fix it before merging it into your kernel, even if the code is disabled...
[Galaxy Note II, Galaxy S III Developer Discussion ] AndreiLux:
I'm not releasing anything yet until maybe in a week or two, I'll update with whatever changes you do until then and consider that I'll be running this anyway on my phone till then.
[Galaxy Note II, Galaxy S III Developer Discussion ] Entropy512:
No, no connection at all, other than Samsung doesn't seem to care about breaking interfaces and leaving flaws open that can kill devices.

They will always point the finger at someone else, even though (as Alan Cox mentioned at https://plus.google.com/111104121194250082892/posts/6Fo89YW6zGW ) - Anything that can be triggered by open source software could also be triggered by malware!

To be clear, this would be for devices bricked by SDS. We have no way to boot from MMC1 on Exynos 4210 (aka devices vulnerable to "classic Superbrick")

That said, it's starting to look like there might be a way to JTAG resurrect Superbricked devices.
[Galaxy Note II, Galaxy S III Developer Discussion ] E:V:A:
As much as it could be useful, I don't think we need to dump the eMMC

firmware, unless you are on a custom ROM or have problems with a non-Samsung

device. The eMMC firmware is available as long HEX structure in a firmware

header file in the GT-I9100, Jelly Bean open source, as part of the eMMC Field

Firmware Update (FFU) module. You can download these sources from the Samsung

Open Source Release Center. Unzip and extract the Kernel and go to:

./drivers/mmc/ffu/fw.h

I haven't checked the FW from the I9300 sources, but it could be worth

comparing it, since the eMMC chip may be different.

The data structure consists of 0x203E0 (132064 = ~128 KiB) hex bytes and

look like this:

[SIZE=2]const unsigned char movinand_fw[] = {
0x00,0x00,0x08,0x00,0x01,0x04,0x04,0x00,0xd1,0xb3,0x04,0x00,0xd3,0xb3,0x04,0x00,
...
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
};[/SIZE]

To convert this to a binary file, just pipe it through xxd like this:

cat fw.h |xxd -r -p >fw.bin

HERE are fw.h and fw.bin for the GT-I9100 for your convenience.

I was not successful in trying to replicate Oranav's results from Post#12. Not

sure what I did wrong. Also, not clear to where this piece fits in to the

memory map of Post#40, if it does at all.
[Galaxy Note II, Galaxy S III Developer Discussion ] Rebellos:
Hex you pasted looks indeed like beginning of samsung eMMC FW. I hate downloading stuff from Samsung OSRC. Could you extract their whole drivers/mmc dir?
[Galaxy Note II, Galaxy S III Developer Discussion ] Oranav:
E:V:A, this is just awesome; this code is rather new I suppose (I haven't seen any JB SGS2 source before).

Samsung actually field upgrades eMMC firmwares. It uses mostly vendor-specific and undocumented MMC commands, but we already knew much of this information thanks to the reversing process.

For those who are interested:

1. They validate that you've got a broken FW by reading a special extended Smart Report (reading address 0x1000 instead of 0 gets you an extended report).

2. If you do have a broken FW, they use CMD62(0xEFAC62EC) CMD62(0x10210001), which enters "SRAM writing mode". When you issue write commands, it just writes them to the SRAM (0x20000000).

3. They now write the whole buffer @ fw.h to the SRAM.

4. They then enter RAM reading mode by using CMD62(0xEFAC62EC) CMD62(0x10210002). Note that this is the exact command I've used to dump the RAM on my device, you can read about it on the old posts on this thread :)

5. They validate the FW upgrade payload by reading the SRAM.

6. If all is okay, they enter "RAM execute mode" by issuing CMD62(0xEFAC62EC) CMD62(0x10210010). They then jump to 0x20020001, which is just the Thumb2 function @ 0x20020000.

This is why the payload in fw.h has more than 0x20000 bytes (which is the size of the firmware). First 0x20000 bytes are the actual firmware, the extra bytes are the FW upgrade payload.

This is somewhat strange as they do have a built-in vendor specific MMC command to upgrade the FW, but they don't use it. I don't know why they do this. I guess time will tell.

I expect to see a similar FW upgrade for the SGS3 in the near time.
[Galaxy Note II, Galaxy S III Developer Discussion ] Entropy512:
Maybe whomever did it didn't know that command was there. They're pretty disorganized.

It's interesting as that appears to be a "upgrade without reformat". Perhaps the vendor specific command will always fullreset the eMMC?

This is actually the third or fourth I9100 JB source drop - HK got it in December, China a bit later.
[Galaxy Note II, Galaxy S III Developer Discussion ] Oranav:
Just a quick update: thanks to a kernel compiled by AndreiLux, and thanks to artesea for doing an eMMC RAM dump on his device, we've got the 0xf7 firmware!

It seems that it is runnable on the same hardware. It means that we can probably field upgrade I9300 devices, just as Samsung does with I9100.

The interesting question is whether we're able to preserve the data on the eMMC during the process. If the answer is no, a firmware upgrade would require PIT repartitioning and reflashing of SBOOT so that the device won't become a brick.
[Galaxy Note II, Galaxy S III Developer Discussion ] E:V:A:
As requested, HERE are the ./drivers/mmc sources (GT-I9100 JB).

[EDIT] (According to Entropy512, the stuff below is not related to FFU...)

To get an idea what chips they're fixing, we look in:

./drivers/mmc/card/block.c

...
[SIZE=2]static const struct mmc_fixup blk_fixups[] =
{
MMC_FIXUP("SEM02G", 0x2, 0x100, add_quirk, MMC_QUIRK_INAND_CMD38),
MMC_FIXUP("SEM04G", 0x2, 0x100, add_quirk, MMC_QUIRK_INAND_CMD38),
MMC_FIXUP("SEM08G", 0x2, 0x100, add_quirk, MMC_QUIRK_INAND_CMD38),
MMC_FIXUP("SEM16G", 0x2, 0x100, add_quirk, MMC_QUIRK_INAND_CMD38),
MMC_FIXUP("SEM32G", 0x2, 0x100, add_quirk, MMC_QUIRK_INAND_CMD38),
/*
* Some MMC cards experience performance degradation with CMD23
* instead of CMD12-bounded multiblock transfers. For now we'll
* black list what's bad...
* - Certain Toshiba cards.
*
* N.B. This doesn't affect SD cards.
*/
MMC_FIXUP("MMC08G", 0x11, CID_OEMID_ANY, add_quirk_mmc, MMC_QUIRK_BLK_NO_CMD23),
MMC_FIXUP("MMC16G", 0x11, CID_OEMID_ANY, add_quirk_mmc, MMC_QUIRK_BLK_NO_CMD23),
MMC_FIXUP("MMC32G", 0x11, CID_OEMID_ANY, add_quirk_mmc, MMC_QUIRK_BLK_NO_CMD23),
/*Some issue about secure erase/secure trim for Samsung MoviNAND*/
MMC_FIXUP("M8G2FA", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc, MMC_QUIRK_MOVINAND_SECURE),
MMC_FIXUP("MAG4FA", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc, MMC_QUIRK_MOVINAND_SECURE),
MMC_FIXUP("MBG8FA", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc, MMC_QUIRK_MOVINAND_SECURE),
MMC_FIXUP("MCGAFA", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc, MMC_QUIRK_MOVINAND_SECURE),
MMC_FIXUP("VAL00M", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc, MMC_QUIRK_MOVINAND_SECURE),
MMC_FIXUP("VYL00M", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc, MMC_QUIRK_MOVINAND_SECURE),
MMC_FIXUP("KYL00M", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc, MMC_QUIRK_MOVINAND_SECURE),
MMC_FIXUP("VZL00M", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc, MMC_QUIRK_MOVINAND_SECURE),

END_FIXUP
};
[/SIZE]...

To decipher that you may need to look at ./include/linux/mmc/card.h HERE.

[SIZE=2]
...
#define _FIXUP_EXT(_name, _manfid, _oemid, _rev_start, _rev_end, _cis_vendor, _cis_device, _fixup, _data) \
{ \
.name = (_name), \
.manfid = (_manfid), \
.oemid = (_oemid), \
.rev_start = (_rev_start), \
.rev_end = (_rev_end), \
.cis_vendor = (_cis_vendor), \
.cis_device = (_cis_device), \
.vendor_fixup = (_fixup), \
.data = (_data), \
}

#define MMC_FIXUP_REV(_name, _manfid, _oemid, _rev_start, _rev_end, _fixup, _data) \
_FIXUP_EXT(_name, _manfid, _oemid, _rev_start, _rev_end, SDIO_ANY_ID, SDIO_ANY_ID, _fixup, _data)
#define MMC_FIXUP(_name, _manfid, _oemid, _fixup, _data) \
MMC_FIXUP_REV(_name, _manfid, _oemid, 0, -1ull, _fixup, _data)
[/SIZE]...
[Galaxy Note II, Galaxy S III Developer Discussion ] Entropy512:
Yeah. My guess is that the new FFU firmware is specially designed to fix Superbrick without requiring a low-level reformat (like most firmware upgrades do. I know at least back a year ago, there was no known way to go from 0x19 to 0x25 without a full reset.)

That's a completely different patch than the FFU stuff. That's Samsung's original Superbrick patch, which was merged to mainline Linux in early September, showed up in I9300 JB (despite being of no use on I9100), and first showed up on an affected device with the I9100 HK JB source drop (which did NOT have FFU).

The original patch would just take all secure erase calls and translate them into nonsecure erase.

The FFU code is completely self-contained and has no interaction with the quirks code.
[Galaxy Note II, Galaxy S III Developer Discussion ] Entropy512:
Hmm. I need to take a closer look at this FFU stuff.

When running on my N7000 (VYL00M 0x19):

<1>[ 338.705203] c0 Found platform driver dw_mmc : c0cf8db8
<1>[ 338.705294] c0 Found platform device dw_mmc : c0cc8fb8
<1>[ 338.705310] c0 FFU getting host data success.
<1>[ 338.705333] c0 mmc0: clock 33333333Hz busmode 2 powermode 2 cs 0 Vdd 21 width 3 timing 5
<1>[ 338.720523] c0 FFU It's not a VHX. 0000

So whatever it's meant to update, it appears to be something other than a Superbrick-vulnerable eMMC.

I'll take a deeper look at this tonight - such as modifying it to display what it DID get from the Smart Report.