FORUMS
Remove All Ads from XDA

eMMC sudden death research

53 posts
Thanks Meter: 262
 
By Oranav, Member on 12th January 2013, 05:26 PM
Post Reply Email Thread
28th January 2013, 12:07 AM |#31  
Senior Recognized Developer
Flag Owego, NY
Thanks Meter: 25,477
 
Donate to Me
More
Quote:
Originally Posted by AndreiLux

Makes sense into why they upgraded the bootloader with LLA then, the increased modification detection would be just a side-effect of a newer bootloader version which already had heightened warranty enforcements on the 9305 and the Note 2's.

That alone would be enough to upgrade bootloader...

I don't believe SBOOT is encrypted or compressed - just run strings on it. If you see lots of recognizable strings, but don't see the eMMC model number, you can be fairly certain the BL doesn't contain a fix.
The Following 3 Users Say Thank You to Entropy512 For This Useful Post: [ View ]
28th January 2013, 06:02 AM |#32  
Senior Member
Thanks Meter: 885
 
More
Quote:
Originally Posted by Entropy512

That alone would be enough to upgrade bootloader...

I don't believe SBOOT is encrypted or compressed - just run strings on it. If you see lots of recognizable strings, but don't see the eMMC model number, you can be fairly certain the BL doesn't contain a fix.

I ran strings in the following BL versions:
- My current EMA1
- First changed release ELLA
- ICS BL ALEF

I'm attaching the results and a diff for each version, a lot of the content is gibberish but there are some quite interesting differences, mostly around line 1100.

Maybe it can help us understand a bit more or determine if BL plays a role.
Attached Files
File Type: zip Comparison_Strings_BL_ALEF_ELLA_EMA1.zip - [Click for QR Code] (137.0 KB, 139 views)
The Following 2 Users Say Thank You to drakester09 For This Useful Post: [ View ] Gift drakester09 Ad-Free
28th January 2013, 09:18 AM |#33  
AndreiLux's Avatar
Senior Member
Thanks Meter: 14,750
 
Donate to Me
More
Quote:
Originally Posted by drakester09

I ran strings in the following BL versions:
- My current EMA1
- First changed release ELLA
- ICS BL ALEF

I'm attaching the results and a diff for each version, a lot of the content is gibberish but there are some quite interesting differences, mostly around line 1100.

Maybe it can help us understand a bit more or determine if BL plays a role.

There are some bootloader MMC changes but if they're related to SDS is to be determined... no VTU00M string in there at least, but that still doesn't rule it out.

Quote:

usb_write reg, val
Read the usb ic register
sdcard test command
+mmcdtest

They added that mmcdtest into the bootloader utility commands, I wonder what it does.
The Following 2 Users Say Thank You to AndreiLux For This Useful Post: [ View ] Gift AndreiLux Ad-Free
29th January 2013, 07:16 PM |#34  
OP Member
Thanks Meter: 262
 
More
I'm reversing sboot to see what have changed (no "VTU00M" string doesn't mean there's no fix).
It should be very easy since we have kernel sources (we know how to communicate with the eMMC controller - MMIO addresses etc.).


* If someone has a BinDiff license and wants to help, it'd be great!


Quote:
Originally Posted by AndreiLux

They added that mmcdtest into the bootloader utility commands, I wonder what it does.

It reads 0xFFC00 bytes from the eMMC boot partition and copies them to 0x50000000 (maybe this is an output buffer? I don't know yet).
I also think 0xFFC00 is the boot partition size, so it just reads it all...
The Following 2 Users Say Thank You to Oranav For This Useful Post: [ View ] Gift Oranav Ad-Free
30th January 2013, 12:10 AM |#35  
AndreiLux's Avatar
Senior Member
Thanks Meter: 14,750
 
Donate to Me
More
Quote:
Originally Posted by Oranav

I'm reversing sboot to see what have changed (no "VTU00M" string doesn't mean there's no fix).
It should be very easy since we have kernel sources (we know how to communicate with the eMMC controller - MMIO addresses etc.).


* If someone has a BinDiff license and wants to help, it'd be great!



It reads 0xFFC00 bytes from the eMMC boot partition and copies them to 0x50000000 (maybe this is an output buffer? I don't know yet).
I also think 0xFFC00 is the boot partition size, so it just reads it all...

The U-Boot sources might interesst you, to get the general idea of the bootloader buildup. I don't know what the practical differences between U-Boot and S-Boot will be though, especially since the former will be outdated.
The Following 2 Users Say Thank You to AndreiLux For This Useful Post: [ View ] Gift AndreiLux Ad-Free
30th January 2013, 02:44 PM |#36  
Senior Member
Thanks Meter: 308
 
More
@Oranav/All:

We have some news regarding to the freezes that occur on some S3's with the new firmware...
Someone posted that he waited until the freeze is over and I asked how long. He said after 10-15 minutes the phone was back to normal without reboot.

So as my phone froze with screen on I waited and I really was suprised that after around 23 minutes freeze the phone just continued to work as it had never frozen.

Maybe the eMMC has a watchdog after all.

Maybe it is a interesing point that the phone is able to continue after a long time freeze.
Maybe we can get some infromation out of some log files?

Since 2-3 days my S3 has 5-20 freezes per day. I am on stock, unrooted XXELL5.

BR
Rob
The Following User Says Thank You to Rob2222 For This Useful Post: [ View ] Gift Rob2222 Ad-Free
30th January 2013, 03:45 PM |#37  
Senior Member
Thanks Meter: 308
 
More
Got a kernel log from just after such a freeze.

I was about to power on the screen but nothing happen. Then I waited around 10 minutes and the screen came finally up and I dumped the log.

Is this interesting?

Full log is attached.

Code:
U/ 4002.738352  c0 [keys]PWR 1
U/ 4002.983296  c0 [keys]PWR 0
...
U/ 4587.514100  c0 mshci: ===========================================
W/ 4587.514336  c0 mmc0: it occurs a critical error on eMMC it'll try to recover eMMC to normal state
....
V/ 4587.850296  c0 mmc0: recovering eMMC has been done
...
W/ 4587.850849  c0 mmcblk0: unknown error -131 sending read/write command, card status 0x900
W/ 4587.851982  c0 end_request: I/O error, dev mmcblk0, sector 3126872
W/ 4587.852174  c0 end_request: I/O error, dev mmcblk0, sector 3126880
W/ 4587.852330  c0 end_request: I/O error, dev mmcblk0, sector 3126888

EDIT: Added another log. Will add more, if I get more.


BR
Rob
Attached Files
File Type: txt 2013-01-30_16-39-42.txt - [Click for QR Code] (126.9 KB, 135 views)
File Type: txt 2013-01-31_12-47-45.txt - [Click for QR Code] (126.7 KB, 55 views)
The Following 16 Users Say Thank You to Rob2222 For This Useful Post: [ View ] Gift Rob2222 Ad-Free
1st February 2013, 03:19 PM |#38  
sodeknetters's Avatar
Senior Member
Flag Rotterdam
Thanks Meter: 72
 
More
Re: eMMC sudden death research
Yes, so it looks like the freezes have emmc involvement indeed!
1st February 2013, 05:56 PM |#39  
Senior Recognized Developer
Flag Owego, NY
Thanks Meter: 25,477
 
Donate to Me
More
Quote:
Originally Posted by Oranav

So I decided to do a small RAM dump after all.

Before the patch, 0x5C7EA reads FD F7 C2 FA, which is "BL 0x59D72".
As I thought, they replace a function call to the new one.

I will dump function 0x59D72 later this week.

Could you perhaps post the RAM dump? I might be able to hand it to someone with a copy of hex-rays decompiler.

How big is the RAM?

I'm thinking of maybe dumping VYL00M fwrev 0x19 while I'm at it, and maybe seeing if someone else can dump 0x25. :P
2nd February 2013, 10:59 PM |#40  
OP Member
Thanks Meter: 262
 
More
I have a Hex-Rays license. I actually reverse most of the time using it; I posted assembly code since it's easier to understand with these short snippets (in my point of view).

I won't post a RAM dump since it contains (probably?) licensed code.
I can however post the memory map:
0x00000000 - 0x00020000 BootROM (I guess it's a mask ROM)
0x00040000 - 0x00060000 Firmware (resides in RAM, the BootROM reads it from the NAND chip itself so it's upgradable!)
0x00060000 - 0x00080000 Data (no dynamic memory there BTW)
0x20000000 - 0x20028000 eMMC interface MMIO
0x20080000 - 0x20080400 I don't know, maybe another eMMC interface MMIO?
0x40000000 - 0x40010000 NAND interface MMIO


I can send you my RAM dump over IRC if you'd like. Besides that, I contemplate posting a .ko which exports the RAM over a character device (this is how I dumped it).

And, yes, dumping the new firmwares to see what has changed is super-cool
The Following User Says Thank You to Oranav For This Useful Post: [ View ] Gift Oranav Ad-Free
3rd February 2013, 11:11 PM |#41  
E:V:A's Avatar
Inactive Recognized Developer
Flag -∇ϕ
Thanks Meter: 2,216
 
More
You can dump all of your "live" RAM with Lime forensic tool:
http://code.google.com/p/lime-forensics/

But it may be overkill...
The Following 2 Users Say Thank You to E:V:A For This Useful Post: [ View ] Gift E:V:A Ad-Free
Post Reply Subscribe to Thread
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes