eMMC sudden death research

[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.

 

[Product F(RED)]

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.

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.

 

[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.

 

[Product F(RED)]

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.

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.

 

[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

 

[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.

 

[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

 

[E:V:A]

...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 ...

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!)

 

[Rebellos]

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

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.

 

[Oranav]

So it sorta looks like in the original firmware, it's (bear with me, this is really fugly pseudocode)
...

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);

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.

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!

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!)

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.

 

[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.

 

[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.

 

[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?

 

[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...

 

[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.

 

[Entropy512]

Could there be a connection between the SDS and the Samsung Laptop Bug:
http://mjg59.dreamwidth.org/22855.html

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 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.

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.

 

[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.

 

[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?

 

[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.

 

[Entropy512]

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.

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.