This workaround is for those of us (may only be me at this point?) who have bricked your Skyrocket by formatting a partition in an ICS-based kernel. This is where the kernel performed an MMC ERASE command and due to a bug in the eMMC firmware, the wear leveling data was corrupted.
The result is that accessing the affected section of eMMC causes the device to lock up. If we could find a way to avoid accessing those areas, the device might be usable again.
To further complicate matters, it seems that writing to the eMMC causes the problem to move around--probably because the eMMC tries to update the wear leveling data. As a result, any workaround needs to assume that no portion of the eMMC can be used for writable scratch space. That means it can't be used for /data, /cache, /tombstone, or "internal sd".
In this workaround, I create image files for the data, cache, and tombstone partitions on the external SD card. Then I modify the ramdisk to use the loop devices to mount these images as /data, /cache and /tombstone. The result is a bootable system.
The system obviously runs slower, but it is definitely tolerable. Usually the delay is noticed when opening an app for the first time. Another downside is that the "internal sd card" is gone and the "external sd card" is not USB mass storage mountable (since loop files are on it and therefore cannot be unmounted).
Thanks to seedub for the brainstorming session where we came up with this approach. I appreciate his Linux-fu.
Identifying If Important Partitions Work
On Skyrocket, for this workaround to be successful, we need at least the first 24 partitions to be okay. A few tests you should run:
- Can you boot into download mode?
- Can you boot into recovery mode?
- In recovery, run "adb shell dd if=/dev/block/mmcblk0pX of=/dev/null" where X is 1-24. Do these all complete without error?
- In recovery, can you install a ROM zip (e.g. CM9) without the device rebooting? (This is to test whether you can write to /system)
If the answer is "yes" to ALL of the questions above, then you are a candidate for this workaround.
Btw, always pull the battery and remove the USB cable before starting the above tests. Once the eMMC is locked up, it needs to be power cycled before it works again.
Creating The Image Files
You will need 1.5GB free. You can adjust the size of the data image to your liking. Boot into recovery and run the following commands in an "adb shell":
# Create an area on your SD card for the image files mount /sdcard cd /sdcard mkdir emmc_workaround cd emmc_workaround # Create the data image file (1 GB - normally on /dev/block/mmcblk0p25) dd if=/dev/zero of=/sdcard/emmc_workaround/data.img bs=1024 count=1048576 busybox losetup /dev/block/loop0 /sdcard/emmc_workaround/data.img mkfs.ext4 -m 1 /dev/block/loop0 busybox losetup -d /dev/block/loop0 # Create the cache image file (297 MB - normally on /dev/block/mmcblk0p26) dd if=/dev/zero of=/sdcard/emmc_workaround/cache.img bs=1024 count=304128 busybox losetup /dev/block/loop1 /sdcard/emmc_workaround/cache.img mkfs.ext4 -m 1 /dev/block/loop1 busybox losetup -d /dev/block/loop1 # Create the tombstone image file (64 MB - normally on /dev/block/mmcblk0p27) dd if=/dev/zero of=/sdcard/emmc_workaround/tombstone.img bs=1024 count=65536 busybox losetup /dev/block/loop2 /sdcard/emmc_workaround/tombstone.img mkfs.ext4 -m 1 /dev/block/loop2 busybox losetup -d /dev/block/loop2 umount /sdcard
Modifying a ROM
We have to modify the ROM to make this work. With a lot of effort you might be able to modify a stock ROM, but I would recommend only modifying a built-from-source ROM. I used CM9 since, well, I am most familiar with it.
Here is the outline of the changes:
- Disable the internal SD card on partition 28
- Make the external SD card non-removable and disable USB mass storage for it
- Rework the init scripts to mount the external SD card, attach the images to loop devices, and mount /cache, /data and /tombstone on their new loop devices
Apply patch #0001 (which is attached) to the device/samsung/skyrocket tree of CM9. See these build instructions: http://forum.xda-developers.com/show...82&postcount=3
Apply path #0002 if you want to move /cache to tmpfs instead of an image file. I'm still experimenting with this one.
I'm sure there are some ways to speed things up. I'll add to this list as we come up with more ideas.
- Use smaller image files
- Put /cache into a ramdisk -- probably would increase responsiveness a great deal (see patch #0002)
- Repartition external SD card instead of using image files