Well, I have been going through many tab owner problems on this forum who have tried everything on the book to get their tab back running. this experimental process is only for those people who have no option left than to throw away their tab as a dead glorious paperweight or play with it as a Frisbee. hopefully it can recover or at least it can open a new way for getting out of a brick or perhaps be a good learning experience, just for the sake of it. what else would you want to do? if your device is un-repairable? at least this can take a backup for the complete device in a different way though.
So what really is this about?
Well, Samsung tab 2 emmc is pretty much notoriously getting scarier, either it is happening because of flashing a wrong kernel or doing wrong with your tab, or in some cases where people had no clue. A sudden attack and the tab was dead. you may be lucky to get a replacement and get the tab running up again. but not all could be solved and resolved.
but what if we provide the tab a second emmc(your external card emulated and working as an exact image of the internal emmc with all the system files with their partition on it?) sounds good eh? there are 2 sides of this coin. one, our device is not made that way and it's definitely not going to work at all, second, it can work after a little hardware modification provided you have the right files and right tools and a insanely expert brain. Now the chances of this working is like that of flipped coin landing on it's edges. very tricky.
But how we can achieve this then?
Well, there are users on the internet that have some sort of success in this, while it wasn't guaranteed for their device, that this process can work for all and there is definitely nothing like this sort ever found for our device. which is on omap chipset, it's the debrick method. you can't tell unless you are from the development department of Samsung. So, I would say even if it's 0.0000000001 percent of having a chance to work for us. I would like to keep it.
Debrick.img? what does it do? how to get it?
Well, this file is generally taken out from a stock rom from location /dev/block/mmcblk0 which is where pit stores the data for all the partition and from there we can extract all the important parts, including the boot-loader, recovery, cache, hidden, sbl1, sbl2, factoryfs param, modem, EFS, DataEFS to a .img file. (as far as my definition goes for better understanding). please feel free to go through all the post that you can find about the debrick, or if you have more knowledge please share.
I was just going through these posts.
The whole process for sg s3 http://forum.xda-developers.com/showthread.php?t=2660566
http://forum.xda-developers.com/showthread.php?t=1818321 a guide that explains about taking backup of the entire memory block with all partitions or single partition. it's quite old but informative.
fixing a bootloader
http://forum.xda-developers.com/showthread.php?t=2345860
there are different parts to it, first is getting the bootloader written on a external sd card. but we still don't know if our device will be able to treat the external sd card as an internal emmc. it is yet to be found out.
my theory is suppose if we can get out the whole partition along with system written on a external card, can we make the device treat it as a internal emmc? will it then be possible to revive a dead internal emmc tab? there are chances it might. still no practical though and no guarantees for sure.
but it makes you feel better, I managed to get out those partition on a .img file which could be written on a external card as well. basically an image of your emmc. this might be a good backup too for those who would like to be safe in case a emmc bug hits them too.
Now, To get this data we need volunteers to take these files from their working rooted stock rom and upload these files for every model of samsung tab, if they wish to contribute to our community, you are welcome. or at least keep it safe on their disks. although, this process will require atmost care as we are dealing with bootloaders here, and one wrong bootloder and it
won't work, as much as my knowledge goes, there are two- the ics and jb for our tab 2. still there are many other variants and I really have no clue, how to work this out all by myself. so, I would like other great minds share their wisdom upon this and please before sharing files, mention everything you can, right from your
1. Device model number
2. 8gb or 16gb
3. Bootloader(ics or jb)
4. Stock rom, custom rom,
5. firmware
6. Baseband
7. Country and to your name.
Now before pulling out this file, I have a doubt, as I have got few imgs option. there is 128mb, 200mb, 256mb, 512mb and also I have got one img of around 2.17gb as well which is the complete backup I could take out from my device.
I am not sure which one to choose that's going to work. people have mostly used 128mb file to get access to the download mode, I guess in that 128mb, there is enough files needed to boot your device into download mode and recover from hard bricks, but there is no evidence as for now in our device section as to which is suffient for us. So for first try, we take 128mb, and keep doubt aside for one process.
but suppose it's our emmc bug and we want to use the external as a image of the damaged internal, in that case I suppose we need to take out the whole info! is it really possible with the 2.17gb of my device complete data? ah, I would really like to know about the answer myself, in case it hits my device, I would be prepared myself
anyways to try this you must have a sd card reader and use a external card of 16gb or 8gb depending upon your device variant (card class 10 required, on others it has high chance of not working at all)
Now the process to extract the file
The script that you need to enter into terminal emulator(download one from playstore) this will backup a 128mb file on your sdcard.
Code:
#su
#busybox dd if=/dev/block/mmcblk0 of=/sdcard/debrick.img bs=1M count=128
128MB is arbitrary. on some devices 70MB was sufficient, on our device? maybe or maybe not. please test or help me answer this correctly, if I'm wrong. but untill then, use 128mb, if we fail, we will look for other options.
other dd commands
Code:
1. dd if=/dev/block/mmcblk0 of=/sdcard/backup.img
backup whole partitons thus will be large size and takes more time.
Code:
2. dd if=/dev/block/mmcblk0 of=/sdcard/debrick.img bs=1M count=70
70mb data from mmcblk0 will be copied to sd card
Code:
3 dd if=/dev/block/mmcblk0 of=/sdcard/debrick.img bs=1M count=512
512mb data from mmcblk0 will be copied to sd card
Code:
4. dd if=/dev/block/mmcblk0 of=/sdcard/backup.img bs=4096
large size more than 4GB and more time consuming
Procedure
1. Connect the external sd card to the card reader move all the files to your pc and format it.
2. find the correct debrick.img image from post 2.
3. Download and extract this software win iso burner
4. Open the software win32diskimager.exe and browse the debrick.img
5. Successfully Write the debrick.img onto it.
6. Put the sdcard in your device
7. Pray, or do the cha cha, praise the droid lord.
8. switch it on or press power button + volume down/up, whatever you can.
9. if you can then get into download mode, you can try to flash stock firmware or dance your way around.
10. report us back what happened.
1. Download Debrick dump imgs. (128mb)
Samsung tab 2 10.1 P5100 16gb
jellybean boot-loader.
was on custom 5.1 rom and twrp recovery from UAE firmware.
Samsung Tab 2 P3100 16gb
shared by @jak978 on post 6 Hit thanks for him.
more will come, when people will share.
for other guides and ways
interesting, unfortunately my broken emmc have replaced with eemc from note 2, tho mine is p3100
jak978 said:
interesting, unfortunately my broken emmc have replaced with eemc from note 2, tho mine is p3100
Click to expand...
Click to collapse
So, you're one of those lucky ones. Getting a replacement is still the best way. So, do you think my theory here could work? Anyways it would be an interesting answer to find out. But people would need to share files here first for any samsung tab 2 model. I hope it becomes helpful rather than just interesting.
billysam said:
So, you're one of those lucky ones. Getting a replacement is still the best way. So, do you think my theory here could work? Anyways it would be an interesting answer to find out. But people would need to share files here first for any samsung tab 2 model. I hope it becomes helpful rather than just interesting.
Click to expand...
Click to collapse
here you go tab2 P3100 16GB
Anybody having any luck with this procedure??
Rag888 said:
Anybody having any luck with this procedure??
Click to expand...
Click to collapse
Well I still haven't faced the emmc bug, so can't really test on my device yet. nobody else who faced this issue had tried this and posted or shared any of the findings here.
Updating the emmc firmware via. ISP gives back life to >80% of affected devices.
16 GB Tab 2 have a known faulty EMMC (MAG2GA). It can happen, that your EMMC get "read only", so you can't perform any write actions (also you can't format) anymore.
From the EMMC data sheet:
5.1.7 End of Life Management:
The end of device life time is defined when there is no more available reserved block for bad block management in the device. When the device reaches to end of its life time, device shall change its state to permanent write protection state. In this case, write operation is not allowed any more but read operation are still allowed.
But, reliability of the operation can not be guaranteed after end of life.
Click to expand...
Click to collapse
On a faulty EMMC firmware it happens a lot faster if the emmc reaches a wrong value.
Sadly Patching the emmc fw isn't possible running the device, at least there's no known kernel on chip power-on Method...
Those from europe can contact @html6405 , he is able to update the emmc firmware and he can also replace the emmc if needed.
Note:
Sharing a whole copy if mmcblk0 isn't good, because it will include efs partition which is sensible data.
~ All my work, news etc. on http://andi34.github.io ~
Found something interesting printing the pit using heimdall:
https://paste.omnirom.org/view/4173cc20
Someone knows what the GANG partition is for?
I wonder if it is the emmc firmware because emmc.bin is stored there...
I am waiting to get the fixed emmc firmware, i might be able to tell you once i have it.
~ All my work, news etc. on http://andi34.github.io ~
Android-Andi said:
Note:
Sharing a whole copy if mmcblk0 isn't good, because it will include efs partition which is sensible data.
Click to expand...
Click to collapse
Yes, better to keep them private. Users do not share, just keep a backup with yourself.
thanks for your thorough research.
Android-Andi said:
Found something interesting printing the pit using heimdall:
https://paste.omnirom.org/view/4173cc20
Someone knows what the GANG partition is for?
I wonder if it is the emmc firmware because emmc.bin is stored there...
Click to expand...
Click to collapse
I did notice the GANG partition since you mentioned it(strange I never realized this before as I have looked at the pit file many times earlier as well.) located at 0x64C.
it does look like the emmc firmware partition. what else it should have?
jak978 said:
interesting, unfortunately my broken emmc have replaced with eemc from note 2, tho mine is p3100
Click to expand...
Click to collapse
hi jak978,
i plan to replace my p3100 emmc with p5100 emmc, can i just flash p3100 firmware using odin after change the emmc?
some more, can u re upload the debrick dump for p3100, it says "file not found" in your link.
regards,
alms
here you go tab2 P3100 16GB UNABLE TO GOT FILE PLEASE SHARE THE FILE PLEASE
---------- Post added at 12:56 PM ---------- Previous post was at 12:49 PM ----------
billysam said:
1. Download debrick dump imgs. (128mb)
samsung tab 2 10.1 p5100 16gb
jellybean boot-loader.
Was on custom 5.1 rom and twrp recovery from uae firmware.
samsung tab 2 p3100 16gb
shared by @jak978 on post 6 hit thanks for him.
More will come, when people will share.
Click to expand...
Click to collapse
please re share p3100 file i need it my tab was not work or trell me any way to get emmc chip from online or else process
my tab only in condition on restart restart.....
No recovery and firmware ll able to write on p3100
please help your reply too much helpful for me please give file p3100 so i can use your method
asiffrluv said:
here you go tab2 P3100 16GB UNABLE TO GOT FILE PLEASE SHARE THE FILE PLEASE
---------- Post added at 12:56 PM ---------- Previous post was at 12:49 PM ----------
please re share p3100 file i need it my tab was not work or trell me any way to get emmc chip from online or else process
my tab only in condition on restart restart.....
No recovery and firmware ll able to write on p3100
please help your reply too much helpful for me please give file p3100 so i can use your method
Click to expand...
Click to collapse
Look at this on eBay http://www.ebay.com/itm/192025936615
Sent from my SAMSUNG-SM-G870A using XDA Free mobile app
Hi,
I just tried this method. The tab boot on the sdcard, i have the charging logo displayed, and then screen turns black. The driver change from omap4430 to Android, and keep this driver until i unplug the usb cable.
On linux, the tab device is recognized as Android. Same on windows (loaded in virtualbox from linux).
adb device display an unauthorized device.
So from this step, it is still impossible to flash the tab.
Anyway thanks for sharing this; even if its painfull to lose a tab, it is nice to learn how all this work.
if other people have more information to share, i would appreciate any new info on this subject
billysam said:
1. Download Debrick dump imgs. (128mb)
Samsung tab 2 10.1 P5100 16gb
jellybean boot-loader.
was on custom 5.1 rom and twrp recovery from UAE firmware.
Samsung Tab 2 P3100 16gb
shared by @jak978 on post 6 Hit thanks for him.
more will come, when people will share.
Click to expand...
Click to collapse
Links are dead can you update them?
@Android-Andi @billysam @jak978
Sorry for pinging do you still have the p3100 debrick img?
No, never had it.
Ugh dev host dosent work in 2020
Still waiting for the link
Related
----------- FIXED ----------
Hey guys,
I'm encountering a terrible problem with my P6810 tab. Here is the story :
At first, I just did format /system/ (and /data/, cache and dalvik) in CWM before flashing a new Rom.
After reboot, the tab just got stuck on the "Galaxy Tab 7.7" logo. no bootloop, just stuck on static logo.
At this stage i could go to download mode and recovery, which I did.
I tried to reflash the rom, no success so then i tried to flash stock ICS firmware through Odin 1.85 : Stuck on flashing Factoryfs.img for several hours, so i had no choice but to reboot the tab. (i had no kies-related software running, neither my antivirus)
There, the tab got stuck on the "Firmware upgrade encountered an issue. please select recovery in Kies" screen, no way to go to either recovery or download mode (not even worth saying Kies didn't recognize the tab).
I've been struggling a few hours with that brick and finally managed to get acces to download and recovery modes again by flashing CWM with Odin alongside a PIT file with "repartition" ticked in Odin.
So there I could access recovery, I flashed CM9, everything went smooth. The tab rebooted and got passed the Galaxy tab 7.7 logo and went to the cm9 bootscreen but got stuck there (big desillusion right there).
So now in recovery, i can mount every partition but those two : /data/ and /sdcard/
I figured out by reading similar threads that the solution to my issue might be e2fsck through adb. I'm a complete noob to adb.
I can acces the adb shell but here are what the commands i've been reading about return me : (mmcblk0p9 is /data/ partition on P6810)
# e2fsck -fDC0 /dev/block/mmcblk0p9 :
e2fsck : Superblock invalid, trying backup blocks...
The superblock could not be read or does not describe as a correct ext2 filesystem.
If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else),
then the superblock is corrupt and you might try running e2fsck with an alternate superblock : e2fsck -b 8193 <device>
also had this once with this command :
bad magic number in superblock while trying to open /dev/block/mmcblk0p9
# e2fsck -b 8193 /dev/block/mmcblk0p9 :
Attempt to read block from filesystem resulted in short read while trying to open /dev/block/mmcblk0p9
Could this be a zero-length partition ?
# e2fsck -c /dev/block/mmcblk0p9 :
same as above
can you guide me with e2fsck or give me a link to a specific tutorial related to android e2fsck?
is there not a way in adb to like replace the corrupt partitions with freshly created ones ? or any other workaround ?
Any help will be appreciated a lot, i'm willing to donate to whoever provides me with a solution to get my tab running again.
Thanks for reading.
check this thread, very informative, helped me before
http://forum.xda-developers.com/showthread.php?t=1625675&highlight=bootscreen
Thanks a lot, already checked that one though.
Everything that worked for the guys in that thread doesn't work for me, or I'm too ignorant to find out the right e2fsck command...
Still no one able to provide some help please ?
It's weird that so many people are having the same issue on 7.7 these days, could it be related to the EU ban of this tab ?^^
Anyway, last day before i send it to Samsung
check this thread here it may help you solve your issue. All problems are coming from a brick bug in the ICS Kernel thats trigerred by wiping.
Thanks a lot, trying this right now
Can someone please post a (parted) print of a safe and working Galaxy Tab 7.7 (either of the two models) ?
I need the exact size of the /data partition
ISSUE FIXED Thanks to Zorbakun's last post. A million thanks dude.
However, the actual internal storage of my tab is now 50mb :silly: anyway i'll find a way to fix that too.
the actual internal storage of my tab is now 50mb
Hello Androguide.fr.
Did you manage to find a way to fix your shrink of internal storage? If so, would you mind to share the method. Thanks
Regards
Budi
cakrabayu said:
Hello Androguide.fr.
Did you manage to find a way to fix your shrink of internal storage? If so, would you mind to share the method. Thanks
Regards
Budi
Click to expand...
Click to collapse
Well yeah, didn't recover the 16gb but you can try to earn yourself some extra gigs by doing this once you created a fresh /data partiton :
this is an example for p6810, replace resize 9 with resize 10 if on a p6800
Code:
adb shell
parted /dev/block/mmcblk0
print
resize 9
It will ask you for start/end values, keep the same start value otherwise it will give you an error. A good idea is to resize the partition like + 500mb at a time, to avoid i/o errors you might get when creating/resizing large file systems.
Hope it helps, good luck.
I am about to have to do this myself, and i'm not a developer. i have accessed and navigated around my device through adb, but this level of complexity *almost* over my head. i just want to make sure i'm not going to permanently mess this up. also, someone in another thread tried flashing ICS with an older version of ODIN and now his tab won't even power on. which i'm trying to avoid... so after reading around these forums for a few days (it happened saturday morning--and i KNEW to avoid flashing from stock ICS recovery--i think i wiped /data-cache-dalvik with CWM 5.0.1) i'm pretty sure that failure to mount /data seems to be the super brick bug everybody's talking about. i bought the p6800 as an import in the US so i am without warranty... if anyone can help with a step by step guide for the masses or something... i'm intelligent, and quite computer literate/net saavy, but i'm not a mentat ("dune" reference)...
like, i'm having trouble figuring out how to install adb on windows. and how do i use parted when it's linux software? i've repartitioned HD's before, and i'm familiar with some command-line basics, but....
--going to bed now...my head hurts--
aletheus said:
I am about to have to do this myself, and i'm not a developer. i have accessed and navigated around my device through adb, but this level of complexity *almost* over my head. i just want to make sure i'm not going to permanently mess this up. also, someone in another thread tried flashing ICS with an older version of ODIN and now his tab won't even power on. which i'm trying to avoid... so after reading around these forums for a few days (it happened saturday morning--and i KNEW to avoid flashing from stock ICS recovery--i think i wiped /data-cache-dalvik with CWM 5.0.1) i'm pretty sure that failure to mount /data seems to be the super brick bug everybody's talking about. i bought the p6800 as an import in the US so i am without warranty... if anyone can help with a step by step guide for the masses or something... i'm intelligent, and quite computer literate/net saavy, but i'm not a mentat ("dune" reference)...
like, i'm having trouble figuring out how to install adb on windows. and how do i use parted when it's linux software? i've repartitioned HD's before, and i'm familiar with some command-line basics, but....
--going to bed now...my head hurts--
Click to expand...
Click to collapse
Try the .PIT file for the P6800 located here. You will lose all data, and part of your internal SD space. Looks like the brick happens consistently at the same point of the memory chip, so the same .PIT works for most people. If that doesn't help, you will need parted.
How can you use parted? It's a Linux program that runs in your tablet. You will adb shell to it, then you will have a Linux shell. Everything you put down there will run in your tablet, as if you were typing on it (think ssh, or remote desktop). I can't help you much more, because (knocks on wood) my tablet is still very much alive, and I don't use ADB that much.
Now, I don't know how it works in your country, but here in Brazil the Samsung service accepts warranties issued anywhere. It may be worth a shot.
aletheus said:
I am about to have to do this myself, and i'm not a developer. i have accessed and navigated around my device through adb, but this level of complexity *almost* over my head. i just want to make sure i'm not going to permanently mess this up. also, someone in another thread tried flashing ICS with an older version of ODIN and now his tab won't even power on. which i'm trying to avoid... so after reading around these forums for a few days (it happened saturday morning--and i KNEW to avoid flashing from stock ICS recovery--i think i wiped /data-cache-dalvik with CWM 5.0.1) i'm pretty sure that failure to mount /data seems to be the super brick bug everybody's talking about. i bought the p6800 as an import in the US so i am without warranty... if anyone can help with a step by step guide for the masses or something... i'm intelligent, and quite computer literate/net saavy, but i'm not a mentat ("dune" reference)...
like, i'm having trouble figuring out how to install adb on windows. and how do i use parted when it's linux software? i've repartitioned HD's before, and i'm familiar with some command-line basics, but....
--going to bed now...my head hurts--
Click to expand...
Click to collapse
I am working on writing a specific 7.7 guide to teach people the parted/e2fsck technique I use to revive my bricked p6810 everytime I want to flash a new rom or test my builds.
First, as pointed out, try to Odin the PIT file for your particular model (eg : P6800 16gb).
You got to know that the parted technique is a pain in the ass, that you'll have to do it quite often if you like flashing roms, and that your tab will have a much smaller internal storage.
I think the guide will be ready in a couple days but you can pm be if you need help before that, no problem.
Good luck with this superbrick curse
thanks guys for your help, i'm going to try to figure this out this afternoon. i'm in the US, so they don't even offer warranties on imports. i was told by a samsung rep in the US that they don't grant warranties to imported models. i will first try the modified PIT file, then i will try the more complex method. @Androguide.fr i will PM you if i have trouble with the more complicated method later. thanks!!!!
aletheus said:
thanks guys for your help, i'm going to try to figure this out this afternoon. i'm in the US, so they don't even offer warranties on imports. i was told by a samsung rep in the US that they don't grant warranties to imported models. i will first try the modified PIT file, then i will try the more complex method. @Androguide.fr i will PM you if i have trouble with the more complicated method later. thanks!!!!
Click to expand...
Click to collapse
I just finished writing the guide, it's here : forum.xda-developers.com/showthread.php?t=1862294
-
I have not done this before and have not tested this method, do this at your own risk!!!
We've made it to the XDA Portal! (link below)
http://www.xda-developers.com/android/fix-your-soft-bricked-galaxy-s-iii-samsungs-way/
Hi,
A few months ago I hard bricked my Galaxy S II into an unfixable situation the only fix being replacing the motherboard. More info: HERE
While looking for a fix I encountered this thread: HERE
This thread contained a leaked confidential file from Samsung on how to fix a Bricked Galaxy S III. It wasn't relevant to me then because I didn't have a S3, but now as an owner of a S3 I find this may be very useful and may save lots of money if & when needed.
Brief Description of the fix:
Copying the Bootloader file to an external SD Card, using a normal GT-I9300.
Inserting the external SD card into the bricked phone, and copying the bootloader file to the defective PBA.
After downloading the bootloader file to the defective phone, entering download mode with the phone, and downloading a Full S/W.(PIT, PDA, CSC, PHONE files)
Description of the files attached to this post:
(12-38)_GT-I9300_BRICKED.pdf.zip - This ZIP file Contains a PDF file that is the manual for the fix.
GT-I9300_Boot_Recovery.tar - This TAR file is the Bootloader that is copied to the external SD card.
Odin3v3.07.rar - The program specified in the manual that copies the bootloader onto the external SD card.
GT_I9300_unbrick_sdcard_head.zip - The BIN file used in Rebellos's method below.
Requirements:
Odin3 v3.07.exe and Odin3.ini
GT-I9300_Boot_Recovery.tar
(12-38)_GT-I9300_BRICKED.pdf.zip
External SD Card (Memory size should be 2GB or bigger.)
One normal I9300 phone(normally booted on)
*Resistor has to be shorted very carefully, avoiding touching any other parts at all cost. If you short too many things together - possibility of frying some component of your I9300 rises drastically.
No one has yet to report trying this fix and it being successful, but I am confident that if preformed according to the instructions this fix has the potential of fixing almost any bricked GS3.
One Little Problem:
Scenario: I bricked my phone and I want to fix it as mentioned in this thread. So I go ahead and look at the requirements:
I download it from the attachments.
I download it from the attachments.
I download it from the attachments.
I don't have one so I go buy one from a store for a little amount of money.
[*]Ummmm... I have one but it can't boot... Damn! I don't have any friends that own one.... Damn! What should I do?!
Buy a new one so I can use it to fix the old one :silly:
Take my bricked phone to a store and pay at least 60$ for a fix.
Follow the instructions below.
Highly Recommended: (Not Tested Yet, People who do this - please report in the thread)
Because of the 'One Little Problem' there are a few things you can do ahead of time so if you brick your phone you will be prepared:
If you don't own an extra one, buy a 2GB external SD card.
Follow steps 1-12 in the manual using your own phone.
Take the external SD card out of your phone and put it away in a safe place to be used if needed.
Or follow Rebellos's (Elite Recognized Developer) way:
Here's an experimental image: (Or attached to this post)
https://dl.dropbox.com/u/32145655/GT_I9300_unbrick_sdcard_head.zip
1) Insert SD card (Everything from it will be wiped!)
2) Bootup some linux machine (it can be rooted android phone aswell as its also linux machine )
3) Unpack archive
4) Perform dd if=GT_I9300_unbrick_sdcard_head.bin of=/dev/<path to SD card device>
On most of phones its /dev/block/mmcblk1 (MAKE SURE YOU DONT OVERWRITE YOUR INTERNAL PHONE MEMORY, ITS USUALLY "/dev/block/mmcblk0")
On PCs it depends, its sometimes /dev/sdb
More info about dding sd card:
http://mikelev.in/2010/09/cloning-an-sd-card-on-linux/
You're all ready and set, try to boot it up on dead I9300 and tell me how did it go! (Follow step 14 of Samsung's guide)
Also, I don't think Anyway JIG is necessary. Probably you only need to connect it to PC so it gets powered and you can use download mode.
Click to expand...
Click to collapse
Notice:
This method of fixing your bricked device is only meant to be used if all else fails: Full S/W package with Odin (PIT, BOOTLOADER, PDA, PHONE, CSC) Or USB Jig.
I have not done this before and have not tested this method, do this at your own risk!!!
-
-
Significant & Useful Posts
Significant & Useful Posts
mikep99 said:
Just been through actions 1-12 with no problems.
However, I can't see anything on internal/external sdcard that looks like a copy of the bootloader.
I'm assuming it's written to a part of the sdcard just like the 'goldcard' on the HTC Desire, which can't be seen without a hex editor.
This would then get picked up when using a jig?
Can anyone confirm this?
Sent from my GT-I9300 using xda app-developers app
Click to expand...
Click to collapse
Rebellos said:
Here's an experimental image:
https://dl.dropbox.com/u/32145655/GT_I9300_unbrick_sdcard_head.zip
1) Insert SD card (Everything from it will be wiped!)
2) Bootup some linux machine (it can be rooted android phone aswell as its also linux machine )
3) Unpack archive
4) Perform dd if=GT_I9300_unbrick_sdcard_head.bin of=/dev/<path to SD card device>
On most of phones its /dev/block/mmcblk1 (MAKE SURE YOU DONT OVERWRITE YOUR INTERNAL PHONE MEMORY, ITS USUALLY "/dev/block/mmcblk0")
On PCs it depends, its sometimes /dev/sdb
More info about dding sd card:
http://mikelev.in/2010/09/cloning-an-sd-card-on-linux/
You're all ready and set, try to boot it up on dead I9300 and tell me how did it go! (Follow step 14 of Samsung's guide)
Also, I don't think Anyway JIG is necessary. Probably you only need to connect it to PC so it gets powered and you can use download mode.
Click to expand...
Click to collapse
Odia said:
You did not need to flash the bootloader to your phone first, its only in the instructions in case the bootloader in the good GS3 does not support SDCARD write protocol.
I can confirm that using an SDCARD image to create the tweezer-tag SDCARD does work.
NOTE: Its also possible to write the entire OS to SDCARD, not just the bootloaders.
Click to expand...
Click to collapse
Rebellos said:
Flashing new bootloader is relatively safe (as far as reflashing bootloader can be safe)
It's just same set of bootloaders but with enhanced ODIN protocol - support of writing into T-Flash. As Odia said - recently produced I9300 models might have this feature in bootloader already.
No repartition should be used for these, new bootloader should overwrite old bootloader in working I9300, and during second flash present PIT will be used.
Click to expand...
Click to collapse
Rebellos said:
It can be said I added few steps after step 11 and before step 12 of Samsung guide.
Note: System must be rooted.
11.1) Bootup phone and connect it to PC
11.2) Invoke "adb root"
11.3) Invoke "adb shell dd if=/dev/block/mmcblk1 of=/storage/sdcard0/recovery_sd_head.bin bs=1024 count=4096"
11.4) Invoke "adb pull /storage/sdcard0/recovery_sd_head.bin"
You will endup with dump of first 4 megabytes of sd card. Should be enough to contain all necessary data to re-create bootable sd card from it.
Actually boot partition is ~880KB big so I guess dump of ~900KB should be enough. But better to have abit more and be more sure it'll work.
Click to expand...
Click to collapse
Rebellos said:
I've disassembled my I9300 yesterday and did some live tests on it.
Unfortunately I was unable to trigger EXT-SD boot, it's pretty hard to short only single resistor without shorting anything else and hanging the board or blowing something up. I'll retry it someday later when I get better tools. Maybe I triggered ext-sd boot but it didn't end up in any special screen because my device was fully alive.
Some tech background I worked out on that solution
Some good news:
If this is possible for SGS3, it's highly plausible that this such method of unbricking can be used for Exynos SGS2 models. This of course needs preparing another magic-SD card.
Click to expand...
Click to collapse
Net.silb said:
We've made it to the XDA Portal! (link below)
http://www.xda-developers.com/android/fix-your-soft-bricked-galaxy-s-iii-samsungs-way/
Click to expand...
Click to collapse
Reserved...
Thanks for this
Sent from my GT-I9300 using xda premium
b-eock said:
Thanks for this
Sent from my GT-I9300 using xda premium
Click to expand...
Click to collapse
My pleasure!
Thanks man
Seems... complicated
I wonder if sharing the "Bootloader SD Image" is an option, would be great to have someone brave enough to upload it for the community to avoid messing with the bootloader of a healthy BORROWED i9300.
Thanks for sharing !
Just been through actions 1-12 with no problems.
However, I can't see anything on internal/external sdcard that looks like a copy of the bootloader.
I'm assuming it's written to a part of the sdcard just like the 'goldcard' on the HTC Desire, which can't be seen without a hex editor.
This would then get picked up when using a jig?
Can anyone confirm this?
Sent from my GT-I9300 using xda app-developers app
Thanks for the share man! Will do some digging and look into this as well when I get time!
Excellent... I've always been worried about bricking my device. I've had my S3 for 2 months and it's the first phone I've rooted, so bricking was always a serious concern for me.
If this is proven to work... thank god!
Hi guys,
Step 15 in the (12-38)_GT-I9300_BRICKED.pdf Is not 100% clear to me and I would love if someone can explain what exactly needs to be done at that step.
"15) Connect the PBA with Anyway JIG and power supply, with the POWER OFF. ※ Use 11pin cable to supply power to the PBA."
Moderators please make this sticky!
Report the thread guys,it'll be useful to have this around in case something bad happens!
If you can use any GS3 to restore the get sharing those files
Sent from my GT-I9300 using xda premium
Net.silb said:
Hi guys,
Step 15 in the (12-38)_GT-I9300_BRICKED.pdf Is not 100% clear to me and I would love if someone can explain what exactly needs to be done at that step.
"15) Connect the PBA with Anyway JIG and power supply, with the POWER OFF. ※ Use 11pin cable to supply power to the PBA."
Click to expand...
Click to collapse
I guess the anyway jig is the jig that they use to put phones into download mode? I got one for my s2 but I'm not sure if it's the same thing.
Sent from my GT-I9300 using Tapatalk 2
This can only be done if you have the Samsung Anyway jig and no one on XDA has their hands on that yet. Or schematics of the board. We need an inside guy to leak that or even give us one.
Sent from my GT-I9300 using xda premium
b-eock said:
This can only be done if you have the Samsung Anyway jig and no one on XDA has their hands on that yet. Or schematics of the board. We need an inside guy to leak that or even give us one.
Sent from my GT-I9300 using xda premium
Click to expand...
Click to collapse
Yes, maybe only a Samsung Anyway Jig can be used as the phone needs to be booted into "SD Card Mode".
But there is always the possibility that a normal Jig can be used, and the power supply can come from the battery and that shorting "R313 resistance" will force the phone into "SD Card Mode".
We can only know for sure once someone has tried it.
Edit:
Info on the Anyway Jig: http://forum.xda-developers.com/showthread.php?t=1629359
I am not here to argue, if we find a way to make the S3 unbrickable without the unbrickable mod. Then Awesome!!! Maybe this weekend we can talk about how things can be done. Until then I have football practice 6 outta the 7 days a week.
And I have that thread bookmarked bro
b-eock said:
I am not here to argue, if we find a way to make the S3 unbrickable without the unbrickable mod. Then Awesome!!! Maybe this weekend we can talk about how things can be done. Until then I have football practice 6 outta the 7 days a week.
And I have that thread bookmarked bro
Click to expand...
Click to collapse
Never intended to sound provocative, just trying to brainstorm ideas on how we can make this thing work!
Look here at post #14: http://forum.gsmhosting.com/vbb/f200/gt-i9300-boot-repair-freee-1497416/
The guy got into SD card mode and got this:
SDCARD MODE
COPY BINARY FROM SDCARD
COPY BINARY TO EMMC
SDCARD DOWNLOAD FAILED
If we can contact this guy and see exactly what happened maybe we can learn more about how to do this.
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
I done ****ed up.
I was attempting to wipe modemst1 and modemst2 because I had flashed a good five different radio firmware packages, and I was rather concerned that there was some conflicting... stuff happening. I thought I had taken successful backups, just in case. However, it turns out these backups failed to write properly, and instead created blank files.
Lo and behold, when my IMEI decided it didn't want to IMEI anymore (it currently reports as 0), I had no recourse. However, all is not lost! I can edit a restored modemst1/2 and write these into position... I think. However, I need help - I don't have another Axon 7 to fetch from. So, if someone here would be so kind as to provide some, that would be extraordinarily good of them.
If you're wondering, this is the command to make a copy:
Bash:
dd if=/dev/block/bootdevice/by-name/modemst1 of=/storage/0000-0000/modemst1backup
dd if=/dev/block/bootdevice/by-name/modemst2 of=/storage/0000-0000/modemst2backup
These commands should place the files modemst1backup and modemst2backup on your SD card. If you have no SD card at hand, replace 0000-0000 with self/primary to save on to your phone's internal storage.
It's probably a requirement for your handset to also be a European A2017G - a US or CN model might not be compatible, but I honestly don't know whether or not that is a load of horse-****e. Thankyou in advance!
That sucks man, I have no idea what to say so I'll just leave this here:
F
I fixed it! Turns out it's actually not that hard to write an IMEI to a Snapdragon device. I'll make a guid post on this in a moment.
Edit: guide up: https://forum.xda-developers.com/t/guide-imei-fix-for-zero-value-imei-strings.4402835/
Edit 2: Turns out I didn't fix it. Looks like I still have some issues. I could still use a copy of modemst1 and modemst1, if anyone could be so kind.