[Captivate Android Development] freshjr:
In another thread, they found the cause (and a potential solution) to seemingly the same issue we are having. The issue was acknowledged by sprint, samsung, AND even google. Everyone was involved because devolperes were trying to contact everyone so the bug information could reach the proper place to get corrected. This bug was even present in OTA ics releases. More on this later since there could be two different bugs (or maybe they are the same bug). This effect of the bug depend's on what EMMC firmware the phone contains. We have the fireware that locks up the card :mad:.

Here is my summary on all the information I have read scattered EVERYWHERE on the issue. I hope it helps some dev. I do not have the knowledge to further apply it.

The Issue:

The issue we are seeing is that the EMMC is locking up when being accessed. This happens only at certain portions within the EMMC card.

The Cause

The lockup is happening because of a wear leveling algorithm bug inside the EMMC firmware.

Some background:

Inside flash memory, each bit can only be written a finite amount of times before it goes bad. Because of this flash manufactures spread writes all around the card to level off the wear and extend life.

Inside conventional harddrive's writing new data by rewriting existing data or writing the new data to emptied (zero'd) data happens at the same speed. But inside flash memory, it is faster to write to zero'd data than existing data. The issue now is wheter the OS should handle where all data is exactly written to, or will it cooperate with the embedded controllers and let some operations occur low level.

Developers have found that the issue is most likely coming from the kernal changes in ICS that deal with how files are deleted on the EMMC card. The kernal itself is not buggy but the low level firmware in the EMMC card that handles file operations is.

It is speculated that the TRIM command and even the MMC_CAP_ERASE command are the ones triggering the issue. Older kernels such as (GB, etc) didn't support these commands.

It is also said that the I9100 ICS kernel doesn't support the TRIM or ERASE commands either. Mabye for now we should try switching to this kernal for our ICS builds?

The issue expanded

It is said that on EMMC cards that have firmware 0x19 (hexadecimal), that when the commands above are triggered they have the potential to lockup/brick the card. We are not sure what is causing the lockup.

For EMMC cards with firmware 0x25, samsung has coded up a fix to take care of the locking up issue but on this firmware version a potential for data curruption (on the order of 32KB) each time still remains.

Yet these two seperate bugs may be one and the same. It could be the but it is speculated that critical data structures on FW 0x19 are being overwritten by the 32kb of zeroes and that is why the card locks up. They data structures are not overwritten by the kernel but by the low level controller due to a bug.

We are not sure if it is the same issue in both 0x19 and 0x25, but for now we know that 0x19 locks up with those commands, and 0x25 has the data curruption problem.

Here is a link the FW 0x25 patch provided by an engineer from google, but was coded by an engineer from samsung to fix the 32kb of zeroes issue. This cannot be applied to our 0x19 firmware version since it was coded specifically for the 0x25 firmware. Possible black hole, phone blowing up, but most likely it just wont work.

https://bitbucket.org/franciscofranco/android-tuna-omap/changeset/cea631bdac53

Seemingly, we just need to disable the commands to stop the issue. That or samsung fix their damn buggy hardware or invent a workaround in the kernal.

Google says from their side, all of their code is okay and this mess is a result of samsung's buggy hardware.

Furthurmore this issue has been pushed closer to attention to samsung and sprint. It has been brought to their attention that large files operations on OTA ICS builds such as wiping from recovery manager could also brick phones. This is because these operations execute the same commands. Sprint/Samsung has developed another patch (maybe the same one from before *I don't know*) and tested with it a batch of phones with it.

Samsung/Sprint have tested 20 devices. 14 were with the patch, 6 were without. All 14 with the patch passed. Out of the 6 without, 4 of them bricked. All of them bricked since the error does not happen everytime the command is ran. It was done with sprint since the patch was for their epic 4g. They have been suffering from the same issue and bricking before us.

... Final words...

I see all of this is a lot of progress from and a lot of positive information compared to our lack of knowledge before. It could be that we suffering from the same bug and we are seeing it officially being fixed on some models. I hope we can learn and apply their fix.

It could be the same issue. What is see is that we are wiping using our safe non trim/MMC_ERASE commands. We are then installing the new kernal with the buggy commands. The google dev said that curruption happens in the /data location since it is the most used. It could be that its the 32kb of zeores at the wrong place locked up the card. Or something else to do with those commands locking up the card.

On a positive note, the google dev said that he has fixed the 0x19 firmware card by doing a full wipe but he cannot release his fix without authorization since it is proprietary information. Presumably to fix, we would have to make the card enter some special vendor mode, and clear EVERYTHING, then blast it with a working flash configuration.

I hope we can learn from the sprint/samsung released patch. Or maybe even the earlier released patch by samsung to google.

For now, lets try using I9100 ICS kernals. (or is that what he had the whole time).