FORUMS
Remove All Ads from XDA

Discussion thread for /data EMMC lockup/corruption bug

5,342 posts
Thanks Meter: 7,242
 
By sfhub, Senior Member on 9th May 2012, 01:08 PM
Post Reply Email Thread
28th May 2012, 12:23 PM |#341  
nCoder's Avatar
Senior Member
Flag Dublin
Thanks Meter: 63
 
More
Found this e-mails of the guys that sign-off the code:

Hyunsung Jang <[email protected]>
Hyuk Lee <[email protected]>
Kukjin Kim <[email protected]>

Could you please contact them with the technical details of the problem to see if they at least reply with more technical details, and hopefully a solution?

Cheers
The Following User Says Thank You to nCoder For This Useful Post: [ View ] Gift nCoder Ad-Free
 
 
28th May 2012, 12:31 PM |#342  
musashiro's Avatar
Senior Member
Flag Tarlac
Thanks Meter: 89
 
More
why don't you try emailing them. tell them the scenarios specially the bricking on Open German release since thats official..

i really want flawless ics on my note.. im a stock+root lover and this bug literally f*cks us who love it that way..
28th May 2012, 12:51 PM |#343  
nCoder's Avatar
Senior Member
Flag Dublin
Thanks Meter: 63
 
More
Quote:
Originally Posted by musashiro

why don't you try emailing them. tell them the scenarios specially the bricking on Open German release since thats official..

i really want flawless ics on my note.. im a stock+root lover and this bug literally f*cks us who love it that way..

My problem, is that I'm not able to have a technical conversation with these guys.

If someone familiar with the problem and what Mr. Sumrall says, then would be much more efficient.

Cheers
28th May 2012, 01:27 PM |#344  
garwynn's Avatar
Retired Forum Moderator / Inactive Recognized Developer / XDA Portal Team
Flag NE Ohio
Thanks Meter: 8,731
 
Donate to Me
More
Forwarded all that I had to them - requested the f/w patch if possible but at least stop using the call to mmc_erase() or replace with a format writing all zeros to the partition. Will pass on if I get a response.
The Following 2 Users Say Thank You to garwynn For This Useful Post: [ View ] Gift garwynn Ad-Free
28th May 2012, 03:31 PM |#345  
CyberpodS2's Avatar
Senior Member
Flag NE Pennsylvania Boonies
Thanks Meter: 1,085
 
More
Quote:
Originally Posted by sfhub

DrNull did this on the "ODIN stuck on data.img" thread months ago. It just depends how badly the EMMC is broken. DrNull could only find a few MB for /data on his phone. I believe Note has more EMMC to work with, so you have more areas to relocate. I could theoretically build a custom kernel and relocate /data to external SD and workaround the problem also.

Personally I'd rather just get the thing replaced as you basically have a hard drive that crashed and you've lost some big areas of your EMMC. You may or may not be able to map around it, but it will be a different remap for everyone, assuming they have enough space available to make it useful.

Maybe a stupid question but couldn't a utility be created to just perm map out the bad areas like a low level does on a SCSI drive? I just don't know how you would get access to run the thing if it never starts at all.

Sent from my SPH-D710 using xda premium
28th May 2012, 04:42 PM |#346  
OP Senior Member
Thanks Meter: 7,242
 
More
Quote:
Originally Posted by CyberpodS2

Maybe a stupid question but couldn't a utility be created to just perm map out the bad areas like a low level does on a SCSI drive? I just don't know how you would get access to run the thing if it never starts at all.

The issue is finding the bad areas. You could create a tool to help, but it would require some manual involvement and might not be the most intuitive because as you try to find the bad area, everytime you access a bad area, it will lockup the phone to the point you must pull the battery.

If one were to create such a tool, you could probably simplify it (and make it semi-usable by the general user) by scanning up until the first lockup, then scanning down until the first lockup. then hopefully you are left with enough usable area to remap.

Personally I would still rather get the unit replaced while it is still relatively new as there are probably limitations to this approach that may not be immediately apparent. For example, you might need to create a custom .pit file for ODIN to work or the damage might not be limited to the sectors that couldn't be accessed and further wear-level activities might bring them to surface, even with fixed kernels.
The Following 2 Users Say Thank You to sfhub For This Useful Post: [ View ] Gift sfhub Ad-Free
28th May 2012, 04:47 PM |#347  
OP Senior Member
Thanks Meter: 7,242
 
More
Quote:
Originally Posted by sjsharksfan420

Is it not possible to "extract" the emmc firmware from data already available? Or do we need source code for that?

Even with source code for ICS kernel, it likely wouldn't include anything on updating EMMC firmware. We might be able to "guess" how to do it based on similar code, but it is probably a relatively dangerous operation to try and attempt without documentation resulting in bricked phones while testing.
The Following User Says Thank You to sfhub For This Useful Post: [ View ] Gift sfhub Ad-Free
29th May 2012, 12:58 AM |#348  
OP Senior Member
Thanks Meter: 7,242
 
More
I went back and traced the CWM recovery code to see how mmc_erase() was being called.

The call chain looks like this (the code is simplified for readability):

recovery.c
Code:
wipe_data() {
   erase_volume(/data)
   erase_volume(/cache)
}
Code:
erase_volume() {
  format_volume()
}
roots.c
Code:
format_volume() {
  make_ext4fs()
}
system/extras/ext4_utils/make_ext4fs.c
Code:
make_ext4fs() {
  make_ext4fs_internal(wipe=TRUE)
}
Code:
make_ext4fs_internal(wipe=TRUE) {
  write_ext4_image(wipe=TRUE)
}
Code:
write_ext4_image(wipe=TRUE) {
  open_output_file(wipe=TRUE)
}
system/extras/ext4_utils/output_file.c
Code:
open_output_file(wipe=TRUE) {
  if (wipe)
    wipe_block_device(out->fd, info.len);
}
system/extras/ext4_utils/wipe.c
Code:
wipe_block_device() {
  u64 range[2];

  range[0] = 0;
  range[1] = len;

  ioctl(fd, BLKSECDISCARD, &range);
  ioctl(fd, BLKDISCARD, &range);
}
I haven't compiled CWM recovery on ICS so this is just based on examining the CWM code people made available for their GB compiles so it is possible I haven't interpreted things correctly for the ICS-based CWM recovery.

So basically in GB there was no support for automatic "wipe" functionality using mmc_erase() (in kernel mmc driver) via ioctl() (in userspace). This functionality was added in the libext4_utils.a library for ICS. The function make_ext4fs() was modified to unconditionally always enables "wipe" whenever it is called. This change was added on 26-Jan-2011 by Colin Cross [[email protected]]

[Diff1 - make_ext4fs.c]
[Diff2 - output_file.c]
[Initial checkin - wipe.c]

Now I am only looking at the GB-based CWM code as I couldn't find any ICS-based CWM checked in for E4GT, so I might have this part wrong, but I'm guessing when people ported CWM to ICS, they linked against the new libext4_utils.a library and therefore called the new make_ext4fs() which unconditionally always "wipes" when called. This eventually results in the ioctl() which triggers the mmc_erase() in the mmc driver in the kernel, which in turn triggers the EMMC firmware lockup/superbrick bug.

Given that, my guess is that Samsung will likely make their patch in libext4_utils.a (and libext4_utils.so, which is not relevant for us since recovery is statically linked, it would only be relevant for Android utilities)

That means the change likely will NOT be in the kernel proper, but rather in the libraries CWM is linked against.

Since CWM is statically linked (at least the copy I saw checked in was) then that means even if Samsung patches libext4_utils.a, the CWM binaries we have now will not get that change.

They will need to be recompiled against the new libext4_utils.a that will be available when Samsung releases the source code.

Also there is actually no need to wait for the Samsung source code. If the people who compile CWM simply NOOP the "wipe" code in their current source tree, their recoveries should then be "safe".
This can be done in

/system/extras/ext4_utils/wipe.c

by replacing wipe_block_device() with

Code:
int wipe_block_device(int fd, s64 len)
{
  return 0;
}
The above code would be the simplest change to make recoveries "safe" again.

Now it would be better to replace it with code that writes zeros to the area (which you should be able to do with write() to the file descriptor coupled with some zero buffer and a loop)

Feel free to comment if I've made some mistake in my analysis.
The Following 12 Users Say Thank You to sfhub For This Useful Post: [ View ] Gift sfhub Ad-Free
29th May 2012, 01:18 AM |#349  
sniper's Avatar
Senior Member
Flag San Diego
Thanks Meter: 3,501
 
More
Quote:
Originally Posted by sfhub

So basically in GB there was no support for "wipe" functionality using mmc_erase() (in kernel mmc driver) via ioctl() (in userspace). This was added in the libext4_utils.a library for ICS. The function make_ext4fs() unconditionally always enables "wipe" whenever it is called. This change was added on 26-Jan-2011 by Colin Cross [[email protected]]

So send all of our hate mail to Colin Cross?

Sfhub, thank you again for all your dedicated hard work; you never cease to amaze us. I read through that and I think I understood most of it I'm glad we're(you guys, not really me, haha) still making progress with this.

Sent from my SPH-D710 using Tapatalk 2
29th May 2012, 01:30 AM |#350  
OP Senior Member
Thanks Meter: 7,242
 
More
Does anybody have the source code for update-binary that is included in the update.zips?

I want to see how that is built. If it is linked against libext4_utils.a there is a possibility it will have the same behavior as recovery.

I stress, this is not fleshed out by looking at the source, since I can't find it right now, so is pure conjecture, but this *MIGHT* explain why certain ROMs tend to trigger the EMMC lockup/superbrick bug. If their update.zip was packaged using an update-binary that was linked against libext4_utils.a from an ICS environment with the "wipe" change, then the install using that update.zip might trigger the bug.

If instead, folks on other ROMs bundled with GB-based update-binary linked against GB libext4_utils.a, then even though they are installing ICS-based ROMs, the calls by the updater would be GB-based and possibly not susceptible to the wipe problem.

Again this is even more conjecture, but theoretically if people took their GB CWM recovery that was linked against GB libext4_utils.a and repacked with ICS kernels, it would probably be safe. It is only the CWM that is linked against ICS libext4_utils.a that appears dangerous because it has the "wipe" functionality.

I don't build these recoveries myself. Can someone tell me what they did to produce CWM for an ICS environment? Did they just take their GB CWM binary (compiled against GB code base) and repack with ICS kernel, or did they recompile CWM within an ICS environment using the generic ICS code, then repack that with ICS kernel?
The Following User Says Thank You to sfhub For This Useful Post: [ View ] Gift sfhub Ad-Free
29th May 2012, 02:59 AM |#351  
biliskner's Avatar
Senior Member
Flag London
Thanks Meter: 29
 
More
Thumbs up
Quote:
Originally Posted by sfhub

I went back and traced the CWM recovery code to see how mmc_erase() was being called.

The call chain looks like this:

Wow. Great explanation. Thanks!

I agree that Sam will just change the libs rather than release a FW rev for their emmc. But one can always hope.......
Post Reply Subscribe to Thread

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes