Related
I'm no expert when it comes to the topics of rooting and getting access to the emmc and all of that good stuff. I more specialize in ROMs and themes and stuff, the less complexed stuff lol
Someone has posted an idea in the general forums in relation to permanent root, I'm not sure if he posted it here or not. So here's what he wrote....and is it possible? Or does it have to be done manually first before this idea can happen?
Originally Posted by deliberate187
In order to unlock the phone, we have to figure out what the protected sectors are first and all related flags. If an Android app could be made to have direct read access to the eMMC filesystems (including write protect flags) and save a log to the SD card detailing these items, this would be ideal.
Then all that would remain is a program to undo the write protection (and re-do it if necessary to unvoid warranty)
If anyone is willing to create these programs, I would be more than happy to test them out on my own G2.
However, I think the keys to the mystery may lie in the recovery image, and/or in the bootloader itself. Has anyone disassembled these yet?
Click to expand...
Click to collapse
Sorry to have to tell you but this is all old information stuff we already know just are unable to do anything about it. Its harder then just coming up with an idea of something. Now if we knew a person that programed the g2 in htc factory then all would be good but as of now we just dont have the information we need to do anything
thanks
Thanks for the idea. Some people will be mad you didn't post in the root thread though.
File under "I'm no expert but..."
Here is one observation I have noted in my exploration. The root filesystem and system partition are mounted with the flags "-o ro,relatime" but in addition the /system partition has ",errors=continue" leading me to believe that this change is in fact written to the release configuration rather than to the eMMC itself. Can anyone try to get a permanent write to the fstab and see if this can net us permanent root? Possibly take a temp root session and remount the system and / filesystems read/write to see if writes stick... just an idea.
The errors=continue flag allows the ext3 filesystem to continue working even if there was a read/write error.
I've been able to get the system to change to r/w a couple times while wandering through root explorer. I have made subtle changes to certain folders such as moving txt files but nothing has ever been permanent. I can't really tell you how I did it either seeing as I can't replicate it on demand...I'm assuming it still gets written to cache despite being in the /system
Sent from my T-Mobile G2 using XDA App
heyy, I'm not punchie, I've got what the doctor calls a relaxed brain
I am thinking there should be a set of adb commands to unlock the nand. I am definitely thinking a nand dump and full disassembly of the bootloader and recovery image could be absolutely crucial in discovering what needs to be done. Just a thought, has anyone done a nandroid backup of the G2 yet? I'm pretty sure TMob doesn't have HTC encrypt its bootloaders...
deliberate187 said:
I am thinking there should be a set of adb commands to unlock the nand. I am definitely thinking a nand dump and full disassembly of the bootloader and recovery image could be absolutely crucial in discovering what needs to be done. Just a thought, has anyone done a nandroid backup of the G2 yet? I'm pretty sure TMob doesn't have HTC encrypt its bootloaders...
Click to expand...
Click to collapse
if you can figure it out, go for it and i wish you luck
deliberate187 said:
Here is one observation I have noted in my exploration. The root filesystem and system partition are mounted with the flags "-o ro,relatime" but in addition the /system partition has ",errors=continue" leading me to believe that this change is in fact written to the release configuration rather than to the eMMC itself. Can anyone try to get a permanent write to the fstab and see if this can net us permanent root? Possibly take a temp root session and remount the system and / filesystems read/write to see if writes stick... just an idea.
The errors=continue flag allows the ext3 filesystem to continue working even if there was a read/write error.
Click to expand...
Click to collapse
If it were only this easy.
Re-mounting /system as r/w is part of the rooting process. This does not result in changes written to eMMC. In fact, the controller "lies" to Linux that the change has been synced. From then on, Linux holds the changes in its cache which, when dropped or rebooted, reverts changed files to their original state (because they were never written in the first place.)
The ext3 continue on errors thing is merely a way to skip fsck in the event that the read-only system has issues in the journal (very unlikely to happen, since nothing can write to it.) Presumably, this only covers an oversight in OTA updates (where the journal of the image provided by the OEM is dirty for some odd reason.) Again, since nothing can write to /system, it's all but an impossible scenario (nothing can write to the journal either...)
As for marking "sectors" as write-protected or not, that's also easier said than done. Entire partitions are locked, and half of the space is mysteriously "missing." It's difficult to see what's really going on from userland, as the device is deceptive as to what is and is not being written, or what is even stored on the eMMC in the first place.
The real solution is to exploit either the boot-loader or eMMC (re)/initialization somehow to allow a) unsigned firmware to be loaded and/or b) allow booting without write protection, allowing us to c) flash rooted rom to the phone and/or d) disable said protection. The unlock procedure will likely be similar to Unrevoked, as that is essentially the same situation (aside from the controller issue.)
All of this is covered in the wiki and various threads - check those out, if you find a way around it everyone would be glad to hear it.
HamNCheese said:
If it were only this easy.
Re-mounting /system as r/w is part of the rooting process. This does not result in changes written to eMMC. In fact, the controller "lies" to Linux that the change has been synced. From then on, Linux holds the changes in its cache which, when dropped or rebooted, reverts changed files to their original state (because they were never written in the first place.)
The ext3 continue on errors thing is merely a way to skip fsck in the event that the read-only system has issues in the journal (very unlikely to happen, since nothing can write to it.) Presumably, this only covers an oversight in OTA updates (where the journal of the image provided by the OEM is dirty for some odd reason.) Again, since nothing can write to /system, it's all but an impossible scenario (nothing can write to the journal either...)
As for marking "sectors" as write-protected or not, that's also easier said than done. Entire partitions are locked, and half of the space is mysteriously "missing." It's difficult to see what's really going on from userland, as the device is deceptive as to what is and is not being written, or what is even stored on the eMMC in the first place.
The real solution is to exploit either the boot-loader or eMMC (re)/initialization somehow to allow a) unsigned firmware to be loaded and/or b) allow booting without write protection, allowing us to c) flash rooted rom to the phone and/or d) disable said protection. The unlock procedure will likely be similar to Unrevoked, as that is essentially the same situation (aside from the controller issue.)
All of this is covered in the wiki and various threads - check those out, if you find a way around it everyone would be glad to hear it.
Click to expand...
Click to collapse
Listen to this dude. Absolutely correct.
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:
In case that someone missed it
(tnx to user garwynn)
Fresh off the press...
Q: Do you know the commands to reset the eMMC controller in question?
Originally Posted by Ken Sumrall (Android)
Once the chip has locked up, no command will reset it. It must be power cycled. If instead you are asking how to clear the metadata so the chip works again, the only solution I know is to update the firmware inside the chip, and that also wipes all the data. This probably includes factory calibration data that must be saved before the firmware is updated, and restored after. Also, the boot loader is probably in the chip, and must be restored after the firmware update, or the device will be bricked. This is a dangerous operation, because if something goes wrong, the device will probably be bricked. (emphasis added)
Q: Is there any documentation available on this issue? If so and it is private is it possible to have it released?
Originally Posted by Ken Sumrall (Android)
It is private, I'm asking if I can release it, along with the code to update the emmc firmware. Don't get your hopes up, my guess is the answer will be no.
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.
Q: Difference between GB/ICS Wipe
Originally Posted by Ken Sumrall (Android)
IIRC, when using recovery to wipe the phone on GB, the make_ext4fs() library would not issue an erase command first, it would just write one a new blank filesystem. This, of course, doesn't really erase all the private data of the user, so we changed make_ext4fs() to first erase the partition, then write out the new filesystem. You can see the code in system/extras/ext4_utils/wipe.c, which didn't exist in gingerbread, but does in honeycomb and later. It is the erase operation on the rev 0x19 firmware that can cause the emmc chip to lockup. (emphasis added)
Regarding Entropy512's summary of observations:
Originally Posted by Ken Sumrall (Android)
Regarding the notes on MMC_CAP_ERASE, the just lists the cards ability to perform the erase command. In other words, if the mmc_erase() function works. What is more important is if anyone calls the mmc_erase() function. Looking at the mmc driver, in drivers/card/block.c, it is only called when a secure discard or discard request is made. As far as I know, those requests are only sent if the filesystem is mounted with the "discard" option, or if userspace code does an ioctl() to erase a partition, like make_ext4fs does. So check the mount options on the filesystems. *If they don't specify "discard", the erase operations are probably not happening.
Of course, a simple debugging printk() in the mmc_erase() function will tell you if anyone is calling it.
Additional info not directly related to questions:
Originally Posted by Ken Sumrall (Android)
The lockup doesn't happen immediately after power-on. The chip doesn't lock up until a sector is referenced that has corrupted wear leveling data inside the chip. Once that sector is referenced, the chip will lockup hard, and the only thing that will get it talking again is to power cycle it. Once it is power cycled, the chip will talk again, until that bogus sector is accessed.
http://forum.xda-developers.com/showpost.php?p=26521643&postcount=293
So, absolutely no CWM wipe for Note, until we got a solution? Maybe change custom ROM CWM wipe as write zeros or delete all files instead of file system format?
It just seems crazy that Samsung/Google cannot release a small file to flash that would fix this problem. I'm sure they could if they really wanted to.
I am asking Samsung Singapore about the eMMC bug on their facebook page. Hope to get some info on whether the bug is proliferating across region ICS versions or have they actually silently fixed it.
for what the note is worth and they sold millions it should be fixed now this is putting me off getting another samsung ,which i really do like them it feels like they have let us down
It is not just the Note, it is all Eyxnos based Samsung phones including the GSII. I could be wrong, but I think they sold a few of those...
It is not just CWM wipe that is the problem. You can brick performing a factory reset on official XXLPY (and all official ICS kernels so far... and all leak ICS kernels). The only safe kernels are those based on GT-I9100 Update4 source code release - this includes XplodWILD's CM9 release (and it's derivatives such as Asylum, Paranoid, MIUI) and Entropy's DAFUQ and that other WizDom kernel with more to come now that there is source available.
FYI, the N7000 source even has the MMC_CAP_ERASE bug. Just look at Franko's kernel thread.
Global recall lmao
Sent from my GT-N7000 using Tapatalk 2
nickshertzer said:
It is not just the Note, it is all Eyxnos based Samsung phones including the GSII. I could be wrong, but I think they sold a few of those...
It is not just CWM wipe that is the problem. You can brick performing a factory reset on official XXLPY (and all official ICS kernels so far... and all leak ICS kernels). The only safe kernels are those based on GT-I9100 Update4 source code release - this includes XplodWILD's CM9 release (and it's derivatives such as Asylum, Paranoid, MIUI) and Entropy's DAFUQ and that other WizDom kernel with more to come now that there is source available.
FYI, the N7000 source even has the MMC_CAP_ERASE bug. Just look at Franko's kernel thread.
Click to expand...
Click to collapse
And the devs on here, now that they have a source, will eventually remove that MMC_CAP_ERASE code from the kernel. Just give them some time. If Samsung won't do anything, then we at XDA will make the best of what we can. And I say Samsung and not Google because the ball really is in Samsung's court, not Google's.
wasnt this published a little while ago on the portal?
panyan said:
wasnt this published a little while ago on the portal?
Click to expand...
Click to collapse
Yes, it was.
So that makes sense FINALLY. GB never did a true wipe, sorta like a soft format pc. Can we just modify the ics kernels to mmc_erase() as how gb runs it and get rid of the new code? This is a temporary work around.
PoisonWolf said:
Can we just modify the ics kernels to mmc_erase() as how gb runs it and get rid of the new code? This is a temporary work around.
Click to expand...
Click to collapse
that was my exact thoughts too as i was reading it -> just do a quick wipe and not full erase
panyan said:
that was my exact thoughts too as i was reading it -> just do a quick wipe and not full erase
Click to expand...
Click to collapse
Yeah, like how Ken talked about Honeycomb and forward having wipe.c, let's just get rid of that nonsense.
I dont know how it works, but if you're on Gingerbread, and you encrypt your phone, and you do a full-wipe in CWM, can a person still access the data? I mean, we now know that they could with the right tools since the information is still on the chip, just not easily accessible. But if it is encrypted, can it be decrypted and accessed? I guess what's the encrypting algorithm and is it the same for all devices?
If the information cannot be accessed if it is encrypted, then paranoid folks shouldn't have to worry with soft wipes.
Can anyone confirm that a 32 GB Note shipped with the same 0x19 firmware on the emmc?
Markuzy said:
I am asking Samsung Singapore about the eMMC bug on their facebook page. Hope to get some info on whether the bug is proliferating across region ICS versions or have they actually silently fixed it.
Click to expand...
Click to collapse
Well don't hold your breath that would mean that Samsung has made a BIG mistake in their's firmware's and that would produce lots of anger and sales drop.
I think IF they decide that they will eventually fix this it would be in big quiet and just like part of "new" firmware like 4.0.4 etc
panyan said:
wasnt this published a little while ago on the portal?
Click to expand...
Click to collapse
andreww88 said:
Yes, it was.
Click to expand...
Click to collapse
Where? This was written yesterday so i don't know what is exactly "little while ago" ?
Additional info not directly related to questions:
Originally Posted by Ken Sumrall (Android)
The lockup doesn't happen immediately after power-on. The chip doesn't lock up until a sector is referenced that has corrupted wear leveling data inside the chip. Once that sector is referenced, the chip will lockup hard, and the only thing that will get it talking again is to power cycle it. Once it is power cycled, the chip will talk again, until that bogus sector is accessed.
Click to expand...
Click to collapse
This concerns me the most. Is there any way to "test" all sectors of the phone's emmc to see if we have the bogus sector?
Like a terminal command to create a file of X size so you could "fill" up the entire phone with a bogus file. Could this work?
PoisonWolf said:
This concerns me the most. Is there any way to "test" all sectors of the phone's emmc to see if we have the bogus sector?
Like a terminal command to create a file of X size so you could "fill" up the entire phone with a bogus file. Could this work?
Click to expand...
Click to collapse
Yes that would be very useful, to actually check if our phones are already damaged ...
Hm, makes me wonder about some peoples SODs
GocaS6 said:
Where? This was written yesterday so i don't know what is exactly "little while ago" ?
Click to expand...
Click to collapse
http://www.xda-developers.com/android/hard-brick-bug-on-galaxy-s-ii-and-note-leaked-ics-kernels/
panyan said:
http://www.xda-developers.com/android/hard-brick-bug-on-galaxy-s-ii-and-note-leaked-ics-kernels/
Click to expand...
Click to collapse
If you read it carefully you'll notice that this is not same conversation
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.
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