[Samsung Galaxy R i9103] aaa839:
Important Documents for Kernel Developer

Project BricksBUGS by [MENTION=4141005]Lanchon[/MENTION]

http://xdaforums.com/android/software-hacking/project-brickbug-aftermath-recovering-t2823051

As you guys may know our devices got a eMMC superbrick bug since 2012 which posted by CM TEAM

it also present a report and patch solution provide by Samsung was disable the secure erase and trim(even nonsecure erase and trim also removed/disable) completely

Affected eMMC chip by our devices (VAL00M)MoviNAND

but it also cause one problem,Trim function broken

CM Report and workaround

http://wiki.cyanogenmod.org/w/EMMC_Bugs

Trim documents(Wikipedia):

https://en.wikipedia.org/wiki/Trim_(computing)

(This has been happen and report nearly 2 years ago,but no one concern or even intended to do somthing for bring back the trim)

Why Trim is important?Without it what happen will cause?

Trim is not a new technology in SSD even Flash memory or NAND Flash chip

Without Trim,it did not means our phone will have any data lost,

but you should feel your devices getting slower day by days,

Because the system cannot told to the SSD/eMMC controller the block has been cleared

also SSD/eMMC controller doesn't know the blocks has been cleared too

it just increase the searching time and need to random moving the sector which may not needed....

How does the SSD/eMMC sector design and Operation for doing writing?

the SSD/eMMC sector was using 4k as smallest store capacity(we called 1 paged),1 sector block=128Page So that mean

1 block sector size was 512KB,Even the SSD or eMMC or NAND minium writing/reading could smallest as 4KB

but when you need to do a wipe/erase operation,it need operate one block(512kb) each time

(Write=>4KB,Wipe=>512KB eachtime on new data writing operation)

Let's use an example for more easier learning:

When you need to write a new 3kb files to the SSD/NAND flash,The data will store as 4kb in the block sector page(even your data has not reach 4kb),(4KB=1 Page, 128Page = 1 Block=512 KB)

However when a new data need to be write,if the block sector has been present a data already,SSD/NAND/eMMC controller cannot just wipe that 4KB sector to write a new data over it.

it need to move the one blocks(each blocks as 512 KB=128Page) data to the cache>wipe and erase the blocks>Modified your writing files(4KB) in the cache and move it back to that block sector

That means if more writing operation,the SSD and NAND/eMMC do more above action=>then it will decrease the performance,because it need to always moving back from cache to block or block to cache

How does Trim doing to solve above situation??

1.Trim work like a maid of your SSD/NAND/eMMC controller

When you deleted the files,Trim function will just marked the block which need to be wiped for writing operation and will wait until the system was idle,then it will doing the above action in background

2.Trim also work like a recyclers/Garbage collector ,it could told the eMMC/SSD/NAND control to wipe and controlled each sector blocks more effective(no need to move any unrelated or random blocks on new writing operation each time) and decrease the moving time for block wipe action

Why we cannot be Trim?

As My mention at first paragraph due to the superbrick bug

Samsung/CM workaround was put the erase function disable completely in the kernel

(remember our eMMC support trim!)

to bring back the trim work it need to reenable the erase function

Trim require erase function work as well

even we have secure erase bug,it could still using non-secure erase for trim to work

Does it means there was no solution to brick back the trim

the answer is No,

Luckly some xda menber already know about this and try to workaround to bring back trim function work

which call Project BricksBUGS

http://xdaforums.com/android/software-hacking/project-brickbug-aftermath-recovering-t2823051

I have already adding the fstrim to the kernel even to the Rom

Does it means it could doing?

No,As I mention the erase function didn't enable(No one intended to do also)

,so you cannot use trim function

not relation with your android version,

Someone said 4.3 or higher cannot run Lagfix and will got operation was not support at endpointed devices

that is incorrect,

Because Google just implement the automatic trim,which was calling fstrim to do such function started at 4.3 while the users was idle.

if the kernel has disabled the require feature,even it have any binaries,it doesn't mean trim can work no matter any android version you have.the function was provide by hardware requirement and Kernel,not the system itself

That means it require our SGR Kernel experts to concern and reenable about it

if we need trim you have to re-enable the erase

For workaround to bring back function

please follow the project brickbug.(it need to modified the)

http://xdaforums.com/android/software-hacking/project-brickbug-aftermath-recovering-t2823051

But our devices was affected by brick bugs,It still safe to trim?

Maybe. Folklore says no,

For me,I will says"you should know that,any action which would touch the internal setting have a risk would cause your devices broken."However even the secure erase have bug,which could use an alternative solution

non-secure trim and erase function,it need redirects those action to non-secure

Also If you ask me to choose for performance but will have risk to brick and stable but slower than usual...

I will choose the first one,because even you were safe to prevent brick risk,

but the phone was slower than a snail day by days,"which should not be happen",this could cause more trouble than brick risk....

I would choose to let my phone in a risk of brick(but have performance enhance) instead of stable but slower than cannot be used daily:(

According my test result,I would says the Trim could bring back it was safe.

Here is my experiment,it was using stock ROM and kernel also without the any Samsung patch Kernel

Testing Enviroment:4.0.4(Official ICS TGY-ZSLPD)(no any patch!,just rooted)

this test has been run more than a months already,I have schedule to perform a fstrim each days too,

My Phone performance now back to same as fast as when I was bought this phone

apps installed quickly,writing more fast than you expected

Remarks:

1.It require the kernel which without the patch,and you could run the trim correctly

2.You could using the Lagfix or terminal with busybox which include fstrim

I"m not sure other SGR buddy would same as my result,(no data lost or brick)

but I would say,According my result

I would support to bring back the trim for our devices as experiments

if you are worrying on the risk,don't do any roots even trim or kernel change cause these type of action will cause damage too

For Anyone who are interst on bring the trim back to work

Please look at the below link for more info

Important Documents for Kernel Developer

Project BricksBUGS by [MENTION=4141005]Lanchon[/MENTION]

http://xdaforums.com/android/software-hacking/project-brickbug-aftermath-recovering-t2823051