Database Users

eMMC fix?

i think i might have found a possible fix for the eMMC corruption.
credits go to 3p4145 for discovering this:
Well I am in no way an expert or have enough knowledge to find an answer.. but I have some basic idea... so here it goes...
If I understand correctly, the problem is that the eMMC driver chip gets corrupt...
This chip controls the MMC0 which is (part of the chip) the actual flash upon which the phone relies to store its stuff...
No Since the issue is seen with rooted phones more often, I would imagine something that was written to the mmc0 is causing issues.. Using root explorer, i found this file on my /proc/emmc
This file seems to have the some sort of memory locations for various directories on the mmc... a corruption of this file could be a bad thing... I am not saying that this is the cause.. but if anyone with a bricked phone could get into their FS (i have no clue how) and check this file.. we could look into coming up with a generic file with memory address that are common....
Mine seems to have locations address for:
misc
recovery
boot
system
cache
userdata
devlog
pdata
Click to expand...
Click to collapse
as he stated, the eMMC files that might be corrupted in the failed eMMC chips are located in /proc/emmc.
i have been able to get to this location using adb
Code:
cat /proc/emmc
so, would it be possible to copy the correct files from a good chip to this location, and fix the failed eMMC problem?
the failed chip's filesystem got corrupted i think (correct me if i'm wrong)
i have the emmc file, pm me if you want it.

seems like a good theory. let's say you do copy the files from a good chip over to the bad emmc...how could you simulate or know when/how the M4G2DE 2.10GiB units would fail?

suchavibrantthang said:
seems like a good theory. let's say you do copy the files from a good chip over to the bad emmc...how could you simulate or know when/how the M4G2DE 2.10GiB units would fail?
Click to expand...
Click to collapse
it's impossible to tell when the chip will fail. but when they do.. could someone try this?

So it's a software failure and not an actual hardware failure? I'm not sure how likely this is to solve the issue, but any movement towards a solution is a good thing.

TeeJay3800 said:
So it's a software failure and not an actual hardware failure? I'm not sure how likely this is to solve the issue, but any movement towards a solution is a good thing.
Click to expand...
Click to collapse
it's more of a firmware issue. inside a computer, there are many different chips. some chips are consisted of firmwares, these are the ones that you can write to and change (like the eMMC chip). other chips, are completely hardware, you can't write to them, you can't change them.
so since the eMMC chip is consisted of "software", then maybe we can replace the corrupted files with good ones.
but i need some testers, since my dead eMMC chip is somewhere in tmobile's dead phones junkyard.

If it's the chip itself that fails - then you can't fix it by writing something to it, since it won't write whatever you're trying to write to it. Trying that would be equal to trying to fix a failed hard disk by using it.
"Firmware" is just another term for software. No chip consists of firmware, firmware is written on memory (permanent or rewritable), which is read by some hardware (usually some type of CPU) that executes this firmware. eMMC is just a rewritable memory chip, and if the controller of the chip fails, or big chunks of the memory in this chip fail - it's not usable anymore.
And of course, there is no such thing as "driver chip". Driver is a program, software, that runs on CPU and is stored in - again - memory. eMMC controller, on the other hand, is hardware, a part of the chip itself. The failure is on a whole another level.

Jack_R1 said:
If it's the chip itself that fails - then you can't fix it by writing something to it, since it won't write whatever you're trying to write to it. Trying that would be equal to trying to fix a failed hard disk by using it.
"Firmware" is just another term for software. No chip consists of firmware, firmware is written on memory (permanent or rewritable), which is read by some hardware (usually some type of CPU) that executes this firmware. eMMC is just a rewritable memory chip, and if the controller of the chip fails, or big chunks of the memory in this chip fail - it's not usable anymore.
And of course, there is no such thing as "driver chip". Driver is a program, software, that runs on CPU and is stored in - again - memory. eMMC controller, on the other hand, is hardware, a part of the chip itself. The failure is on a whole another level.
Click to expand...
Click to collapse
You summed up my thoughts on the issue perfectly, especially the first paragraph. That's why I didn't understand why the OP's theory would work. I'm not knocking his efforts at all...anyone trying to fix the eMMC issue is doing a good thing, it just didn't make sense to me.

oh...
sorry.. i thought the chip was just corrupted when it said "failed"...
well then nevermind, this wouldn't work.

Thanks for talking abt this guys..
I understand what you guys are saying.. but quite often the HW itself is not bad but the address locations are corrupt.. Like I mentioned in my initial post... I am not sure what causes the fault.. but Once caused, IF there is a way to just re-write the addresses for these locations so that the driver chip/Controller chip can try to use the addresses provided is what I am trying to see..
This statement is right on the amrk: "eMMC is just a rewritable memory chip, and if the controller of the chip fails, or big chunks of the memory in this chip fail - it's not usable anymore."
now considering this, IF the controller is physical fault (as in fabrication fault, overheated transistors etc).. the nothing more can be done.. BUT if the fault is just in the addressing fail.. this providing the addresses should work wouldn't you think?
If someone has a brick on their desk they can try this.. Nothing really to loose right?
I would never suggest replacing the emmc file of a working chip.. now thats just crazy talk.. well if you have $500 to spare.. sure.. but I was thinking of fixing a broken one...
One more last thing: The only problem with this approach on a dead phone is getting access to the FS AFTER the phone is dead.. any ideas?

3p4145 said:
Thanks for talking abt this guys..
I understand what you guys are saying.. but quite often the HW itself is not bad but the address locations are corrupt.. Like I mentioned in my initial post... I am not sure what causes the fault.. but Once caused, IF there is a way to just re-write the addresses for these locations so that the driver chip/Controller chip can try to use the addresses provided is what I am trying to see..
This statement is right on the amrk: "eMMC is just a rewritable memory chip, and if the controller of the chip fails, or big chunks of the memory in this chip fail - it's not usable anymore."
now considering this, IF the controller is physical fault (as in fabrication fault, overheated transistors etc).. the nothing more can be done.. BUT if the fault is just in the addressing fail.. this providing the addresses should work wouldn't you think?
If someone has a brick on their desk they can try this.. Nothing really to loose right?
I would never suggest replacing the emmc file of a working chip.. now thats just crazy talk.. well if you have $500 to spare.. sure.. but I was thinking of fixing a broken one...
One more last thing: The only problem with this approach on a dead phone is getting access to the FS AFTER the phone is dead.. any ideas?
Click to expand...
Click to collapse
using adb you are able to get into the filesystem...

A failed partition update would mean the emmc file was corrupted??
Or failed partition update means it wasn't able to update partitions because the chip failed to re-initialize??
If the theory is correct, the EMMC file not the chip is actually screwed up and it can be fixed, but if the emmc chip is what failed then it is irrecoverable.

tKoHaXoR said:
A failed partition update would mean the emmc file was corrupted??
Or failed partition update means it wasn't able to update partitions because the chip failed to re-initialize??
If the theory is correct, the EMMC file not the chip is actually screwed up and it can be fixed, but if the emmc chip is what failed then it is irrecoverable.
Click to expand...
Click to collapse
i'm pretty sure it the eMMC's filesystem got corrupted, but of course, i could be very wrong.
that's why we need a bricked MT4G with dead eMMC.

Has this been posted in the g2 forums? I know they have had some guys lookin into this as well...
Sent from my HTC Glacier using XDA Premium App

irrelephant said:
Has this been posted in the g2 forums? I know they have had some guys lookin into this as well...
Sent from my HTC Glacier using XDA Premium App
Click to expand...
Click to collapse
should i also post this in the g2 forums?

saranhai said:
should i also post this in the g2 forums?
Click to expand...
Click to collapse
I believe there are a few ppl there with the failed emmc that still have their phones...
Sent from my HTC Glacier using XDA Premium App

irrelephant said:
I believe there are a few ppl there with the failed emmc that still have their phones...
Sent from my HTC Glacier using XDA Premium App
Click to expand...
Click to collapse
yes thank you

irrelephant said:
I believe there are a few ppl there with the failed emmc that still have their phones...
Click to expand...
Click to collapse
Do any other models have this issue, or is it just T-Mobile phones?

TeeJay3800 said:
Do any other models have this issue, or is it just T-Mobile phones?
Click to expand...
Click to collapse
I have heard about 4 or 5 phones have had the bad emmc... Just Google phones with bad emmc and I'm sure there will be a list
Sent from my HTC Glacier using XDA Premium App

question: would the stock rom/pd image have this so called "good" file imbedded in it?
i ask because my current phone has gotten the cache errors while on rooted non-stock roms such as ice glacier and CM7..i was able to recover from them...but never once saw any issues after flashing completely back to stock...ive also not seen this issue arise after flashing from stock into Virtuous Unity and ive been on VU for almost 2 weeks and ive flashed a few radios and restarted my phone at least 2 dozen times to see if i get the cache error and so far nothing
all of which kinda leads me to believe that this very well could be a software or file issue thats being written maybe too many times or written with incorrect information due to flashing multiple roms or radios or something...i know not everyone with the "bad" emmc has had issues but maybe they arent doing something to trigger the bad errors

here's the emmc file located in proc:

Discussion : Hard Bricking bug could be fixed

Today Franco Kernel R3 was released and it included the removal of :
* Removed MMC_CAP_ERASE (workaround to fix the superbrick bug)
Boy124 on the other hand, flashed the kernel. Performed a wipe/factory reset twice, and phone successfully booted. As well as, flashed stock GB in PC Odin for checkup, and the rom was successfully flashed.
So is it the time where the bug is being solved? The more confirmation, the better, the safer. Cheers.

GocaS6 said:
In case that someone missed it
(tnx to user garwynn)
Fresh off the press...
Q: Alternate erase method?
Originally Posted by Ken Sumrall (Android)
If you really want to erase data on a rev 0x19 samsung emmc chip, I suggest you just write zeros to the entire partition.
Click to expand...
Click to collapse
Based on the other thread about this.
Is it possible to create a partition from that faulty blocks and mount it on to PC? later on I will use data wiping software to write 0..
Im thinking of trying this. but Im still quite unsure yet on how to actually mount second partition to PC, besides the UMS partitition

Looks like the bug is still there!

blue_panther9_9 said:
Based on the other thread about this.
Is it possible to create a partition from that faulty blocks and mount it on to PC? later on I will use data wiping software to write 0..
Im thinking of trying this. but Im still quite unsure yet on how to actually mount second partition to PC, besides the UMS partitition
Click to expand...
Click to collapse
You cannot format or write zeros into the bad blocks because you cannot access them.
You can low level format the whole chip, but then you need to restore the or rebuild the bad blocks list. Finally you would need a Jtag to rewrite the bootloaders into the chip.

Princeomi said:
Looks like the bug is still there!
Click to expand...
Click to collapse
When the bug damages the emmc, it will not be until after the faulty sector is written to/used that the problem will become apparent.
The bug does not have to be present in the current kernel to cause the brick. In the case of this claim, info about his/her previous ICS flashes and wipes is much more important than the proverbial straw that broke the camels back.
Sent from my GT-N7000 using XDA

BIOS - NAND - Whatever - Explain

Where is the BIOS in this thing? I get that it has /boot /system and /recovery but where is the firmware that the device very first utilizes?
Does the streak even have any type of NVRAM memory?

webdawg said:
Where is the BIOS in this thing? I get that it has /boot /system and /recovery but where is the firmware that the device very first utilizes?
Does the streak even have any type of NVRAM memory?
Click to expand...
Click to collapse
What are you attempting to do?

Understanding and Hacking
I am trying to understand the device and search for potential exploit vectors. If I take out the inner SD card what type of data does the device still have on it?
It has to have something that starts the boot from the inner SD card. Does this something insert anything into the running code on the device? Can it?
Can, if the device has the type of storage I am talking about, the device record and store even a small amount of data?
I have heard of reference to NAND backups and even seen a quote about how the NAND backup util included in the recovery utils does not backup something. The something I am referring to is not the external SD card.
Web...
Strephon Alkhalikoi said:
What are you attempting to do?
Click to expand...
Click to collapse

Why would you need exploit vectors when the system is completely open/unprotected?
the innerSD holds the /data and /cache partitions

It is like I am not making myself clear enough. A computer has a BIOS which passes boot to the OS/bootloader. Would not the phone have the same thing. If you do not know this answer do not ask anymore questions.
Stop asking why I am asking.
TheManii said:
Why would you need exploit vectors when the system is completely open/unprotected?
the innerSD holds the /data and /cache partitions
Click to expand...
Click to collapse

webdawg said:
It is like I am not making myself clear enough. A computer has a BIOS which passes boot to the OS/bootloader. Would not the phone have the same thing. If you do not know this answer do not ask anymore questions.
Stop asking why I am asking.
Click to expand...
Click to collapse
Unfortunately for you it seems you don't know what you're doing or why you're even asking about it
Sent from my GT-I9100 using Tapatalk 2

Okay Then
cdzo72 said:
Unfortunately for you it seems you don't know what you're doing or why you're even asking about it
Sent from my GT-I9100 using Tapatalk 2
Click to expand...
Click to collapse
Please. Unless you have an answer please do not reply. I know exactly what I am talking about. If the device does not have any NVRAM in it that one could flash to and only internal memory via SD card then just say this.

webdawg said:
It is like I am not making myself clear enough. A computer has a BIOS which passes boot to the OS/bootloader. Would not the phone have the same thing. If you do not know this answer do not ask anymore questions.
Stop asking why I am asking.
Click to expand...
Click to collapse
Manii knows far more about the Streak than you do, so if you want your questions answered, I suggest you check that attitude of yours at the door.

Strephon Alkhalikoi said:
Manii knows far more about the Streak than you do, so if you want your questions answered, I suggest you check that attitude of yours at the door.
Click to expand...
Click to collapse
Your right. Did not realize it was him, work has an affect on my attention. Sorry Manni.
I am at home now. Let me try and expain myself.
I just do not get it. All the pages I have read and the research I have done everything tells me that everything is stored on the internal SD card.
But I still have this nagging thought from this page: http://www.rdtk.net/2011/06/25/using-streakmod-recovery/ that says this: the firmwares reside on the nand but in an entirely separate area. only stock recoverys can write to them under normal circumstances, you can probably read/write them manually but it’s dangerous as you can super-brick if you don’t know what you’re doing
What the hell is that guy talking about? The way I read it is that an entire subset of firmware exists on the device that only that one webpage has ever talked about. (That I have read)
I have read alot about BIOS hacks and how they function inserting code into Windows. Even legitimate code for paid services. Computrace.
I know about the Carrier IQ software. What I do not know about is the software outside the rom, recovery, boot partitions and such that exists on the Dell streak or any Android device.
I suppose my attitude comes from the ton of forum posts that I read with unanswered questions because people wanted to know why the OP is asking such a question.
I took Manii's post the wrong way because of your question Steven. Not to offend you and I understand why you ask. For example I just hate going into support channels and asking questions about an iptable rule and being told that I should relearn Linux networking because...well just because I did not understand one concept. I took it the same way here.
I apologize to all.
Web...

MTD based nands are more complicated then eMMC nands in this aspect, as MTD nands you simply cannot read from the 'hidden' portions of the nand. eMMC ones you can.
eMMC devices you can always read from any eMMC partition, so you can likely make complete backups including your modem (though no custom recovery does this by default, it's still a bad idea)
Fortunately for us, MTD seems to be 'obsolete', every device that launched with GB installed or newer uses eMMC.
Dell Streak 5/Partition layout - XDA wiki
Dell Streak Pro/Partition layout - XDA wiki
The S5 is a MTD device, the SPro is eMMC, note how the SPro has many more partitions.
The majority of them also exist on the S5, but the only way to access them (safely) is though a stock recovery.
You can write to them with fastboot, but some of them must be unpacked by an updater in the stock recovery. Simply flash them (specific ones) and you'll super-brick that would require JTAGging at a minimum to fix.
You simply cant read the other MTD partitions without JTAGing (it might be possible with a specificly modified kernal, but you dont gain anything doing this, if at all), assuming that the hidden parts are MTD partitions even. For all we know the controller could be directly writing onto NAND pages with their locs hardcoded (which would kinda be like partitioning, but without the formal partition tables(?) )
There's also is a small amount of memory that can only be written (afaik) via JTAG.
It contains your device's ID, such as Service tag and IMEI.
On tegra devices (at least the S7 and S10) it's the WP1 and WP2 partition.
It could be possible that it's on the NAND as a MTD partition, but if it is we dont know about it. It would be insane (and illegal, as changing your IMEI is illegal in most countries) to write to it, but so there's never been an example of it. I dont know where they are on the SPro, i'd need a live device to check.
The modem OS itself is stored on the nand, the modem processor knows (or the bootloader knows) how to feed it it's OS image.
Location breakdown:
NAND: <everything on the partition layout above, including the below>
/system
/firstboot
boot.img
recovery.img
amss.mbn
appsboot.mbn
dbl.mbn
dsp1.mbn
fsbl.mbn
osbl.mbn
DT.img
The innerSD
/data
/cache
Modem storage (lock state)
Device unique data (IMEI and Service tag)
RTC (the clock)
I dont know the exact terminology or the exact order of booting on qualcomm snapdragons (it's likely to be the same with all at least in the same generation)
But it's something like:
Press power button
CPU powers up
IPL loads <hardwired onto cpu>
Check if innerSD is valid (this is streak specific, device also locks up if it fails as the loader isnt robust enough to work around it)
Init modem and it's firmware <amss.mbn on older devices, non_hlos.bin on newer devices> (FYI modems are themselves complete 'system's in that they have their own ram and OS, basebands are complete OS images in most devices)
Check what button combos are pressed
Start booting:
If you pressed the recovery mode combo:
Load recovery SPL <dbl.mbn? + DT.img>
Display SPL menu:
Reboot
Load Recovery ("update from update.pkg")
Read from recovery.img and load it
Caliberate screen
If you pressed fastboot mode combo:
Load the fastboot loader <fsbl.mbn?>
If you pressed the download mode combo:
Go into download mode (for QDLtool)
If you did not press any combo: begin booting normally
Load dsp1.mbn
Load boot.bin
Linux kernal mounts and starts reading:
/system
/cache
/firstboot
/data
Android boots normally
Boot completes, you're at the lockscreen/home screen
I'm just making educated guesses at which *.mbn does what, as noone's really studied them to the point that they are willing to modify them.
Regardless they're signed so you cant modify them (we dont know per-se that the CPU checks the signatures on *.mbns, but I dont think any is willing to risk their device to try anyway)
The kernal images arnt signed, you can simply toss any kernal that is valid (otherwise it wouldnt boot)
When your device boots, the logo flashes 4 times:
1st logo: IPL and it's logo (possibly hardwired onto chip)
2nd logo: SPL and it's logo (stored in one of the *.mbns)
3rd logo: UBOOT and the kernal logo (stored with the kernal, sounds like a band name)
4th logo: bootimage.zip (whatever boot splash is with the installed rom

TheManii,
Thanks for the information. This is everything I wanted to know. If I have anymore questions I will ask later.
Web...

[Q] SOLVED- Process to map out bad sectors on a500? Replace MOBO

SOLVED the best way.. See post #5
Hello
I have asked this in other threads, but have not gotten an answer that I can manage to make work yet. I'm also hoping that this thread may help the many others out there with this same problem.
I have an Iconia A500 that has the bad sector problem. I cannot get it to format partitions through any of the EUU's out there,or even the Babsector .bat's . Same thing every time-read/write failure. I have seen mention in a thread or two about guys who have used the "rawdeviceread" and "rawdevicewrite" commands in NvFlash to "map out" any bad sectors on the EMMC chip, and create "dummy" partitions over them so that the tablet will function again, at least until more sectors die anyhow.
Can someone please explain this process, including describing the files needed, exact commands, and the rest of the process to make this happen? I have seen member "Yaworski" describe the basis of it, but again his commands are no-go for me. It would also be great if a partition could be created, but not formatted, completely bypassing any possibility of NvFlash failure.
Thanks in advance By helping me I'm sure you wil also help many others. It seems many a500's are starting to suffer form this same exact issue.

Anyone? I have read thru this post: http://forum.xda-developers.com/showthread.php?t=1691729&page=3 , and seen a couple recommendations to it in other threads, but no dice on making it work .. or even being able to map out the bad sector/s. I know this'lll fix me up at least temporarily...

I need help with this as well. There doesn't seem to be a step by step guide anywhere :\
Sent from my SGH-T769 using xda premium

dynospectrum said:
I need help with this as well. There doesn't seem to be a step by step guide anywhere :\
Sent from my SGH-T769 using xda premium
Click to expand...
Click to collapse
I've been asking around about a possible process of mapping out bad sectors, and not just members in here, but engineers and technicians I know as well. First, the NAND has this sort of embedded firmware that directs it to remap or bypass bad sectors “spontaneously,” if you can call it that. When you're stuck with “write errors” or where the NVflash even fails to create and format a partition, it suggests that this part of that firmware is not working. Why the loose fit, or lack thereof, I don't know.
Second, The FCK guys mention that you can write a dummy file and make the device read back so you can see where the data is missing and circumvent it altogether. But they also state that if Sector 0 – which NVFlash is slated to access – is kaputt, then it would hang, as probably in your case and certainly in mine.
Given that the Boot Configuration Table is 4Kb tiny while the NAND is 16Gb large, I can't imagine the latter being damaged so badly as not to have a continuous space of 4Kb to accommodate such partition. As a matter of fact, I did have someone with special equipment probe my NAND “physically” and the initial report indicated that the first half (50%) of it had less than 3% of its sectors that was bad. NVFlash, however, could neither create nor format, let alone write on it.
So, either one must have the appropriate hardware to do a very low level format to restore the NAND in full or in part, or NVFlash has to be hacked to command writing at a Sector different than 0. Until that happens, I doubt it that a step-by-step guide grounded in current programs would be viable.
I know that neither the custom ROMs nor the custom Bootloaders and Recoveries are remotely the cause, because this occurred way before any of it came onto the scene. But in light of the frequency at which this happens to some of us, it seems ironic to term this device bullet-proof. I'd like to think it's not incurable, but what the FCK do I know? (Sigh) Anyone with the essential hardware know-how to tackle this?

SOLVED..well the "easy" way....
I sourced out a broken A500(strangely the screen is fine though lol), re-soldered the power button on it(PITA), and put it into my A500.
I plan on taking it easy with the flashing on this one. A500s seem to have a growing history of EEMC chip failure from over-flashing. My old board had been flashed MANY times by the previous owner, and a few by me before it died. The "new" tab was only flashed enough to get it to Stock ICS. Now it has the V8 bootloader and Civato's Re-Flexx ROM(Best out there IMHO).
So there you have it.. this seems to be the best way to fix this problem on the A500---Replace the Darn motherboard. I'd imagine mapping/skipping sectors is only a temporary fix that will probably lead to the tablet dying when its needed most.

[GUIDE] Re-partition your device using REPIT

You might have seen this guide on XDA, but is out-dated and only seems to work on stock firmware. What about people people running CM13, will it work, or will it brick your device?
This guide is updated and works with CM13 tested by me, it was also written with the i9300 16GB model in mind.
FAQ: next post
I take NO responcebility for any bricks, that's on you. Exactly like rooting, or installing anything 3:rd party (right?). Either is is my responsibility if any data is lost.
If you don't follow the guide, and adventure on your own, there's no one to blame but yourself when **** hits the fan.
Now, let's have a look at my partitions before modifying them (kB):
Code:
Filesystem Total Used Available Use% Mounted on
mmcblk0p8 1032088 17732 1014356 2% /cache
mmcblk0p12 11901576 6355436 5546140 53% /data
mmcblk0p12 11901576 6355436 5546140 53% /sdcard
mmcblk0p10 564416 8964 555452 2% /preload
mmcblk0p9 1548144 632704 915440 41% /system
mmcblk0p3 20144 9568 10576 47% /efs
As you can see, stock paritioning is bad. /preload and /cache has a lot of available space which takes up a lot of unnecessary space.
We can minimize all the partitions and use the space to increase your internal storage, neat; let's do it!
1. Check for buggy eMMC chip
First of all we'll be checking if your chip is possible to SDS (sudden death syndrome) which basicly corrupts your eMMC (internal storage) chip.
This only effects the 16GB model, if you're on another model just skip to the flashing part.
A. Download the app eMMC Brickbug Check app from the Play Store.
B. Check eMMC
Check if your device has the following under eMMC chip:
Type: VTU00M
FwRev: 0xF1
If the values match, you should update to the latest ROM + kernel available ASAP, which should fix SDS, if you don't; your eMMC chip might corrupt under the process of flashing REPIT.
2. Flashing guide
A. Before we begin
- Make sure that you're running the latest version of TWRP (i9300, i9305). Any other recovery and the script will NOT work.
- Do NOT continue if you're running stock, or planning to do so. This script is only tested on official CM13.
- Make sure you're plugged into a power source, and not a computer; or else partitions may fail to un-mount.
- Do a backup of your rare cat images so they don't get lost in the worst scenario.
- (optional) If you want to configure the script, see this.
B. Download required tool
We'll be using ourselves with the tool REPIT made by @Lanchon.
Without it I wouldn't make this guide as it is the only(CN) flexible tool for modifying partitions in Android.
Download the required flashable zip file: [updated 2017-01-22]
- i9300 - here
- i9305 - here
Make sure you DON'T rename it; copy it to your device.
C. Boot into recovery - volume up + home button + power button when powered off
D. Flash the zip file
- This process is a really long one, do NOT interrupt the process.
- If the flashing fails, it may tell you that it copied itself to /tmp, navigate to /tmp and flash the script again.
- If x partition fails to un-mount, try un-mounting it via TWRP > Mount.
Inside TWRP navigate to Install > Navigate to saved REPIT and select > Swipe to confirm flash.
3. Done!
You may now restart your device and verify the extra utilized internal storage.
It's not that hard eh? That's because @Lanchon did a great job on his project available on GitHub. Him and I worked closely on #22 to add support for the i9300.
After re-partitioning (still kB):
Code:
Filesystem Total Used Available Use% Mounted on
mmcblk0p8 32240 4200 26404 14% /cache
mmcblk0p12 13457732 574316 12199796 4% /data
mmcblk0p12 13457732 574316 12199796 4% /sdcard
mmcblk0p10 8048 4120 3520 54% /preload
mmcblk0p9 1548144 638168 909976 41% /system
mmcblk0p3 20144 9568 10576 47% /efs
It seems like we've gained 1.5GB in local storage, hoorah! Totally didn't steal from other partitions
Worth it? (my opinion)
Unless you REALLY need that 1.5GB of extra storage; NO, not at all.
On Android 6+ (CM13) sd-cards are now implemented like normal internal storage. Just buy a 8GB micro sd-card which costs a couple of bucks these days and save yourself some trouble.
Not only that, recently a user possibly got SDS (sudden death syndrome, do your own research) after flashing REPIT. Did my own research and I updated the guide with a step to check for this buggy eMMC chip.
Credit:
- @Lanchon for REPIT.
- @forumber2 for original guide.

QnA:
The questions are kinda copied from the old guide.
Q: Why is /cache a large partition?
A: It's because stock software updates saves in the partition. The partition was extended(CN) when upgrading to Android 4.3, as the update was so large, the cache partition had to be as well. AOSP does NOT use the partition when updating.
Q: What is the /preload partition for?
A: It's only really used if you bought the phone locked. Many mobile operators put in extra apps, and bloatware too in the partition only utilized in stock firmware; and even then... There's some random Samsung crap too. REPIT minimizes the partition.
Q: Any consequences of flashing?
A: Yes, you will NOT be able to install stock firmwares (assuming that you're not running stock). A undo is easy as the script is so flexible.
You will also burn a lot of eMMC life cycles using REPIT so don't do it often, and I hope you've read 1. where I covered the buggy eMMC chip thingy.
Q: Something went wrong with flashing the zip file!
A: Please upload the REPIT log usally found in the folder where you placed the flashable zip file to dropbox, or https://paste.tinyw.in; apparently pastebin doesn't like long logs. Can also be in /tmp. Otherwise you can copy the whole TWRP log found in /tmp/recovery.log, /cache/recovery/log or /cache/recovery/last_log. NEVER copy the whole log and make a post out of it, you're spamming the thread by doing so. Issues with REPIT should NOT be reported here, instead go to the REPIT GitHub page here.
Q: I want to undo these changes!
A: Since @Lanchon is taking over this thread :laugh:, ask him. Sorry for me not doing my homework.
Q: How about the x GB model?
A: They all work, REPIT is designed to assign any leftovers to the partition we use.
More questions? Bring them on.

Reserved #2

May be it's better to give proper credits too considering it was a big mess up in past.
Sent from my "i9300/1+2" powered by Carbon/Temasek
Fueled by 7000mAh ZeroLemon Battery

nicesoni_ash said:
May be it's better to give proper credits too considering it was a big mess up in past.
Sent from my "i9300/1+2" powered by Carbon/Temasek
Fueled by 7000mAh ZeroLemon Battery
Click to expand...
Click to collapse
Woops, I made the guide in notepad++, and accedently removed some lines when editing it; including a better credit to @Lanchon; adding in a new one now.

Hawaii_Beach said:
Woops, I made the guide in notepad++, and accedently removed some lines when editing it; including a better credit to @Lanchon; adding in a new one now.
Click to expand...
Click to collapse
I meant in your op too.
Sent from my "i9300/1+2" powered by Carbon/Temasek
Fueled by 7000mAh ZeroLemon Battery

Btw, is it possible to modify this script somehow so that you can reformat the /cache partition to f2fs? Afaik the minimum size is 100mb.

Sincci said:
Btw, is it possible to modify this script somehow so that you can reformat the /cache partition to f2fs? Afaik the minimum size is 100mb.
Click to expand...
Click to collapse
No, I'm sorry. It is already known, on GitHub: #8.
The minimum size of /cache? The script sets /cache to 32240kB which is 32MB..

nicesoni_ash said:
I meant in your op too.
Click to expand...
Click to collapse
OP?

Hawaii_Beach said:
No, I'm sorry. It is already known, on GitHub: #8.
The minimum size of /cache? The script sets /cache to 32240kB which is 32MB..
Click to expand...
Click to collapse
After I read your conversation with @Lanchon on git, it seems to me that there is no need to wipe data and it will still work, it's that right?
OP - Original Post basically referred to first post.
Sent from my "i9300/1+2" powered by Carbon/Temasek
Fueled by 7000mAh ZeroLemon Battery

nicesoni_ash said:
After I read your conversation with @Lanchon on git, it seems to me that there is no need to wipe data and it will still work, it's that right?
OP - Original Post basically referred to first post.
Click to expand...
Click to collapse
Yes, you don't need to wipe /data. It just makes things faster; as you wont have to move the content around. Without wiping, it will take a longer time to re-partition.
The script will NOT wipe /data except you add +wipe to -data=max (-data=max+wipe-i9300)
OP has so many meanings, it's f***ed.

Hawaii_Beach said:
On Android 6+ (CM13) sd-cards are now implemented like normal internal storage. Just buy a 8GB micro sd-card which basicly costs a couple of bucks and save yourself some trouble.
Click to expand...
Click to collapse
hi, thanks for the guide!
actually, the external sdcard will always be slower than the internal eMMC. also, the extra free space gets auto-TRIMmed in /data, making the whole eMMC (and thus your phone) faster. also, adopted storage diminishes the total reliability of your phone and data (more devices can fail).
in all, i'd recommend anybody with less than 2 or 3GB free space in /data to REPIT; it's safe and easy.
---------- Post added at 05:35 PM ---------- Previous post was at 05:22 PM ----------
Sincci said:
Btw, is it possible to modify this script somehow so that you can reformat the /cache partition to f2fs? Afaik the minimum size is 100mb.
Click to expand...
Click to collapse
REPIT does not support f2fs for now.
(future support will not include wipe without resizing, as f2fs does not support that yet.)
but you can get what you want anyway:
"-cache=0.03125+wipe"
actually means
"-cache=0.03125+wipe+ext4"
given that ext4 is the default FS for "cache".
"wipe" means format, and never mind what was there before. even if it was something that wasn't ext4 at all, it will succeed.
so you can use:
"-cache=0.0976+wipe"
to get exactly 100MiB-sized cache (in ext4)
then, afterwards, use TWRP to format cache in F2FS
and you'd get what you want.
but...
DON'T!!!
dont use F2FS in ANY partition besides /data! it makes NO sense!
F2FS has an overhead of about 100MB, so basically you would be creating a /cache that is unable to hold any files at all. (ext4 has 5MB overhead.)
and why have a dysfunctional /cache? what for? to have problems? incompatibilities?
certainly not performance, because cache is NEVER used in android. so why do it?
it's soft of a crazy fad, like /system in f2fs.
/system, the one partition we never write to, lol
---------- Post added at 05:39 PM ---------- Previous post was at 05:35 PM ----------
nicesoni_ash said:
May be it's better to give proper credits too considering it was a big mess up in past.
Sent from my "i9300/1+2" powered by Carbon/Temasek
Fueled by 7000mAh ZeroLemon Battery
Click to expand...
Click to collapse
thanks!
no credit required!!! the GPL allows him to do as he pleases, as long as he doesn't remove the license or claims copyright.
but anyway, thanks for the credit appreciated!
and thanks for invaluable help to port to i9300!!
---------- Post added at 05:43 PM ---------- Previous post was at 05:39 PM ----------
btw, i should start thanking the people who helped with the ports in the comments of the device port file. so far 2. i will back-credit when i get the time.
and i9305 and others are probably trivially supported, i just need the dumps done.

Lanchon said:
really long stuff going on
Click to expand...
Click to collapse
The thing is that not only could REPIT be ported to i9300, but any other Samsung device, right? They all run TouchWiz; for example s4, s5, s6? Have anyone even checked partitions on those devices?
The thing with partitions and the Android community is that almost no one discusses it. If you do a google on partitions on Android; very Little information / threads exist.

Lanchon said:
hi, thanks for the guide!
actually, the external sdcard will always be slower than the internal eMMC. also, the extra free space gets auto-TRIMmed in /data, making the whole eMMC (and thus your phone) faster. also, adopted storage diminishes the total reliability of your phone and data (more devices can fail).
in all, i'd recommend anybody with less than 2 or 3GB free space in /data to REPIT; it's safe and easy
Click to expand...
Click to collapse
To be honest, I never cared about storage speed (same goes for trim), not a heavy user on my phone, and have never been, just doesn't go well when I'm the operator. As long as it doesn't take 1 year to copy my secret .mp4's (ransom.mp4 and many more), there's no worries.
About failure, it's like running a computer. If you shut down a computer without sending signals (unplug from wall etc), it may damage the harddrive; right? Same here. Right?
Any how, If I ever run out of space on my i9300, I'd just add a sd-card. I don't save anything important on my device that doesn't get backed up via TWRP. But..
that's never going to happen! Because my OnePlus One is coming back from RMA service! (finally after 4 months (not kidding)). kinda off topic, but hey; it's my thread right :good:

Hawaii_Beach said:
The thing is that not only could REPIT be ported to i9300, but any other Samsung device, right? They all run TouchWiz; for example s4, s5, s6? Have anyone even checked partitions on those devices?
The thing with partitions and the Android community is that almost no one discusses it. If you do a google on partitions on Android; very Little information / threads exist.
Click to expand...
Click to collapse
lol about the quote
besides the name playing on samsung's PIT files, REPIT can actually work on any device with TWRP support. but the partition layout in most newer devices is friendly enough not to bother. even the stock i9300 layout is sort of friendly. highly problematic are only the devices that shipped before ICS with android 2.x (galaxy S2) or devices that shipped with non-emulated internal sdcard.
discussion is low volume because partitioning is considered 'dangerous'. and it can be, you can brick if you mess up. the idea of REPIT was to make it safe by encapsulating a bit of knowledge of each device in the device port file. motivation was that S2 users suddenly all needed to repit: their devices stopped working after a nightly flash because of /system being too small, it was a mess, lol.
btw, since you asked before, that's the reason why porting is needed: because you can't trust users not to make mistakes with full freedom. users that want full freedom have other tools: gdisk, parted, mkfs.xxx, resize2fs, etc.

Lanchon said:
lol ab...
Click to expand...
Click to collapse
Yeah, I know that other devices doesn't even need to touch the partitions, as it is a waste of time. (so is this??)
edit: still, maybe I want a extra 1.5gb on my s6 Active or whatever.
edit: by for today, it's 00:00 here..
discussion is low volume because partitioning is considered 'dangerous'. and it can be, you can brick if you mess up. the idea of REPIT was to make it safe by encapsulating a bit of knowledge of each device in the device port file. motivation was that S2 users suddenly all needed to repit: their devices stopped working after a nightly flash because of /system being too small, it was a mess, lol.
Click to expand...
Click to collapse
Dangerous!? I've seen way more people fu** their IMEI number (including ME on MINE i9300) by doing something dumb to the /efs content (totally didn't try to unlock the phone), that's dangerous. (got 0049)
The phone was just lying round until I got around to fix it, not going to get into details as XDA doesn't allow this stuff. It was really fustrating as people said that reflashing stock would get back the IMEI (should apparantly work, etc etc).
yet again side tracked, but i'm the operator right? :good: :highfive:

@Lanchon
Since we are talking abt partitions, I would like to ask a question that's not related to this tool but the other way mentioned in first post by flashing a zip file with manually entering the size in script file.
I tried that a while back on my s3 and it worked great. I was on kitkat that time and it was fine till lollipop came. So I flashed lollipop but since the system size was only about 500mb, it failed to flash so I made another zip with system size to 800mb and flashed it again. Although everything went fine but after flashing a new rom or restoring my old backup phone always showed some encryption error and asked to factory reset and even after doing that, still showed the same error even though I never encrypted anything. So the only option was to flash stock with pit file and change the partitions to stock size and then restore or flash a new rom.
I was never able to partition my phone after that coz that error always came back. I have op2 now so all molding goes on it and s3 is like a backup phone but I am still interested to know what was that all about and what could I do to fix that or whether my emmc worn out?
Sent from my "i9300/1+2" powered by Carbon/Temasek
Fueled by 7000mAh ZeroLemon Battery

Hawaii_Beach said:
Dangerous!? I've seen way more people fu** their IMEI number (including ME on MINE i9300) by doing something dumb to the /efs content (totally didn't try to unlock the phone), that's dangerous. (got 0049)
The phone was just lying round until I got around to fix it, not going to get into details as XDA doesn't allow this stuff. It was really fustrating as people said that reflashing stock would get back the IMEI (should apparantly work, etc etc).
yet again side tracked, but i'm the operator right? :good: :highfive:
Click to expand...
Click to collapse
well... effing the bootloader i way worse than borking /efs, believe me.
now, trying to hack /efs WITHOUT A BACKUP (!!) is big jesus f*cking christ sh*t u talking lol!!!

Lanchon said:
well... effing the bootloader i way worse than borking /efs, believe me.
now, trying to hack /efs WITHOUT A BACKUP (!!) is big jesus f*cking christ sh*t u talking lol!!!
Click to expand...
Click to collapse
Hahahaha yep. Didn't know the risk dude.

nicesoni_ash said:
@Lanchon
Since we are talking abt partitions, I would like to ask a question that's not related to this tool but the other way mentioned in first post by flashing a zip file with manually entering the size in script file.
I tried that a while back on my s3 and it worked great. I was on kitkat that time and it was fine till lollipop came. So I flashed lollipop but since the system size was only about 500mb, it failed to flash so I made another zip with system size to 800mb and flashed it again. Although everything went fine but after flashing a new rom or restoring my old backup phone always showed some encryption error and asked to factory reset and even after doing that, still showed the same error even though I never encrypted anything. So the only option was to flash stock with pit file and change the partitions to stock size and then restore or flash a new rom.
I was never able to partition my phone after that coz that error always came back. I have op2 now so all molding goes on it and s3 is like a backup phone but I am still interested to know what was that all about and what could I do to fix that or whether my emmc worn out?
Sent from my "i9300/1+2" powered by Carbon/Temasek
Fueled by 7000mAh ZeroLemon Battery
Click to expand...
Click to collapse
well i cannot answer about scripts and procedures unknown to me but...
an encrypted disk typically is made of 2 things:
-the encrypted disk 'surface' or area (ie: the data)
-and metadata (data describing the data, ie: data describing the encrypted disk)
metadata typically contains:
-cipher info
-and the disk surface encryption key (generated at random), itself encrypted with the access key (such as a passphrase).
why the indirect key? without it:
-changing the passphrase (say, your phone lock pattern) would be a very dangerous operation that would require reading, reencrypting and writing the complete disk, would take a huge amount of time and would drain your battery completely
-erasing the disk would similarly take a long time.
with it:
-when changing the passphrase you just need to reencrypt the surface key with the new passphrase and rewrite the metadata.
-when erasing, just wipe the metadata.
for example the metadata in recent android phones with hardware backing store for keys probably contains:
-cipher info
-and the disk surface encryption key (generated at random), itself encrypted with a secondary key (also random).
the secondary key lives in the hardware keystore. it's generated there and can never leave that processor. the keystore will decrypt the surface key during boot, only if the main processor informs the right passphrase (say, the PIN or pattern). a 4-digit PIN would be very easy to bruteforce, except that the keystore throttles down guesses, and can even wipe the key (rendering the disk forever unreadable) after so many bad guesses.
the keystore should be tamper-proof: a silly small processor, but resistant to voltage spike attacks, rays, etc and decapping to read the storage, to pick up signals in traces, to inject signals in traces, to chip modifications, etc. think of it as the chip in any recent credit card or even some sim cards, but on the main circuit board.
anyway back to metadata in android: it needs to be stored somewhere. the obvious place is an ultra small metadata partition containing just the raw metadata, no file system or anything of the like. this is simple and works great, except for one detail: older phones don't have this partition. basically this means that an android upgrade couldn't give you encryption.
so android can use a "crypto footer": with this scheme the encryptable partition (say /data) has a file system that is 16KiByte short of filling the actual partition, and the 16KiB footer follows. the footer is the metadata.
when you repartitioned before, you probably created a file system that used the complete partition area. there was no space left for the footer, so encryption couldn't be enabled.
you could have solved your issue today by flashing repit with all-default parameters: repit always resizes the encryptable partition's file system to make room for the footer, if not already there.
in REPIT, these commits add general and ext4-particular support for crypto footers:
https://github.com/Lanchon/REPIT/commit/591961adb180a6a03594053a846b698240b4d507
https://github.com/Lanchon/REPIT/commit/de3d3af9813afef7de3a798ce5314c0fb210e30f
https://github.com/Lanchon/REPIT/commit/5c3360b572ff25c7c01d796cabb9400066451ec3
this configures the footer on the i9300:
https://github.com/Lanchon/REPIT/blob/f46b0aafdfeb7860be17a315b4aceb43966325f9/device/i9300.sh#L85