Related
** UPDATED WITH .BCT saving, include USB as well as NVFLASH just copy in
** 1 dir, run the batch and keep those you may need them one day
** Read the batch file for more info
It is clear for me is that it is not a perfect solution to use nvflash with images that you do not know the source.
The tegra S.O.C. use the information from a file stored in partition#2 to configure some low level setting like flash memory chip speed, total memory installed, video memory installed, flash type etc. As an example, if for some reason a batch of tablet is built with more memory then the .bct files will need to be changed accordingly
It is already confirmed that there's at least 2 different type of hardware. (2 different images by bekit do not use the same .bct configuration)
When flashing after a full wipe after using the create command, nvflash read the .bct configuration files and store it in the partition #2 on the tablet, bct files are created by the manufacturer using a tool from nvdia called buildbct. They are not writen during regular nvflash (where the partition are not re-created)
This also mean it is MUCH safer to NOT replace the partition 2 when nvflashing a device... (the hardware configuration would not be touched).
This batch files will work under windows and will not modify your tablet in anyway
please make sure you use the nvflash tools that is 151K there's an older and smaller one in some package, it will output binary inside the partition.txt instead of plain text. The version 2 include everything you need to backup the device under windows
Thanks to the various poster of thread about nvflash for the correct command THEY did the hard work not me !
To Restore individual partition the command is
"nvflash.exe" --bl bootloader.bin --download X partX.img
where X is the partition number you wish to flash, as stated you can also use your backup from clockwork mod for partition 11 restore.
this will not work for partition below 4
P.S.
I am not trying to start a debate on the validity of the current recovery (thumb-up to the guy who offered those!) They are valid for MOST device however
if you do have a different device this will alleviate any issue that may happen with nvflash restore.
see 2 post below for full restore info
Hi,
I know that the partitiontable shows a partition named "BCT", but is there also something else, perhaps flashed into the SOC itself that is referred to as "the BCT"?
The reason for the question is that nvflash has a setbct and a getbct command, separate from the read and download commands, which work with the partitions.
Jim
Reserved
(will be completed a bit later)
so, we possibly share more internals with the 10s than previously expected? maybe... can we get this thing to dual boot in the future??
10roller said:
so, we possibly share more internals with the 10s than previously expected? maybe... can we get this thing to dual boot in the future??
Click to expand...
Click to collapse
My guess is yes, the platform of the ac100 laptop by toshiba is tegra based and they do it!
P00r said:
The set bct command probably write the 4080 byte to the partition named bct in the cfg, I have yet to test flashing a dummy FF filled partition with the command to confirm the flash.bct get writen there
So in fact when you restore with the nvflash restore images from bekit I think you are actually writing it twice... (it is in the image and you telling the nvflash to create it) but I have not confirmed this yet
Once the bct info is there, the SOC read his configuration there, as well as the ODM info, I have not found a way to use --getbct that reads back the BCT from mass storage yet...
I am not sure either why there's so many section being flashed it should work with only a few of those (I plan to test this) since nvflash is simply puting those one after the other. It make sense only sense for a dual booting unit
Click to expand...
Click to collapse
Hi,
I was able to get --getbct to output a 2048 byte file awhile ago. I think I had posted about it, but, sorry, I don't remember which thread. The only thing I vaguely remember was that I had to use some unobvious combination of parameters. Also, I think that it only worked right after pushing the bootloader.bin. If I find my post, I'll provide a link.
Jim
Thanks OP, I like the idea of being able to back up the partitions directly from my tablet so I know I'm restoring the proper thing should I ever have to resort to that.
Just starting to get into modding this thing after it showed up from Woot yesterday, been planning on buying one for quite some time to compliment my Epic 4g and when the woot sale dropped I had to jump on it. So far all I have done is flash clockwork, and make a nandroid backup with that. Also doing this backup method now.
So have you actually done a successful restore using this method?
so is it possible to back up your original hardware configuration and restore it when you got problems???
Yes and NO, I have error reading partition #11 (system) on my tablet (bad block)
if I use it as is for restore, it doesn't restore and boot, however replacing this partition with clockwork system.img backup give me back a full working tablet.
I can also reboot into recovery and restore from there.
Letters and numbers oh my
I ran the backup on my new replacement GTab yesterday. I had a size mismatch on partition 5, everything else backed up properly. Also, my partition 7 is BLO and partition 6 is MSC. Thanks for the script and capability.
Mike
P00r said:
This also mean it is MUCH safer to NOT replace the partition 2 when nvflashing a device... (the hardware configuration would not be touched). I will post later on how to flash back those if someone request it...
Click to expand...
Click to collapse
Instructions on how to flash back using this would be great. I'd like to have the option to do so if I need to, but haven't gotten familiar enough with nvflash yet to figure it out on my own.
iamchocho said:
Instructions on how to flash back using this would be great. I'd like to have the option to do so if I need to, but haven't gotten familiar enough with nvflash yet to figure it out on my own.
Click to expand...
Click to collapse
You can flash back the partition using
"nvflash.exe" --bl bootloader.bin --download X partX.img
where X is the partition number you wish to flash, as stated you can also use your backup from clockwork mod for partition 11 restore.
If needed you can use the nvflash format kit prior to restoring however it would be better to use your own .bct with that option
Getting stuck at partition 7.
xkwwwx said:
Getting stuck at partition 7.
Click to expand...
Click to collapse
What is the error you are getting ?
stock recovery image
Thank you very much for the sharing this.
Now I have 10 img files (part-2 to part-11)... wich one is the stock recovery image? I did this before installing clockwork mod...
Thanks!
I think this is fantastic. Gives us a chance to backup our gtab before deciding to try a new rom. I tried this today in the hopes to backup and then install the flashback HC rom. But unfortuntaly it stopped on image 7, as xkwwwx has also mentioned. The message seemed to be a issue with the size expected of the image as to what was received. Ill try and copy the message.
"nvflash.exe" -r --read 7 part-7.img
nvflash started
[resume mode]
receiving file: part-7.img, expected size: 16777216 bytes
/ 131072/16777216 bytes received
At that point it stops, and i have to control c to exit the batch file. Id love to be able to backup with this pls, so i can try another rom, and know i can use this to return to this rom if i dont like the new one, any chance this can be resolved pls ?
Was also wondering if some form of GUI maybe of benifit, i know alot of people feel wary of NVFlash, perhaps with a GUI people would feel more comfortable using it. Maybe a simple screen with a backup and restore set of buttons ?
P00r, any chance you can help mate ? Cant use this unfortunatly because of the image size issue.
Icedvoco said:
P00r, any chance you can help mate ? Cant use this unfortunatly because of the image size issue.
Click to expand...
Click to collapse
This mean you probably have a bad block in this section, try skipping it to get the other parts first. this is not a major issue, you may also encounter one in the last data section (my tablet has a few byte less than the regular one)
For the data partition you can substitute the cwm images
Also try using a different bootloader and nvflash this can help even shorter usb cable or a different one can help
The part that you can read is probably usable for a restore anyway
Bad block are not unusual in flash and I have seen a few with this, ideally and usually it's located at the end, you could try using the format image a few time it could be a stuck byte and writing different data can revive it (format write FF all over)
P00r said:
This mean you probably have a bad block in this section, try skipping it to get the other parts first. this is not a major issue, you may also encounter one in the last data section (my tablet has a few byte less than the regular one)
For the data partition you can substitute the cwm images
Also try using a different bootloader and nvflash this can help even shorter usb cable or a different one can help
The part that you can read is probably usable for a restore anyway
Bad block are not unusual in flash and I have seen a few with this, ideally and usually it's located at the end, you could try using the format image a few time it could be a stuck byte and writing different data can revive it (format write FF all over)
Click to expand...
Click to collapse
Bad blocks may be common, but bad blocks in the exact same spot probably not. I get the exact same thing:
"nvflash.exe" -r --read 7 part-7.img
Nvflash started
[resume mode]
receiving file: part-7.img, expected size: 16777216 bytes
/ 131072/16777216 bytes received
Any other thoughts on this?
Maybe someone here knows,
So with NVflashing, I've found only one file that has the alternative BCT (it's a tnt1.0 rom on BL1.1) and no other NVflash file sets work without causing a APX bootloop.
This is the NVflash file set that works for me http://db.tt/FvSeAZj
Ive read it was made when someone was trying to configure for the hardware variations.
Now is it possible to take my backup and insert just the files needed into another NVflash file set?
I hope this information is useful to you. It allowed me to restore my phone, after flashing the 2.3.5BETA from Huawei, effectively reverting the process. If you follow these procedures, you do so at your own risk. A typo in the needed commands may render your phone useless, so if you feel uneasy DON'T DO IT! That being said, on with the show.
Rationale: The U8800's memory is accessible as a mass storage device, when the phone is powered up in pink screen mode. This device holds the boot sector, partitions, operating system and user data. As such, it can be treated as any other block device and can be imaged to a file, through a bit-by-bit copy. The inverse is also possible and thus constitutes a valid backup/restore method.
Motives: Some weeks ago, I imaged my U8800 having in mind that spending time flashing ROMs, recovery and boot images could at some point go wrong and brick the device. Having a full dump of the device, done while it was in good working condition, would give me a chance of disaster recovery.
Requirements: Linux box and familiarization with Linux. I use Slackware 13.37 x86_64, but any flavour of Linux should do.
1 - Enter pink-screen mode by pressing power + vol up + vol down;
2 - Connect the USB cable. I recommend using the USB ports on the back of your PC (irrelevant if it's a laptop) as some PC cases have inadequate wiring to the front ports and will only allow slow data transfer. I've done it all while logged in as root, and not running X. If you're running X and HALD (automount of CD's and USB sticks, etc), you should unmount whatever units get automaticaly mounted when you plug the U8800 in. Avoid X if possible;
3 - Run 'dmesg' to ensure your U8800 was correctly detected. last output on screen should look like this:
[ 4444.026295] usb 1-2: New USB device found, idVendor=12d1, idProduct=1035
[ 4444.026300] usb 1-2: New USB device strings: Mfr=3, Product=2, SerialNumber=0
[ 4444.026304] usb 1-2: Product: Qualcomm CDMA Technologies MSM
[ 4444.026308] usb 1-2: Manufacturer: Qualcomm, Incorporated
[ 4444.029209] usb 1-2: selecting invalid altsetting 1
[ 4444.029265] scsi4 : usb-storage 1-2:1.20
[ 4445.031474] scsi 4:0:0:0: Direct-Access Qualcomm MMC Storage 2.31 PQ: 0 ANSI: 2
[ 4445.031755] sd 4:0:0:0: Attached scsi generic sg2 type 0
[ 4445.034576] sd 4:0:0:0: [sdb] 7733248 512-byte logical blocks: (3.95 GB/3.68 GiB)
[ 4445.035947] sd 4:0:0:0: [sdb] Write Protect is off
[ 4445.035952] sd 4:0:0:0: [sdb] Mode Sense: 0f 0e 00 00
[ 4445.035956] sd 4:0:0:0: [sdb] Assuming drive cache: write through
[ 4445.042568] sd 4:0:0:0: [sdb] Assuming drive cache: write through
[ 4445.053569] sdb: sdb1 sdb2 sdb3 sdb4 < sdb5 sdb6 sdb7 sdb8 sdb9 sdb10 sdb11 sdb12 sdb13 sdb14 >
[ 4445.059328] sd 4:0:0:0: [sdb] Assuming drive cache: write through
[ 4445.059335] sd 4:0:0:0: [sdb] Attached SCSI removable disk"
"sdb" is the device name alocated to the U8800. It can be "sdc", "sdd", "sde". Depends on the number of block devices (hard disks, USB sticks, card readers, etc) already present on your system.
4 - If your U8800 is showing up in "dmesg"' output, you are ready to create the image file, by typing "dd if=/dev/sdb of=u8800.img bs=512". Remeber: this example assumes the device name to be "sdb", yours may be different. If all goes well, you'll end up with the "u8800.img" file in the current directory. This is a 4GB transfer so it will take some time and there will be no progress indicator whatsoever. Final output should look like:
3959420000 bytes (3866621 KB) copied, [ time spent], [KB/s] ( These figures vary according to your transfer speed )
If the transfer fails, the output will show how many bytes were transfered along with the indication that there was an error; should it indicate an error, retry from the beginning, using a different USB port.
The resulting u8800.img file can be ziped, gziped, bziped, rared, whatever to reduce it's size to around 600 MB.
4A - This concludes the backup part;
5 - Having hold of the u8800.img file, you can restore it back to your U8800. Connecting and finding the device name of your mobile through the output of "dmesg" is the same as for backup and is described in (1), (2) and (3). To restore it, and assuming the img file resides in the current directory, type "dd if=u8800.img of=/dev/sdb bs=512". Don't forget to decompress the file in case you ziped it. Again, your device name may be other than "sdb".
Since writing to flash memory is a slower process than reading it, this operation will take longer than performing the backup. As an example, mine took around 45 minutes to complete, while other user reported 25 minutes for the same operation.
BEWARE: There's no way to perform a sanity check of the img file you're dumping back! Those commands will hapilly flash an Excel spreadsheet to your mobile's memory if you give it as a parameter to the "dd" command!
Final words
I used this method to revert to a pre 2.3.5BETA state. Huawei's update wrote a new bootloader, which is something not included in CWM backups and restores. Furthermore: CWM restores showed up errors about mountpoints. Ignoring these errors and performing a factory reset would allow FROYO to boot up and run, but my carrier's costumizations, which reside in the same volume as boot.img, and restore.img, were ignored afterwards. I didn't want this to be used as an argument by the carrier to consider my warranty void, should I need it...
Cheers
First of all, thanks for your tut, it's very helpfull for those who have linux
I have a question
The u8800.img contains all partition data?
Thanks in advance, regards
sewa2k said:
First of all, thanks for your tut, it's very helpfull for those who have linux
I have a question
The u8800.img contains all partition data?
Thanks in advance, regards
Click to expand...
Click to collapse
Yes. You can mount the image through /dev/loop and run fdisk on it to see the partition table.
There are windows tools to accomplish the same tasks of byte-copying to a file and vice-versa, but I haven't used them, since it was straight-forward with Linux.
Cheers
Thank you very much for this tutorial.
But what about us who have not made this backup when we had the original froyo and flashed the original 2.3.5?
I have several CWM backups but none of them works(it keeps booting in recovery mode or not booting at all),unless i restore to factory data which is useless.
Can you or someone else please upload a clean froyo backup so we can flash it and go back to our 2.2 backups via CWM?
bonowax said:
Yes. You can mount the image through /dev/loop and run fdisk on it to see the partition table.
There are windows tools to accomplish the same tasks of byte-copying to a file and vice-versa, but I haven't used them, since it was straight-forward with Linux.
Cheers
Click to expand...
Click to collapse
Thanks m8, i'll do it tonight, so i can start to porting roms to U8800-51
Wow nice. I was waiting for something like this. I ran "sudo -i" before the process and it's copying right now. This is good for recovering the phone in case of soft brick.
That was a great tutorial! Thank you!
I did it on an Atom netbook last night, booting Linux from a USB thumb drive.
I saved the image on an external USB ntfs HDD, that it had to first be mounted, of course. I had to to this because the internal disk is an 8GB SSD with no room for a 4GB image file.
The imaging process took about 25 minutes on this machine, with all 3 USB 2.0 ports occupied (Boot USB drive, u8800, external USB drive). Transfer speed was about 2.7 MB/s.
Right now I'm trying to compress it with 7zip (maximum) and at 65% progress it has a 45% compression ratio (output/total). (The phone has many apps installed (1GB) and also I have the ndrive folder on the internal memory as a backup in case there is a problem with the ext SD.)
So I suggest you, to do the backup on an empty phone if possible, if you want the smallest size for your image.
Regards.
sport_billy said:
Thank you very much for this tutorial.
But what about us who have not made this backup when we had the original froyo and flashed the original 2.3.5?
I have several CWM backups but none of them works(it keeps booting in recovery mode or not booting at all),unless i restore to factory data which is useless.
Can you or someone else please upload a clean froyo backup so we can flash it and go back to our 2.2 backups via CWM?
Click to expand...
Click to collapse
It should be possible to dump and restore only the first two partitions, in which case it would make a much smaller up/download. This would restore the previous bootloader and allow CWM to operate normally ( or at least I hope so ).
I'll look into it.
EDIT: I dumped primary partitions 1, 2 and 3 to a image file which is around 140 MB after ziped. This could be enough to restore the old bootloader. "Could" is the keyword here, as it assumes the partition scheme is the same in every U8800.
bonowax can you please upload it so we can give it a try?
I am having bootloops even with the new beta v2 they released today.
So your solution is the only way to revert back to 2.2 .
sport_billy said:
bonowax can you please upload it so we can give it a try?
I am having bootloops even with the new beta v2 they released today.
So your solution is the only way to revert back to 2.2 .
Click to expand...
Click to collapse
you could just install stock 2.2 firmware normal way ... easy as that
Sent from my u8800 using XDA App
Yes but if i restore my CWM backup after flashing via the classic method it keeps rebooting in recovery mode.
So it is useless and it also means that it is not completely the same as before.
Some people mentioned having issues after flashing 2.2 with the classic method .
I want to try the method mentioned here.
sport_billy said:
bonowax can you please upload it so we can give it a try?
I am having bootloops even with the new beta v2 they released today.
So your solution is the only way to revert back to 2.2 .
Click to expand...
Click to collapse
Unfortunately there is the IMEI issue. I don't know where it is stored, and dumping from phone to phone might not be a good idea, unless we're talking about two devices you can actually get a hold of AND you do a full backup of both devices prior to any experiments...
Many, many thanks for posting this tutorial.
I ended up with a unformatted 4GB drive after trying to revert genokolar's custom partition script due to boot loops with the 2.3 beta. Luckily I had done a backup via this method so I was able to restore it successfully.
Be warned that it takes a long time to restore the full 4GB, well over an hour on my phone. I had almost given by the time it had finished.
I would definitely recommend this to anyone who wants to try any custom roms or messing around with scripts. I just wish I'd done it when my phone was completely stock.
Excellent!
I actually did a dd backup before 2.3.5 upgrade, but I didn't dare to restore it. Now I know it worked for you
I started the phone in bootloader mode and WOW, my Ubuntu crashes. It gives some kernel message and the display is completely messed up. It worked before, but it made my computer not shut down properly. Any help is appreciated.
Blefish said:
I started the phone in bootloader mode and WOW, my Ubuntu crashes. It gives some kernel message and the display is completely messed up. It worked before, but it made my computer not shut down properly. Any help is appreciated.
Click to expand...
Click to collapse
I was not able to use Ubuntu 11 - it auto mounted all the partitions and like you crashed when trying to dismount them.
I have tried every way to stop this auto mount behaviour - looking in all the forums I could find, but nothing worked, so yesterday I grabbed LinuxLive USB creator, http://www.linuxliveusb.com/ and used it to create a live Puppy Linux on my usb stick, it runs sweetly on my laptop (booting from the USB drive not running it using the vbox option inside Windows).
It immediately recognises all the U8800 partitions but does not automount them.
I ran the dd command after navigating in terminal to a spare folder on my laptop hard drive (after mounting the laptop hard drive with Puppy's useful mounter app), and now I have a u8800.img on my laptop hard drive! Perfect!
Oh - and of course once again - EVERY time I have used pink screen mode on my U8800 with the latest Stock Beta 2 Gingerbread, it re-boots ok but the SD card is gone. Booting into recovery mode and wiping the Dalvik cache is the way to solve this - it is now completely predictable and after doing this I am back to a really great phone - faster, cooler, great camera and video, BBC iPlayer etc.
will this method work also on u8800pro?
Isn't it the same of going to the pink screen, open the image directory and do a backup of all files in it?
BTW, the problem is that we need to go to the pink screen to restore the phone, right?
Inviato dal mio u8800pro usando Tapatalk
matteof93 said:
will this method work also on u8800pro?
Isn't it the same of going to the pink screen, open the image directory and do a backup of all files in it?
BTW, the problem is that we need to go to the pink screen to restore the phone, right?
Inviato dal mio u8800pro usando Tapatalk
Click to expand...
Click to collapse
Simply copying the image is not enough, full copy (dd) backups system, cache, even IMEI, if I am not mistaken.
Easiest way is of course copying when in pink screen, but with some hacking it should be possible in Android aswell.
Sent from my U8800 using Tapatalk
Blefish said:
Simply copying the image is not enough, full copy (dd) backups system, cache, even IMEI, if I am not mistaken.
Easiest way is of course copying when in pink screen, but with some hacking it should be possible in Android aswell.
Sent from my U8800 using Tapatalk
Click to expand...
Click to collapse
but we already have a way to downgrade from 2.3.5 to 2.2.2 on u8800pro using update.app and update_g.app
matteof93 said:
but we already have a way to downgrade from 2.3.5 to 2.2.2 on u8800pro using update.app and update_g.app
Click to expand...
Click to collapse
Well if for example for reason x the partition table gets messed up or anything else, you can restore everything back with dd. If you can get into the pink screen.
Sent from my U8800 using xda premium
Hi emmc bricked folks,
this is a emmc partition scanner which is mainly usable for emmc bricked phones (only Samsung?).
It's a companion software for my xda thread: "PIT file method to revive your phone from a MMC_CAP_ERASE brick".
The tools are started via "install zip" from a recovery.
emmc_scan_all_partitions_once.zip
emmc_scan_all_partitions_infinitely.zip
these allow fast scanning of all blocks of all emmc partitions in 1MiB steps.
The main purpose is to access each emmc block to find any bricked block in the partitions after repartitioning.
The "infinitely" variant runs checks infinitely, which may help to find emmc brick effects which only occur sporadically (if such effect really exists). Run this as long as you want. Reboot to finish.
If this freezes the last partition shown may have a bricked block inside.
emmc_find_brick_start.zip
emmc_find_brick_end.zip
these scan the whole emmc device.
emmc_find_brick_start starts scanning from the beginning of the device upward.
emmc_find_brick_end searches the end of the device and then scans downward.
If this runs up to the end or down to zero (showing a message with "completed --> OK"), no bricked block was found.
If it freezes, the block shown last with "..." at end of line is the first bricked block in that direction.
The line before with "-> ok" is the first usable block before/after the brick.
The tools above only read bytes from the emmc block devices, so it generally shouldn't harm anything.
Don't worry about the term "flash", because it doesn't really flash, it's only using the update mechanism of the recovery (edify scripting).
This is called fake flashing.
emmc_scan_write.zip
this is a very experimental scanner.
It is for experiments on phones, which have no obvious bad blocks in the partitions (scanned by scan_all_partitions_infintely without freeze) but still freeze randomly (without having problems with apps etc.).
It continuously creates a file of 10MB and deletes it after that.
The theory behind that:
* the wear leveler will assign different blocks each time the file is created
* the wear leveler may get a problem when assigning blocks to the file
* then it will freeze
* hopefully, if the file isn't deleted it will claim the bricked block(s), so they are not assigned again
* this will allow to isolate the blocks
* to keep those files containing bricked blocks, they are placed on the internal sd
note: the running counter is the amount written yet. It is not related to the partition size.
important:
The internal sd is determined by an environment variable EXTERNAL_STORAGE.
Despite it's name it should be the *internal* sd, instead SECONDARY_STORAGE contains the external sd.
I hope, this applies to all android OSes...please report if not.
For now you shouldn't use the tool, until you checked this:
adb shell set
If EXTERNAL_STORAGE isn't your *internal* sd, the tool will not help, because it writes on the external sd.
Some users wonder why it works so fast.
That's because it doesn't read each and every byte (like dd command or the "emmc brickbug check" app) but instead jumps in reasonable steps and in each step reads only the first byte of the chunk.
I think, reading each byte is not needed, because the flash memory is always used blockwise and the wear leveler (which has the bug) is working on the block level not the byte level. So a bricked block should always affect each byte in this block, which means reading one byte should be enough.
I choose steps of 1MiB (1024x1024 bytes), mainly because it's like parted etc., but unfortunately 1MB (1000x1000) doesn't work well so I was forced to use the MiB steps and calculated the other (currently rounded). May be the internal wear leveler block size is smaller (e.g. 256kiB = 256x1024 bytes), but it seems that the affected block area is always bigger than 1MiB. But I may rethink this decision...
when it's running slow
The scan method is very fast, I think the complete scan of the internal emmc should be done in under a minute, add several minutes for the external sd if scanning all partitions.
That said, if you get much slower performance, you probably hit an emmc bricked block. It seems the emmc brick can show up in two ways, either completely freezing the device or returning an error after a timeout which slows down the scan process significantly.
The word "FREEZE" in the descriptions above should be replaced by "freeze or slowdown".
So if it slows down, note the numbers at this point, like if the emmc freezes.
It's possible to use the scanner manually in adb (also from a terminal in the gui).
Extract file emmc-scan from one of the zips, put somewhere (=PATHTOSCANNER).
Eventually use
Code:
chmod 555 PATHTOSCANNER/emmc-scan
to make it executable (depend on how you extract it).
usage for find-brick-start:
Code:
PATHTOSCANNER/emmc-scan -p -f MMCBLOCKDEVICE
usage for find-brick-end:
Code:
PATHTOSCANNER/emmc-scan -p -b MMCBLOCKDEVICE
with e.g. MMCBLOCKDEVICE = /dev/block/mmcblk0 for N7000, etc.
example session:
Code:
unzip 120824-221256-emmc_find_brick_end.zip emmc-scan
adb root
adb push emmc-scan /cache/
adb shell chmod 555 /cache/emmc-scan
adb shell /cache/emmc-scan -p -f /dev/block/mmcblk0
to scan all partitions of all flash memory devices automatically (using my algorithm to find the flash devices) simply use:
Code:
adb shell /cache/emmc-scan
for usage description use:
Code:
adb shell /cache/emmc-scan -H
which outputs something like this:
Code:
usage:
emmc-scan [-f | -b] [-a] [-p] [DEVICE | PARTITION]
emmc-scan -w [-a] [-p] DIRECTORY
emmc-scan -H
operations:
-f forward, scan from begin to end of device
-b backward, scan from end to begin of device
-w write to writable partitions (fill with small files)
targets
-a scan all partitions
DEVICE device to be scanned (e.g. /dev/block/mmcblk0 )
PARTITION partition to be scanned (e.g. /dev/block/mmcblk0p10 )
DIRECTORY directory to be filled with files (e.g. /data, /sdcard )
other:
-p print position while scanning
-c print CR after position
-H output this help text
comments:
- scanning/writing is done in 0 byte steps (0 MiB)
- multiple devices/partitions/-a can be given with different options
- devices are scanned with all options given before
examples:
emmc-scan -b mmcblk0p10
scan /dev/block/mmcblk0p10 backward
emmc-scan -f -a -b /dev/block/mmcblk0
scan all partitions forward and mmcblk0 backward
To use the scanner with a terminal app in the android gui,
you ommit "adb shell",
so the example session would look like this:
Code:
chmod 555 /cache/emmc-scan
/cache/emmc-scan -p -f /dev/block/mmcblk0
There were several problems to be solved, mainly:
* seek, setpos functions not working for big partitions (only 4 byte numbers)
* dd command with skip= also not working for big partitions
* finding the emmc device(s)
* finding all emmc partitions to be scanned
* finding the end of a partition without working seek/setpos and without touching a block
* showing live outputs from the program in recovery (unfortunately doesn't work with \r)
the zips are now signed (but see "known bugs" section below).
currently tested on:
* Samsung Galaxy Note N7000
please report if it works for your phone model (e.g. finds the correct partitions) if it's not on the compatibility list.
known bugs:
* the signed zips may not work with stock recovery (1 report but no reports after changing the signing method)
Disclaimer: of course I cannot give any guaranties.
Please don't copy or link directly to an attachment. Link to the whole thread instead.
I will probably update this first post and the attachments frequently, at least until all calms down.
hg42 said:
Hi emmc bricked folks (and perhaps others),
I just created a emmc partition scanner which is mainly usable for emmc bricked phones (only Samsung?).
It is started via install zip from recovery.
It allows fast scanning of blocks in 1MiB steps of all emmc partitions.
The main purpose is to access each emmc block to find any bricked partition after repartitioning.
There were several problems to be solved.
Mainly
* seek, setpos functions not working for big partitions (only 4 byte numbers)
* dd command with skip= also not working for big partitions
* showing live outputs from the program in recovery
* finding all emmc partitions to be scanned
Please report, if it works for each unreported phone model. I will add a compatibility list and try to fix incompatibilities.
currently tested on:
* Samsung Galaxy Note N7000
Click to expand...
Click to collapse
Thank you for the post,
I need to try...
However, is it okay to flash this with STOCK ICS ROM?
tannykim said:
Thank you for the post,
I need to try...
However, is it okay to flash this with STOCK ICS ROM?
Click to expand...
Click to collapse
yes, this software only reads, so generally cannot harm.
It doesn't really flash, it's only using the update mechanism of the recovery (scripting).
hg42 said:
yes, this software only reads, so generally cannot harm.
It doesn't really flash, it's only using the update mechanism of the recovery (scripting).
Click to expand...
Click to collapse
Please let me know if I am wrong.
I think I can only run signature confirmed flash with STOCK ROM.
Could you please confirm I can flash this with STOCK KERNEL [3.0.15-N7000XXLPY-CL474507] ?
please i neeed a good help whene its ok with custom partition but after flashing stock pit i have a good black screen i cant access to nothing either with jig
nice work will try.Thanks
tannykim said:
Please let me know if I am wrong.
I think I can only run signature confirmed flash with STOCK ROM.
Could you please confirm I can flash this with STOCK KERNEL [3.0.15-N7000XXLPY-CL474507] ?
Click to expand...
Click to collapse
this might be, I am using custom ROMs all the time (mostly cm9).
But anyway, it's better to flash a custom kernel in these times (emmc brick is waiting).
tannykim said:
Please let me know if I am wrong.
I think I can only run signature confirmed flash with STOCK ROM.
Could you please confirm I can flash this with STOCK KERNEL [3.0.15-N7000XXLPY-CL474507] ?
Click to expand...
Click to collapse
hg42 said:
this might be, I am using custom ROMs all the time (mostly cm9).
But anyway, it's better to flash a custom kernel in these times (emmc brick is waiting).
Click to expand...
Click to collapse
Hi hg42, I'm on S2, but I think your work is great for all user that have bricked their devices, so any question: there is a cwm.zip for note (a temporary CWM flashable from the stock recovery like on S2)? If yes this can answer the question of tannykim.
Thank you
Mario
Inviato dal mio Galaxy S2 con Tapatalk2®
XWLPF Stock
Siyah 4.1 beta 6
Jkay V14.1
Mario1968 said:
there is a cwm.zip for note (a temporary CWM flashable from the stock recovery like on S2)? If yes this can answer the question of tannykim.
Click to expand...
Click to collapse
yes, you are right, I didn't think of it.
So he can flash cwm.zip and from cwm flash the scanner
But again I would not stay on stock ics kernel.
Too much danger to brick again.
Btw, this cwm.zip together with the stock ics kernel will cause the brick if wiping.
Newer cm recoveries and I think current chainfire's versions don't brick with the dangerous stock ics kernel.
hg42 said:
yes, you are right, I didn't think of it.
So he can flash cwm.zip and from cwm flash the scanner
But again I would not stay on stock ics kernel.
Too much danger to brick again.
Btw, this cwm.zip together with the stock ics kernel will cause the brick if wiping.
Newer cm recoveries and I think current chainfire's versions don't brick with the dangerous stock ics kernel.
Click to expand...
Click to collapse
I do not want to stay on stock but if I do not try anything [root... Custom OS...] There will be no further issue with STOCK...
I do want to have Rocket ROM but there is no way I can get Odin file for Custom ROM. After PIT change Odin installation is more efficient from my experiences. I tried to start with GB then Root and Wipe then Flash Custom ROM in recovery, but it is not stable after these process.
I am not expert so I need someone who have better experiences and knowledge on this.......
As I already posted on PIT post, I tried more than 50 times and I found most stable method, which is
1. Odin Flashing PIT file.
2. Odin Flashing CM9 safe kernel.
3. Boot in recovery Wipe everything / format everything
4. Odin Flashing Stock ICS ROM.
I can not use my Note same as before the Bricked...[No more many apps/No more multitasking....]
However I did not have any freeze and force to restart...
Dear hg42,
As tannykim said, I don't know what is happening with may Note too, it do exactly that same as his SGN !!!!!!!!!
Now I'm able to locate the bad blocks .. and I'm surly out of these blocks in my eMMC structure now. I did everything to make sure that FACTORYFS, DATAFS, and UMS partitions are in clear blocks, even though, random restarts, freezing, and hanging all the time.
Note: RECOVERY, CACHE, and KERNEL are also in clear blocks (after running the Partition Scanner app).
I also did a check that certainly made me sure that the I'm in a clear area in UMS. I mounted my SGN in the PC after flashing a ROM, then I copied to/from anything in the UMS partition till its full (more than a time) and it works like a charm, with no hangs at all. That made me certain that these blocks are OK. Even though, it hangs!!!!!. In addition I did the following checks:
Run the Partition Scanner app and shows no errors at all.
Did the DD command scan method, and shows no errors in all partitions (from forest1971 post)
Did the e2fsck check method, and shows no errors (from forest1971 post)
I can wipe all partitions in Recovery without any errors or hangs at all
I can install all types of roms without errors, no hangs in FACTORYFS image in odin at all
Now I'm about to go mad, everything is fine, I'm out of bad blocks, even though; freezing all the time and Force Close !!!!!!!!!!!!!!! WHY??
I noticed also that ICS stock ROM installed without the Lock Screen, strange!!!
Is there any explanation of what my phone is doing?
Thanks a lot for your efforts hg42, you rock
Mohamed
tannykim said:
I do not want to stay on stock
...
I do want to have Rocket ROM but there is no way I can get Odin file for Custom ROM.
Click to expand...
Click to collapse
ok
After PIT change Odin installation is more efficient from my experiences.
Click to expand...
Click to collapse
but there should be absolutely no difference.
Either you have other problems or the emmc brick behaves different in your case.
I can imagine, that a problem like the emmc brick, which is to be located in the wear leveler could produce any kind of errors.
It may just like a faulty memory.
I remember when reviving my phone, the start offset of the bricked blocks was higher first and then moved some 100 MB.
So my very first attempt didn't work, because some good blocks changed to bad blocks, so factoryfs freezed again.
Perhaps you may scan multiple times (the more the better in this case) to be sure it works reliably...
I tried to start with GB then Root and Wipe then Flash Custom ROM in recovery, but it is not stable after these process.
Click to expand...
Click to collapse
what is unstable then?
1. Odin Flashing PIT file.
2. Odin Flashing CM9 safe kernel.
3. Boot in recovery Wipe everything / format everything
4. Odin Flashing Stock ICS ROM.
I can not use my Note same as before the Bricked...[No more many apps/No more multitasking....]
However I did not have any freeze and force to restart...
Click to expand...
Click to collapse
this shouldn't be like this. E.g. the data partition has the same size afterwards, so the maximum count of apps should be the same.
What do you mean with "no multitasking"? You cannot switch between apps or such?
With absolutely *no* multitasking the OS wouldn't work.
What happens if you install cm9 (stable) in step 4?
Btw. do you do all these tests with a clean new system without any bloat? Or do you restore apps e.g. via Titanium backup?
what is unstable then?
- It keep freeze and randomly shut down
this shouldn't be like this. E.g. the data partition has the same size afterwards, so the maximum count of apps should be the same.
What do you mean with "no multitasking"? You cannot switch between apps or such? -If I want to switch between apps. Note get freeze step and do not do anything even screen stop.-
With absolutely *no* multitasking the OS wouldn't work.
What happens if you install cm9 (stable) in step 4? -I will try to flash the Rocket Rom V10 since your OP state Odin flash is best way to install the ROM I followed your OP. However, I will try and report that.-
Btw. do you do all these tests with a clean new system without any bloat? Or do you restore apps e.g. via Titanium backup?[/QUOTE]
-I did all these tests with a clean new system without any bloat. I am not sure what bloat you means but I did not have any backup since I lost all my data from the first bricked situations HaHa-
I updated the thread starter:
* added brick finder (start and end)
* added infinite variant of scanner
* some minor cleanups and improvements
* the files now start with date and time in YYYYMMDD-HHMMSS format
tannykim said:
It keep freeze and randomly shut down
Click to expand...
Click to collapse
you may try the new indefinite scanner, may be it finds a bricked block after many iterations.
The speculative theory behind that assumes the wear leveler which assigns free blocks to a write request may sometime assign a bricked block.
This would then result in random freezes (which usually reboot the phone after many seconds, if you wait patiently).
signed zips (hopefully)
update:
the zips should now be signed.
Those with stock recovery, please report failure and success.
EDIT: someone reported the zips still don't work with stock recovery.
I assume I have to dig deeper into the signing
sry for my bad english
when i use emmc_find_brick_start.zip , it's process Stop on 834MB
when i use emmc_find_brick_end.zip , it's Stop on 3064 MB
i use ( Q1_20110914_16GB-patched-regain-1126400-kB.pit ) pit file
any better pit file for me?
biostar said:
sry for my bad english
when i use emmc_find_brick_start.zip , it's process Stop on 834MB
when i use emmc_find_brick_end.zip , it's Stop on 3064 MB
i use ( Q1_20110914_16GB-patched-regain-1126400-kB.pit ) pit file
any better pit file for me?
Click to expand...
Click to collapse
note, this is a general android thread.
I'll answer in the PIT thread instead.
signed with testsign
I updated the emmc scanner tools with another signing method applied.
Hope this works now on stock recoveries...please report success or failure
hg42 said:
I updated the emmc scanner tools with another signing method applied.
Hope this works now on stock recoveries...please report success or failure
Click to expand...
Click to collapse
Hello hg42,
I have just flashed back a stock ICS recovery to test the signature verification, but unfortunately it failed with the standard message:
Code:
E:signature verification failed
Please, let me know if you need more tests.
Best regards,
aDEO
Hello everyone,
Please, just a question about repartitioning a PIT file via Odin. I´m a bit confused about information I have read about the result of the repartitioning operation.
In some forums appear to say the repartitioning operation via Odin is, first, a values rewriting of GPT entries, and after that any kind of formatting/wipe of all partitions.
In other words, if i repartition a PIT file exactly with the same values I have in my GPT table, does nothing occurs and the content of partitions keeps, or partitions data are lost?
Sorry about my english, and thank you for any answer you can give me.
D,
hi,
if i understand correctly, you would still be performing a repartition operation , which will destroy data during the process.
Although, if you have some experience with data/forensic recovery and can get the tools ported to your tab, it's likely
you may be able to recover a fair amount of what you lose without the data being corrupted.
That being said your repartitioning would need to succeed first.
The better approach for rescuing your data would be to pull the mmcblocks/partitions off of the device and onto
your pc [Linux] as img files through ADB [android debug bridge], BEFORE YOU PERFORM THE OPERATION.
That way if you fail in repartitioning [ which is highly likely]
your data will still be preserved on your pc. To be able to pull the information/data from the device, the device must be rooted
or have a custom recovery available with properly functioning access to/through adb for root functions and adb shell as root.
questions belong in q&a by the way.
m
hi,
if i understand correctly, you would still be performing a repartition operation , which will destroy data during the process.
Click to expand...
Click to collapse
Thank you for you answer. Well, what i´m trying to do is just an "experiment" resizing partitions. Of course there are other ways to do it, but what i´m thinking about is this:
Imagine the recovery partition was located in the first memory addresses, so, in one of the first GPT entries, and what i want to do is just modifiy size of last three partitions, so, three last entries in GPT table. If i create a new PIT file exactly with the same values that i have in the GPT table of the device but only modified values for the three last GPT entries, after perform a repartitioning via Odin and restart the device the recovery will be still there?
So, that is the sense of my question: Repartitioning does only write the values in the GPT table, or besides performs any kind of data lose in partitions (wipe,formatting...) ?
questions belong in q&a by the way.
m
Click to expand...
Click to collapse
Sorry and thank you, next time i´ll pay attention to it.
On older devices I had some success resizing partitions using parted in recovery mode via adb.
parted doesn't support ext4 as far as it's useful functions goes, you would have to create/resize any partition
as ext2 and reformat from there, cute approach but more hassle/trouble than it's worth.
for your experiment, be sure you can afford a new tab ! :silly:
i'm pretty sure your block layout is hardcoded in the bootloader. So you will probably end up creating
a very fashionable serving tray.
Meaning your device won't be able to find recovery partition, also there is likely a set amount of partitions allowed
by way of kernel if i remember correctly.
If your trying to get rid of that annoying no-execute permission in data thing, getting rid of FUSE would maybe get that done.
m
Thanks again for your answer. Experiment cancelled, currently no budget for a new tab.
Just a last -and sure a stupid- question, please: In your opinion, what would happen if i extract the PIT file from my device, and use itself to repartitioning via Odin? I mean, just specifying the PIT file and marking Re-Partition, other options (PDA,Phone,etc) unmarked? After restart, could work the tablet or I´ll get a brick?
Thanks again.
Regards.
D,
hi,
That's not a stupid question at all. I would suggest you read this thread all the way through
http://forum.xda-developers.com/tab-4/help/t530nu-pit-file-t2968498
also search via your preferred engine and XDA for terms/variations
samsung pit file signed odin heimdall
so far, the chances of repairing/modifying partition table on these newer devices [samsung] is slim/grim.
However maybe utilizing external/usb-otg storages to suit your needs would be a way to go. :good:
m
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