More of: News
More on: app store, Apple, apps, Festival, ipad, iPhone, ipod touch, iTunes, London, News, Roundhouse

Not long ago we brought you a couple of tweaks for the Droid X2 that brought 3G speed improvements.While we live in a world of 4G internet for mobile phones, there are still a whole bunch of users out there who either don’t live in a 4G area or don’t use 4G because they like their phone battery to extend past the traditional workday, so they stay on 3G speeds and reap the battery benefits.

Recently, XDA Forum Member mykeevee got a little bold and tested the tweaks on the Motorola Photon 4G. Surprisingly, they actually worked, despite being on a different Motorola phone on a different carrier. Mykeevee tested the tweaks on CyanogenMod 7.2, so it’s unclear if it’ll work with every ROM. However, most in the thread have reported moderate to significant gains in transfer speed.

Those looking to give it a shot can head on over the mykeevee’s thread to check out other user reports to see if they could get it to work as well or straight to the original Droid X2 thread to try the tweaks for yourself. As always, make a backup before changing anything in case you wish to revert.

• TAGS: Motorola Photon 4G
• Comment

Since the latest leaks for the Samsung Galaxy S2 line up have been hitting us left and right, people have been jumping between ROMs—mainly between buggy, pre-release ICS builds and very stable GB. This is, after all, what we do on XDA as a habit: We see a leak, we flash it, we use it, and we tweak it. If it doesn’t fly, we simply roll back. Of course, there is always an inherent risk in flashing stuff that should not be on your device in the first place, but the risk of fully bricking a device in this day and age is rather small. Especially, since there are tools available to bring your devices back from the dead, such as UnBrickable Mod by XDA Elite Recognized Developer AdamOutler.

Having said this, not everything seems to be fine in the world of leaks. Thanks to XDA Elite Recognized Developer Entropy512, we have learned that most devices that are receiving leaks are at a very high risk of never waking up after a flash. It turns out that there is a major bug in the leaked ICS kernel that affects the /data partition in the eMMC chip, which apparently gets corrupted during certain operations such as wiping and flashing. This was originally believed to be affecting only operations performed in custom recoveries such as CWM. However, there have been reports of hard bricks being produced from the flashing from stock recoveries as well. The affected devices are:

• All Epic 4G Touch (SPH-D710) ICS leaks
• All Galaxy Note (GT-N7000) ICS leaks
• The AT&T Galaxy S II (SGH-I777) UCLD3 leak – and probably all others
• Korean SHW-M250S/K/L official releases and any kernel built from their source

Entropy and other devs have posted several warnings scattered throughout the site, in which they explain in detail what is happening. Our suggestion is that users should stay away from flashing ICS from leaks until the bug in the kernel has been completely fixed—unless of course, you are looking to hard brick your device. Remember, this is not something that can be resurrected via Unbrickable Mod or even via JTAG, as this is a firmware error in the eMMC. This is directly from Entropy himself for those of you interested in a bit more detail:

DANGER: Many Samsung ICS leak kernels may damage your device!

Those who pay attention to goings-on with various Samsung devices may have noticed that some devices are experiencing a large quantity of hardbricks when ICS leaked kernels are used. These hardbricks are particularly nasty, in that vendors of JTAG services have been unable to resurrect these devices, unlike simple bootloader-corruption hardbricks. This is due to the fact that these kernels are actually managing to cause what appears to be permanent damage to the eMMC storage device.

Kernels that are confirmed affected are:
[*]All Epic 4G Touch (SPH-D710) ICS leaks[*]All Galaxy Note (GT-N7000) ICS leaks[*]The AT&T Galaxy S II (SGH-I777) UCLD3 leak – and probably all others[*]Korean SHW-M250S/K/L official releases and any kernel built from their source

Kernels that SHOULD be safe are:
[*]GT-I9100 ICS leaks[*]GT-I9100 official releases[*]Kernels built off of the GT-I9100 Update4 source base

Operations that are likely to cause damage when running an affected kernel:
Wiping in CWM (and likely any other custom recovery) (confirmed)
Restoring a Nandroid backup in CWM (wipes first)
Flashing another firmware in CWM (most flashes wipe first)
Wiping in stock 3e recovery (suspected, also wipes a partition)
Deleting large files when running an affected kernel (suspected but not confirmed)

If you have an affected kernel:
Flash a known good kernel using Odin/Heimdall immediately. Do NOT use Mobile Odin, CWM, or any on-device method to flash. Known good kernels include:
[*]Nearly any Gingerbread kernel[*]ICS kernels built from the GT-I9100 Update4 source code

The root cause of this issue has yet to be determined, however, numerous Recognized Developers in XDA suspect it is due to Samsung enabling a feature in the affected kernels, MMC_CAP_ERASE – This is a performance feature that can greatly increase flash write performance, but appears to bring out a flaw in the flash chipset. GT-I9100 ICS kernels do not have this feature enabled and appear safe. However, not enough is known to declare all kernels without this feature safe – the only entity that can confirm the root cause of this problem and declare it fixed without taking great risk (destroying multiple devices with no way to repair them) is Samsung themselves.

In general, until further notice, if you are running a Samsung ICS leak for any Exynos-based device other than the GT-I9100, it is strongly advised to flash something else.

And this just showed up this morning in our forums as well, courtesy of XDA member garwynn. Apparently, Google has been contacted and they are aware of the issue, and working towards a fix.

Well, it’s been some time but thankfully Mr. Sumrall from Android did get back to us on our questions. I think the community will find that this was worth the wait.Issue: fwrev not set properly.
As we suspected the bugfix is not in our build. (The patch applies this unconditionally.)

Quote:

Originally Posted by Ken Sumrall The patch includes a line in mmc.c setting fwrev to the rights bits from the cid register. Before this patch, the file /sys/class/block/mmcblk0/device/fwrev was not initialized from the CID for emmc devices rev 4 and greater, and thus showed zero.(On second inquiry) fwrev is zero until the patch is applied.

Question: Revision didn’t match the fix
(Emphasis mine in red as it discusses the superbrick issue.)

Quote:

Originally Posted by Ken Sumrall You probably have the bug, but rev 0×19 was a previous version of the firmware we had in our prototype devices, but we found it had another bug that if you issued an mmc erase command, it could screw up the data structures in the chip and lead to the device locking up until it was powered cycled. We discovered this when many of our developers were doing a fastboot erase userdata while we were developing ICS. So Samsung fixed the problem and moved to firmware revision 0×25.Yes, it is very annoying that 0×19 is decimal 25, and that led to lots of confusion when trying to diagnose emmc firmware issues. I finally learned to _ALWAYS_ refer to emmc version in hexadecimal, and precede the number with 0x just to be unambiguous.However, even though 0×19 probably has the bug that can insert 32 Kbytes of zeros into the flash, you can’t use this patch on devices with firmware revision 0×19. This patch does a very specific hack to two bytes of code in the revision 0×25 firmware, and the patch most likely will not work on 0×19, and will probably cause the chip to malfunction at best, and lose data at worst. There is a reason the selection criteria are so strict for applying this patch to the emmc firmware.I passed on our results a few days later mentioning that the file system didn’t corrupt until the wipe. This is a response to that follow-up.As I mentioned in the previous post, firmware rev 0×19 has a bug where the emmc chip can lockup after an erase command is given. Not every time, but often enough. Usually, the device can reboot after this, but then lockup during the boot process. Very rarely, it can lockup even before fastboot is loaded. Your tester was unlucky. Since you can’t even start fastboot, the device is probably bricked. If he could run fastboot, then the device could probably be recovered with the firmware update code I have, assuming I can share it. I’ll ask.

Question: Why the /data partition?

Quote:

Originally Posted by Ken Sumrall (Android SE) Because /data is the place the chip that experiences the most write activity. /system is never written to (except during an system update) and /cache is rarely used (mostly to receiving OTAs).

Question: Why JTAG won’t work?

Quote:

Originally Posted by Ken Sumrall As I mention above, the revision 0×19 firmware had a bug that after an emmc erase command, it could leave the internal data structures of the emmc chip in a bad state that cause the chip to lock up when a particular sector was accessed. The only fix was to wipe the chip, and update the firmware. I have code to do that, but I don’t know if I can share it. I’ll ask.

Question: Can a corrupted file system be repaired (on the eMMC)?

Quote:

Originally Posted by Ken Sumrall e2fsck can repair the filesystem, but often the 32 Kbytes were inserted at the start of a block group, which erased many inodes, and thus running e2fsck would often result in many files getting lost.

So, while the fix doesn’t apply to us at the moment, we’ve been given a great insight into the superbrick issue as well as information that a fix is already developed (hopefully we’ll see it released!). The bug likely applies to us and assuming the fix for the 0×19 firmware is given then it would apply to our devices.

On a lighter note, I wanted to include his close:

Quote:

Originally Posted by Ken Sumrall You are getting a glimpse into the exciting life of an Android kernel developer. Turns out the job is mostly fighting with buggy hardware. At least, it seems that way sometimes.

Please stay clear from flashing anything ICS onto your devices until this has been solved.

Want something published in the Portal? Contact any News Writer.

[Thanks Entropy512 for all your hard work!!!!]

• TAGS: Android 4.x (Ice Cream Sandwich), AT&T Samsung Galaxy S II, Galaxy Note N7000, Samsung Epic 4G Touch
• Comment

GBkey V1.21 Released

More Details

Discuss Here