Related
You NO larger need GParted or a Linux/Unix distro in order to make your own data.img! You NO longer need a command prompt either. However, you can use the command prompt still as an alternative option since this supports the commands in Windows. But this is an application.
With this Application you can create a brand NEW data.img or Add/Subtract space from an existing data.img. Example: You can take a 256MB data.img & make it convert to a 1GB data.img or take a 1GB data.img & make it 256MB data.img. Maximum space possible shown is based on the HDD or SD space left. So you could create a 150GB data.img if the drive had 150GB free space. It is completely safe & wont do anything to damage an existing data.img.
You will need WinRar or 7zip to extract the .RAR for this download.
WARNING!: DO NOT MAKE YOUR DATA.IMG Larger than 2GB because Android will not recognize the SD Card after. I will test this later.
1024 = 1GB
2048 = 2GB
4096 = 4GB
8192 = 8GB
Just double the #!
Screenshot:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
How to make a NEW(Fresh) Data.img:
NOTE: In order to start NEW you must have wiped your SD card or removed every file or folder such as: .REC, Cache, Android, OLD Data.img & any apps that took a folder on the card.
1. Open TopoResize
2. Select "Create New"
3. Select Save destination such as the SD Card & name it data
4. Select "Create File"
5. Select ext2 or ext3
6. Hit Ok & it will autorun.
DONE!
How to add space to an existing Data.img:
1. Open TopoResize
2. Select "Find File"
3. Locate file & select it
4. Use the size slider to select the extra space
5. Select "Resize File"
6. It will autorun
DONE!
How to subtract space to an existing Data.img:
Same instructions apply to add space just use the slider to go down & select resize file.
How to read the system.ext2 & transfer it over to the desktop:
1. Open Ext2explore
2. Select File & Open Image
3. Goto the system.ext2 & select it
4. Select Save
5. Select a destination to save it to. (Save it to a folder is preferred, so make one.)
INSTRUCTIONS TO CREATE A NEW or MODIFY EXISTING DATA.IMG via Command Prompt:
1. Open Command Prompt
2. Goto the directory of Data.img Maker
3. Enter dd if=/dev/zero bs=1M count=XXX >> data.img (XXX = Amount of Space for NEW such as 256MB is 256. Also if file is 256 already add 256 to make modified data.img = 512MB)
Alternative method! Instead of dd. You can use the following (only for new data.img):
Enter tfile data.img XXX (XXX = Size of MB ex. 1024 = 1GB. For new data.img only)
Alternative method! Instead of dd. You can use the following (only for modify data.img):
Enter Resize2fs -p data.img XXXXXX (1024*512MB=524288, always use 1024 times amount of space like 1024MB=1GB, so 1024*1024MB=1048576 for modify data.img only, can skip dd & just run this command for modify!)
4. Enter Mke2fs data.img (This will actually partition it so it doesnt come out as a bad read, MODIFY DATA IMAGE DOES NOT APPLY TO THIS STEP!)
5. Enter Resize2fs -f data.img (This will resize it for MODIFY ONLY! NOTE: can skip if you did the alternative method for existing!)
6. Enter E2fsck -f data.img (This checks to make everything is correct)
DONE!
Creating NEW Example:
d:\Software\DATA.IMG Maker\DATA.IMG Maker>dd if=/dev/zero bs=1M count=512 >> dat
a.img
rawwrite dd for windows version 0.6beta3.
Written by John Newbigin <[email protected]>
This program is covered by terms of the GPL Version 2.
512+0 records in
512+0 records out
d:\Software\DATA.IMG Maker\DATA.IMG Maker>mke2fs data.img
mke2fs 1.40.6 (09-Feb-2008)
data.img is not a block special device.
Proceed anyway? (y,n) y
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
131072 inodes, 524288 blocks
26214 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=67633152
64 block groups
8192 blocks per group, 8192 fragments per group
2048 inodes per group
Superblock backups stored on blocks:
8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 25 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
d:\Software\DATA.IMG Maker\DATA.IMG Maker>e2fsck -f data.img
e2fsck 1.40.6 (09-Feb-2008)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
data.img: 11/131072 files (9.1% non-contiguous), 18858/524288 blocks
Alternative examples:
Using tfile to create fresh data.img instead:
D:\Software\DATA.IMG Maker\DATA.IMG Maker>tfile data.img 512
data.img
sizeMB= 512
Using resize2fs only to resize w/o anything else:
D:\Software\DATA.IMG Maker\DATA.IMG Maker>resize2fs -p data.img 524288
resize2fs 1.40.6 (09-Feb-2008)
Resizing the filesystem on data.img to 524288 (1k) blocks.
Begin pass 1 (max = 30)
Extending the inode table XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
The filesystem on data.img is now 524288 blocks long.
Download HERE! (Alternate)
NEED HELP? Comment here.
FINALLY! Thanks. I'm sure this will definitely come in useful. Downloading now... Testing later.
Yeah, really appreciated! Downloaded and will try out and report back (expanding standard 256MB data .img months old to 512MB or 1GB).
Nice App
I tried this out a few days ago to see how easy it was to use and how well. It was surprisingly simple. Good app. Worked like a charm.
OK. First of all a big thanks Viper.
But -yes it IS a stupid question but i don't get it - what does this application do beside from making a data.img with various sizes. I use android now for -i think it is- a long(er) time and just want to know what i can do to explore the System .
Cheers Bieka
Bieka said:
But -yes it IS a stupid question but i don't get it - what does this application do beside from making a data.img with various sizes. I use android now for -i think it is- a long(er) time and just want to know what i can do to explore the System .
Click to expand...
Click to collapse
That's all it does... Other questions?
arrrghhh said:
That's all it does... Other questions?
Click to expand...
Click to collapse
Uhm am i kickin' myself out if i ask what this (making various sizes of a data.img file) means?! Is this the storage size android gets?
That's all it does... Other questions?
Click to expand...
Click to collapse
Uhm am i kickin' myself out if i ask what this (making various sizes of a data.img file) means?! Is this the storage size android get?
Click to expand...
Click to collapse
You kno the way if you had an android device you would have sd storage and phone storage? and phone storage would be used for apps? well this data.img is lik a virtual phone memory, When you install apps they are stored on the data.img. And for alot of of ppl 256mb isnt enough, but unlike physical harware phone memory the data.img can be made bigger. understand?
Also a big tanks viper matrix, i was looking for a way to do this a couple weeks ago, i got it sorted by using someones modified rootfs to create a new data.img but this application will probly still come in handy
Aaaaah. Thanks a lot. Now i get it Simple and obvious .
Now i can say Thanks Viper for this aplication ^^ Great Job
Worked GREAT expanding trusty months-old data.img from nearly filled up 256MB to glorious 1GB. Now Android reports memory is over 990MB!
Dead simple: run the .bat, point to data.img on SD, move slider to expand size and go. Recognized errors, corrected them, then set to it's task which took a few minutes. Done.
Superb tool, waaay too unknown to group.
Open ext2explore & goto your system.ext2 & open it & then youll be able to save it to your desktop.
Use it on the desktop & make sure its extracted into a folder.
hi!
i linked my thread to your tool if you don't mind.
posting this app in the hd2 forums would bring it a LOT of attention.
@Viper
Excellent work on these apps! I was easily able to resize my data.img. I also tried ext2explore, which works well extract items from a system.ext2. A few questions:
- Would it be possible to have the data.img resizer use standard sizes, like 524288 for 512MB, 786432 for 768MB, 1048576 for 1GB (I think you get the idea). It seems like the resizing sizes are a bit arbitrary - or is there some sort of correlation between the standard sizes and the ones selectable in the app? Or, is there a way to put these values in manually?
- In the ext2explore app, will the possibly to Copy/Cut/Paste ever be added (or drag & drop from Explorer)?
I would love to see these apps developed further .
Again, great work!
P.S. I was hoping to be able to use ext2explore to add the BLAZN theme to the FRX03 build (see this thread) - that's when I realized I couldn't copy/paste.
Viper Matrix Wireless said:
You NO larger need GParted or a Linux/Unix distro in order to make your own data.img! You NO longer need a command prompt either. However, you can use the command prompt still as an alternative option since this supports the commands in Windows. But this is an application.
With this Application you can create a brand NEW data.img or Add/Subtract space from an existing data.img. Example: You can take a 256MB data.img & make it convert to a 1GB data.img or take a 1GB data.img & make it 256MB data.img. Maximum space possible shown is based on the HDD or SD space left. So you could create a 150GB data.img if the drive had 150GB free space. It is completely safe & wont do anything to damage an existing data.img.
You will need WinRar or 7zip to extract the .RAR for this download.
WARNING!: THIS HAS NOT BEEN TESTED, DO NOT MAKE YOUR DATA.IMG Larger than 2GB because Android may not recognize the SD Card after. I will test this later.
1024 = 1GB
2048 = 2GB
4096 = 4GB
8192 = 8GB
Just double the #!
Screenshot:
How to make a NEW(Fresh) Data.img:
NOTE: In order to start NEW you must have wiped your SD card or removed every file or folder such as: .REC, Cache, Android, OLD Data.img & any apps that took a folder on the card.
1. Open TopoResize
2. Select "Create New"
3. Select Save destination such as the SD Card & name it data
4. Select "Create File"
5. Select ext2 or ext3
6. Hit Ok & it will autorun.
DONE!
How to add space to an existing Data.img:
1. Open TopoResize
2. Select "Find File"
3. Locate file & select it
4. Use the size slider to select the extra space
5. Select "Resize File"
6. It will autorun
DONE!
How to subtract space to an existing Data.img:
Same instructions apply to add space just use the slider to go down & select resize file.
How to read the system.ext2 & transfer it over to the desktop:
1. Open Ext2explore
2. Select File & Open Image
3. Goto the system.ext2 & select it
4. Select Save
5. Select a destination to save it to. (Save it to a folder is preferred, so make one.)
Download HERE!
NEED HELP? Comment here.
Click to expand...
Click to collapse
Or you just install linux and make that all with one or two mouse clicks by your self
d0nate110 said:
Or you just install linux and make that all with one or two mouse clicks by your self
Click to expand...
Click to collapse
That's not an option for everyone , so Viper's tool is very useful for those people (like me) .
Captain_Throwback said:
That's not an option for everyone , so Viper's tool is very useful for those people (like me) .
Click to expand...
Click to collapse
For me it is ONLY option, cuz with linux I can apply my lovely BLAZN theme to any Froyo etc. Release what I want
Jandyman said:
You kno the way if you had an android device you would have sd storage and phone storage? and phone storage would be used for apps? well this data.img is lik a virtual phone memory, When you install apps they are stored on the data.img. And for alot of of ppl 256mb isnt enough, but unlike physical harware phone memory the data.img can be made bigger. understand?
Also a big tanks viper matrix, i was looking for a way to do this a couple weeks ago, i got it sorted by using someones modified rootfs to create a new data.img but this application will probly still come in handy
Click to expand...
Click to collapse
making sure I understand, under sd card in settings....phone free space, this is what it does...makes that free space bigger? more storage.?
Resized the img file from 512MB to 2 gigs, but I'm using the HD2 Nexus ROM, and it doesn't report the correct disk space usage. It still shows like 65MB free as it did before resizing. The file resized properly, but the phone doesn't report that.
Normal? If not, did I do something wrong? I followed the directions...
With the advent of Blackrose custom HBOOT which gives us S-OFF, we can now resize the MTD partitions of our N1. This method is the one used by lbcoder in the Desire thread where you patch the recovery and boot in order to pass modified MTD partition information which supersedes the one provided by the SPL. Using this, I've managed to increase my userdata partition by ~50 MB by taking ~50 MB from the cache partition.
These instructions are for advanced users only. This will involve hex calculations and command line instructions that are not for the faint of heart. I don't believe it's dangerous though so anyone could still try since I will try to make these instructions as detailed as I possibly can.
What you need:
N1 with Blackrose HBOOT (I'm not sure this is needed though after I read more in-depth about the patch)
hex calculator (or a pencil & paper if you want to do it manually)
adb
fastboot
unpack-bootimg.pl
mkbootimg
recovery.img <- in my case I used ClockWorkMod 5.0.2 from here
boot.img <- taken from CM zip (in my case my KANG)
Partition Layout:
0x000003ee0000-0x000003fc0000 : "misc"
0x000004240000-0x000004640000 : "recovery"
0x000004640000-0x0000049c0000 : "boot"
0x0000049c0000-0x00000dac0000 : "system"
0x00000dac0000-0x0000139c0000 : "cache"
0x0000139c0000-0x00001fe00000 : "userdata"
Partition Sizes in Hex:
0x0000000e0000 : "misc"
0x000000400000 : "recovery"
0x000000380000 : "boot"
0x000009100000 : "system"
0x000005f00000 : "cache"
0x00000c440000 : "userdata"
Step-by-step Instructions:
A>Backup your current system: (OPTIONAL)
*I'm assuming you're using CWM 5.0.2 for the backup step since I tried using 3.X and the restore didn't work
1.) Boot your N1 into recovery using either adb reboot recovery or through the bootloader
2.) Backup your current system (I'm going to assume you know how to use your recovery for this)
B>Calculate new MTD parameter values:
*For this example I'm going to transfer ~50MB of cache space to my userdata partition:
1.) Since I know the cache partition is ~100MB in size, I'll just divide the hex size in 2:
0x5f00000 / 2 = 0x2f80000 <= this will be our new cache size
**Note that there is a minimum of 0x20000 (128k) for a partition and the size must be divisible by it which is why I'm playing safe and just dividing the original number in order to get an easier value for this example.
2.) Add the new cache partition size to the original cache partition starting address to get the new starting address of the userdata partition:
0xdac0000 + 0x2f80000 = 0x10a40000 <= this will be the new starting address for userdata
3.) Get the new userdata size by subtracting the new starting address of userdata with the ending address:
0x1fe00000 - 0x10a40000 = 0xf3c0000 <= this will be the new userdata size
C>Create a new recovery.img file which uses the new values:
1.) Breakdown the recovery.img file into it's kernel and ramdisk components using unpack-bootimg.pl:
.\unpack-bootimg.pl recovery.img
*This will yield 2 files and 1 directory. You can delete the directory since we only need the files.
2.) Rename the kernel from the recovery.img-kernel.gz made from unpack-bootimg.pl to recovery.img-kernel.
3.) Create the recovery-new.img file using mkbootimg with the new MTD command embedded:
mkbootimg --cmdline 'no_console_suspend=1 console=null mtdparts=msm_nand:[email protected](misc),[email protected](recovery),[email protected](boot),[email protected](system),[email protected](cache),[email protected](userdata)' --kernel recovery.img-kernel --ramdisk recovery.img-ramdisk.cpio.gz -o recovery-new.img --base 0x20000000
*Note that the values for cache starting address, userdata starting address and userdata size have been changed to the newly calculated values in the previous step.
**This will yield recovery-new.img which will be used in the next steps.
D>Create a new boot.img file which uses the new values:
1.) Breakdown the boot.img file into it's kernel and ramdisk components using unpack-bootimg.pl:
.\unpack-bootimg.pl boot.img
*This will yield 2 files and 1 directory. You can delete the directory since we only need the files.
2.) Rename the kernel from the boot.img-kernel.gz made from unpack-bootimg.pl to boot.img-kernel.
3.) Create the boot-new.img file using mkbootimg with the new MTD command embedded:
mkbootimg --cmdline 'no_console_suspend=1 wire.search_count=5 mtdparts=msm_nand:[email protected](misc),[email protected](recovery),[email protected](boot),[email protected](system),[email protected](cache),[email protected](userdata)' --kernel boot.img-kernel --ramdisk boot.img-ramdisk.cpio.gz -o boot-new.img --base 0x20000000
*Note that the values for cache starting address, userdata starting address and userdata size have been changed to the newly calculated values in the previous step.
**This will yield boot-new.img which will be used in the next steps.
E>Flash the recovery-new.img:
1.) Boot into bootloader and use fastboot command to flash the new recovery:
fastboot flash recovery recovery-new.img
F>Make system operational:
1.) Boot into recovery mode.
2.) Erase everything (factory reset)
3.) Either:
- Flash the ROM you took the original boot.img from OR
- Restore the backup you made previously (this only works (or has been tested) on CWM 5.0.2)
4.) DO NOT REBOOT YET!!!
G>Flash modified boot.img:
1.) Use adb to reboot to bootloader directly from recovery: (this is for safety since if you boot from an unmodified boot.img you'll have to start from F again.
adb reboot bootloader
2.) Use fastboot to flash the new boot image:
fastboot flash boot boot-new.img
3.) You may restart normally.
For those who've read this far, everything above has been rendered obsolete! Here's an editor for the SPL itself for the partition sizes:
http://intersectraven.euroskank.com/tools/SPLHexEditor.exe
*Instructions are in dla5244's thread 2nd post.
Try it at your own risk though!
Credits:
dla5244 - for bringing S-OFF to our N1 even after a looong time since its release
Firerat - for the original patch idea
Lbcoder - for coming up with the idea in the Desire thread
Reserved!
(I'm learning to reserve now... )
2 Questions:
Is the userdata space where downloaded apps go?
why didn't you choose any other partition to transfer empty space from?
drzplaya1121 said:
2 Questions:
Is the userdata space where downloaded apps go?
why didn't you choose any other partition to transfer empty space from?
Click to expand...
Click to collapse
1.) Yes.
2.) This is a sample. If you want to transfer from system or to system from cache, this example will show you how to do so.
thank U. Now I have no need to buy a new phone because of constantly running out of memory
Does it mean that every time I flash a new kernel, the whole effort will go waste?
Also, can I use the same procedure for Amon RA recovery??
rjmohit said:
Does it mean that every time I flash a new rom (which obviously has a different boot.img), the whole effort will go waste?
Also, can I use the same procedure for Amon RA recovery??
Click to expand...
Click to collapse
For that you need to do only steps D, F and G. If you flash only a kernel which uses koush's anykernel updater, you don't need to do anything.
intersectRaven said:
For that you need to do only steps D, F and G. If you flash only a kernel which uses koush's anykernel updater, you don't need to do anything.
Click to expand...
Click to collapse
Thanks.
One more silly question
Will the following procedure work.
1. Flash any ROM.
2. Then flash the modified boot.img (which may not belong to that ROM).
3. Then optionally flash the desired kernel.
rjmohit said:
Thanks.
One more silly question
Will the following procedure work.
1. Flash any ROM.
2. Then flash the modified boot.img (which may not belong to that ROM).
3. Then optionally flash the desired kernel.
Click to expand...
Click to collapse
Yeah. That would work since you're replacing the kernel anyways. What's important is that the kernel is compatible with the ROM.
Well done IR cannot wait to resize my data partition..
Okay, I extracted the recovery.img file, now when I try to extract recovery.img-kernel.gz, it gives the following error: not in gzip format. Exactly same happens for boot.img. I tried extracting it with different extractors on windows and ubuntu, nothing worked. Pls help.
I don't like using MTD because over time you will notice lag. If your already using sd-ext then your data is basically not being used. And I believe that cache never gets past 50% usage. Just putting in my two cents
rjmohit said:
Okay, I extracted the recovery.img file, now when I try to extract recovery.img-kernel.gz, it gives the following error: not in gzip format. Exactly same happens for boot.img. I tried extracting it with different extractors on windows and ubuntu, nothing worked. Pls help.
Click to expand...
Click to collapse
That's odd. In my installation, it worked flawlessly. Were there no errors during the run of unpack?
blahbl4hblah said:
I don't like using MTD because over time you will notice lag. If your already using sd-ext then your data is basically not being used. And I believe that cache never gets past 50% usage. Just putting in my two cents
Click to expand...
Click to collapse
intersectRaven said:
That's odd. In my installation, it worked flawlessly. Were there no errors during the run of unpack?
Click to expand...
Click to collapse
Nope. No errors. :-/
rjmohit said:
Nope. No errors. :-/
Click to expand...
Click to collapse
Found the problem. It seems it was never compressed in the first place. Ark sees this and just copies the file without the .gz extension.
*Instructions edited accordingly.
I may sound a bit noobish, but I'm facing one more hindrance:
How exactly do I run the mkbootimg file in the ubuntu terminal? I mean, can you give me the exact syntax?
I was facing a similar problem with the perl script, but then I found a solution on google, but didnt find anything for the mkbootimg. Can I run it under windows cmd?
rjmohit said:
I may sound a bit noobish, but I'm facing one more hindrance:
How exactly do I run the mkbootimg file in the ubuntu terminal? I mean, can you give me the exact syntax?
I was facing a similar problem with the perl script, but then I found a solution on google, but didnt find anything for the mkbootimg. Can I run it under windows cmd?
Click to expand...
Click to collapse
I already posted the syntax in the instructions. You just need to make sure the mkbootimg file has execute permissions in order for it to run.
Updated OP with SPL editor program.
intersectRaven said:
Updated OP with SPL editor program.
Click to expand...
Click to collapse
I tried your program. Everything worked fine. Just that my /cache now shows 290 MB free, while I had resized it to 20 MB!! Is that a bug? /system & /data show proper sizes though. thanks.
rjmohit said:
I tried your program. Everything worked fine. Just that my /cache now shows 290 MB free, while I had resized it to 20 MB!! Is that a bug? /system & /data show proper sizes though. thanks.
Click to expand...
Click to collapse
Is it the display on the program or display on the Android device when booted?
Wait, I found it. It's a bug. Thanks! I'll edit it when I get home. For now, please double check the values by reopening the made file before flashing. If the values are incorrect, please DON'T FLASH!!!
I Have decided that this thread has served it's purpose and will now be closed to future posts. Please direct and 'non' SHV-E160L post's to
Brixfix V2
Please can all Ongoing jobs/works migrate to the above thread.
-----------Final Notes--------------
It has been mentioned many times that i should go back and correct the information below, i started to correct a few post's then realized i was removing the flavour in change of colour and size, parts of this thread documents my mistakes, assumptions and general lack of understanding of how we NOOBS post on XDA, It's with that in mind that i have decided to leave the mistakes in, so you can see in writing what i gained from the support of other Devs here.
Now, if you are NOOB in anyway or have a few questions please click HELP
If you are bricked and need help, read this thread first, there is NO one CLICK solution for anything, even this mentioned device.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
So you Brixed/bricced/BOD/QDL/EDLOAD/QHS-USB/05c6:9008/05c6:9025/ your device? Need a Oil and brush , Need help, follow this
One, Rules
Two, Understanding
--------------------------------------------------------------------------
Tip From the Author,
Some of you may have noticed that i did not start the original thread with a question, I did something my mentor taught me at around 9 years old but didn't put into good use until much later in life.
The tip is write things down as a question for yourself, in the writing process you get to pass the information past the part of your brain that interprets information, virtual sounding board, before posting as a question for others.
--------------------------------------------------------------------------
New Tools for debricking, goto
Brixfix V2
---------------------------Further Info Info -----------------------------
** I have Since Fixed the device and developed soultions for non shv-e160l devices. Prior posts are undergoing edit's for corrections.
** if you want the glory shot, sorry you will just have to read through.
** If you are selling this as a solution, dont. I know who you are.
---------------------------Original Post-----------------------------
Hi All
As i mentioned on this thread http://forum.xda-developers.com/showthread.php?p=32231827#post32231827 i will be attempting to come up with a home grown debrick solution for a SHV-E160L samsung note from korea.
I will use the forum to document what i am doing, i am very new to this so correct me please if i am wrong. I have never done Android dev work at any time but i have a very good understanding of the logic behind it all. `
Things i Have :-
Phone ( SHV-E160L)
bus pirate v3 with jtag firmware
openocd compiled on ubuntu and centos 6
smd jtag adapter and relay wire ( magnetic wire)
things i still need :-
openocd target config file for MSM8660 Snapdragon cpu (and a better understanding of eMMC access, how to load boot loaders either into ram or eMMC or trigger fail over boot to sc-card, USB via software or X0M/Boot pins)
assembled jtag (it's the smallest soldering i've ever seen)
.PIT file for 32GB model (if someone could pull the .PIT file from a working unit I would be happy, specify your radio/kernel versions when uploading)
micro fine solder iron tip and 20w iron (i've got 60w but too high for this type of work)
Does anyone have a idea of the SD-CARD partition layout, files for snapdragon devices, google has given me much for other devices but not a snapdragon .
Another question, I've used the USB jig to trigger 301K mode USB-Factory and seen no activity in dmesg for usb devices, i've yet to try windows, does windows/linux behave in a different way when it comes to usb , as in windows see's the qualcom usb mode but not linux ? does the usb client device always start the comms?
using the 615K usb jig i get nothing too, no pbl message from samsung (hence i am led to think is's the pbl/sbl thats damaged)
My understanding up boot is as follows
iROM code
This loads basic settings to boot the PBL (iROM is in rom) the PBL is loaded into radio(modem) cpu and then loads the SBL(s)
PBL/SBL stored in eMMC at address ????? (need to document the address for the masked access to eMMC and jtag/openocd access unmasked access)
Once the SBL is loaded you with have the ODIN mode (USB/UART)
from what i can see of commercial JTAG boxes is the access the radio cpu via jtag, write a new PBL/SBL to the eMMC then halt/reset cpu which now loads the new bootloaders, (resurrect dead body)
The openocd TAP id for the cpu should be 0x105310E1 but thats a number i got from a riff box log, not any actual testing ( still need to solder the fine pitch connector)
Here is a log from a riff box, not sure if the address's are usable accross to opencd
Taken from gsm-forums:-
Open serial port...OK
Connecting to the RIFF Box...OK
Firmware Version: 1.33, JTAG Manager Version: 1.44
Selected Resurrector: [Samsung E160K V1.0.4535.7001]
Connecting to the dead body...OK
Detected dead body ID: 0x105310E1 - IGNORED!
Set I/O Voltage reads as 1.79V, TCK Frequency is RTCK
Adaptive Clocking RTCK Sampling is: [Sample at MAX]
Resurrection sequence started.
Establish communication with the phone...OK
Initializing internal hardware configuration...OK
Uploading resurrector data into memory...OK
Starting communication with resurrector...OK
Detected an Initialized FLASH1 Chip, ID: 0x0015/0x0000 (KTS00M, 0x0003AB400000 Bytes = 14.68 GB)
Detected an Initialized FLASH2 Chip, ID: 0x0015/0x0000 (KTS00M, 0x000000200000 Bytes = 2.00 MB)
Flashing the dead body...OK
Resurrection complete!
Click to expand...
Click to collapse
I did notice one thing, the riff box opens the serial port, i wonder if they load PBL+SBL into memory, reset the cpu, then using the serial connection activate download mode ? (like on the captive)
I also dont know how the cpu (jtag TAP id? ) and flash variables translate accross to openocd as ive not found a target config file yet ( or my searching is wrong)
in the full stock Firmware I was able to extract the .tar file which contained,
Code:
amss.bin <-- application cpu boot files ?
boot.img <-- kernel/initrd ramdrive
mdm.bin <-- modem cpu boot files
recovery.img <--- recovery image
system.img.ext4 <---- rest of the system applications
so i think we have the two cpu firmware/boot loaders in the .bin files, these bin files are just fat32 images, to access in ubuntu use
Code:
mount -o loop mdm.bin /mnt/mdmmountlocation
My guess is my first approach is getting the right PBL/SBL into the system and getting some feed back via uart, i have the jtag pinouts and further reserach says there is a UART2 on the jtag header, so when soldering up my jtag adapter i will include all pins if i can and sniff for serial logic, i happen to have a Open source logic sniffer, great tool as i do a lot of hacking into serial devices like scales and till printers .
back to topic.
When i do get to the jtag part at a minimum i should have access to the modem radio, afaik jtag devices connect in chains and most of the IC's that have jtag on the phones board all should link to the master device (i am thinking it's the modem cpu, no application) and that the Two cpu's share the eMMC memory some how, or it could be one cpu loads it into the other (it is connected via jtag down the chain) .
hopefully someone could correct me there.
Most of this is theory and my guess work, correct me if you find a mistake. most of the research is only over a few days too so i am far from finished there, does not help that most of the users speak a language that google translate just does not have a flair for.
Most of the info seems to suggest the modem cpu is the first inline so i decided to look further into the files there, notice the mdm.bin file is 23Mb, thats large, when mounted i notice the is a folder called 'image' ( amms.bin has folder called IMAGE , note the case difference, dont yet know whay)
in image folder we have :-
Code:
1.3M Sep 30 13:07 AMSS.MBN
35K Sep 30 13:07 DBL.MBN
2.2M Sep 30 13:07 DSP1.MBN
19M Sep 30 13:07 DSP2.MBN
40 Sep 30 13:07 EFS1.MBN
40 Sep 30 13:07 EFS2.MBN
40 Sep 30 13:07 EFS3.MBN
295K Sep 30 13:07 OSBL.MBN
Ah, i see amss.mbm , that must be the boot loader for the application cpu, DBL.MBM seems to be the PBL , OSBL.MBM could be the SBL
then there is the DSP/EFS files, I did do the command strings on all the files,
DBL.MBM does not have any text in the file that points to being able to do UART on boot, all text seems internal like pointers and references to the original build files e.g
Code:
D:\Q1LGT_MDM\MDM9600\modem_proc\core\boot\secboot2\dbl\target\mdm9x00\src\dbl_ddr.c
9x00B-SCAQSVZM-31613102
D:\Q1LGT_MDM\MDM9600\modem_proc\core\boot\secboot2\dbl\target\mdm9x00\src\dbl_sahara.c
but it also does contain data like this
Code:
auth_image
@[email protected]
@configure_hw
@flash_init
l0:eek:SBL
load_osbl_img
@DBL, Start
hw_init
so it looks more likley that dbl is first in the chain, it refers to loading osbl and configure hardware, i wonder if it means USB/UART at this stage or setting up ram and other GPIO's
in OSBL.MBM we have more interesting text
Code:
MbP?
Unable to attached to ChipInfo DAL
SAMSUNG
TOSHIBA
Flash: Failed to do initialization for probe!
ONFIx
0:ALL
Flash: Multi 2X page read not supported!
Flash: Multi 2X page write not supported!
boot_qdsps
OSBL
hw_init
hw_init_secondary
OSBL, Start
create_vector_table
ram_init
retrieve_shared
clobber_add_protection
mmu_flush_cache
OSBL, End
OSBL, Delta
osbl_sahara_load_amss
osbl_sahara_load_dsp1
osbl_sahara_load_dsp2
osbl_sahara_load_ramfs1
osbl_sahara_load_ramfs2
osbl_sahara_load_ramfs3
smem_boot_init
so it is looking more and more like DBL then SBL which then loads all of the other parts , also if you notice EFS1/2/3 are all tiny 40byte files, now i see why, they are loaded as ram-drives, so i assume those file set out the basic EFS file system in the ram.
again from research the boot stages are often counted as 3, i am assuming the real first part is in rom of the cpu (is this what triggers the qualcom download mode ) that loads DBL from eMMC and chain loads SBL
Now looking around the riff forums i see the list the info in a different way
Code:
Partition 0
SBL1
SBL2
Partition 1
RPM
SBL3
eMMC APPSBoot
TZ
.PIT
Click to expand...
Click to collapse
TZ i think is Trusted Zone
RPM - Power manager ?
now how this translates to file name from full flash and to mmcblk0p1 partitions i have yet to find out, i still dont have a .PIT file from a 32gb model
More updates to come,
regards
DarkSpr1te
CPU Boot order updates
So my digging has taken me back round to some of me early searching which i forgot about , hardware level seems to support the qualcom usb mode, but it can be disabled by manufacturer, so even if you find a resistor to the BOOT_CONFIG GPIO and ground it , it still may not work, and you could toast your board. once the qfuse is gone for that track, the maker can now use the gpio for anything else, it no longer controls the iROM branch choice ( CPU:do i start usb first or last?), it my thinking that on the first board sent out by the designers for a final production run ( those first public devices) they keep the option open to print off DEV models by changing the resistors/value of while the hardware stays same, not to be confused with dev board, that is pin/track simlar but is used to design the software mainly, sometimes hardware debug but as you change the hardware between the dev platform and production this is less helpful, google new.intrinsyc.com and apq8060, they produce a dev board that is the same as the device we hold, but everything is broken out for testing so don't expect to see this left in a bar for you to e-bay.
EDIT:
Above I refer to a dev phone and dev board, these are SURF and FFA, FFA is form factor accurate and SURF is Subscriber Unit Reference.
Here is the link, http://forum.xda-developers.com/showthread.php?t=1856327
Now from what i see, it's the same(edit:simlar) X0M pin setup as other phones, ground the right pin, reverse boot order, but this maybe two pins in the snapdragon,
[copied from other link]
Simplified table:
Code:
------------------------------------------------------------------
BC[5:0] Mapping
------------------------------------------------------------------
0b00000 Emergency Boot from SDC3 (SD) followed by USB-HS
0b00001 SDC3 followed by SDC1 (eMMC)
0b00010 SDC3 followed by SDC2 (if used)
0b00011 SDC1 (eMMC)
Click to expand...
Click to collapse
So if 0b00000 is EM boot and the docs say the the two gpio's that control this (if qfuse not blown) are taken high then it's 0b00011, so grounding those two resistors should give us 0b00000 or EM boot, the cpu docs also say they are internally grounded, the schematic says the voltage goes throught a 10k resistor, so grounding that side of the resistor that 'goes' to the cpu should change the boot order, but before trying this out, remember if you get the live side of the resistor the is no resistor between your probe and ground, that full current, short, blown, no more johnny 5.
Have you managed to unbrick the E160L?
darkspr1te said:
So my digging has taken me back round to some of me early searching which i forgot about , hardware level seems to support the qualcom usb mode, but it can be disabled by manufacturer, so even if you find a resistor to the BOOT_CONFIG GPIO and ground it , it still may not work, and you could toast your board. once the qfuse is gone for that track, the maker can now use the gpio for anything else, it no longer controls the iROM branch choice ( CPU:do i start usb first or last?), it my thinking that on the first board sent out by the designers for a final production run ( those first public devices) they keep the option open to print off DEV models by changing the resistors/value of while the hardware stays same, not to be confused with dev board, that is pin/track simlar but is used to design the software mainly, sometimes hardware debug but as you change the hardware between the dev platform and production this is less helpful, google new.intrinsyc.com and apq8060, they produce a dev board that is the same as the device we hold, but everything is broken out for testing so don't expect to see this left in a bar for you to e-bay.
Here is the link, http://forum.xda-developers.com/showthread.php?t=1856327
Now from what i see, it's the same(edit:simlar) X0M pin setup as other phones, ground the right pin, reverse boot order, but this maybe two pins in the snapdragon,
[copied from other link]
Simplified table:
Code:
------------------------------------------------------------------
BC[5:0] Mapping
------------------------------------------------------------------
0b00000 Emergency Boot from SDC3 (SD) followed by USB-HS
0b00001 SDC3 followed by SDC1 (eMMC)
0b00010 SDC3 followed by SDC2 (if used)
0b00011 SDC1 (eMMC)
So if 0b00000 is EM boot and the docs say the the two gpio's that control this (if qfuse not blown) are taken high then it's 0b00011, so grounding those two resistors should give us 0b00000 or EM boot, the cpu docs also say they are internally grounded, the schematic says the voltage goes throught a 10k resistor, so grounding that side of the resistor that 'goes' to the cpu should change the boot order, but before trying this out, remember if you get the live side of the resistor the is no resistor between your probe and ground, that full current, short, blown, no more johnny 5.
Click to expand...
Click to collapse
I think my E160L got a real brick today after I tried to flash a modified Rom downloaded from a Chinese forum. It can not be powered on after rebooting (installed successfully). I desperately need advice now on how to deal with it.
Jeff_GTA said:
I think my E160L got a real brick today after I tried to flash a modified Rom downloaded from a Chinese forum. It can not be powered on after rebooting (installed successfully). I desperately need advice now on how to deal with it.
Click to expand...
Click to collapse
Do you have any backups like nandroid ? does the 3 button boot still work ?
Regards
Have you looked into using ort-jtag. It's only about $150 (USD).
I've been looking into this myself for low-level debugging/bootloader development on SGH-T959V and SGH-I717.
All three of these devices are supported by ort-jtag and have header connectors for the jtag pins.
So I'm also getting some of these from digi-key, and making a small receptacle, much like in AdamOutler's captivate bootloader development thread. (search for k-ww)
Again, ort-jtag does support the SHV-E160L. (search that link for SHV-E160L)
PBL Dump - I think
So ive been doing some tests.
I think i managed to dump the PBL
i dumped memory and a strings search return this
Code:
pbl_error_handler.c
pbl_flash_nand.c
pbl_flash.c
dload.c
pbl_flash_nand.c
pbl_flash_onenand.c
pbl_auth\secboot_rsa_math.c
pbl_error_handler.c
pbl_auth.c
pbl_auth.c
pbl_auth.c
pbl_auth.c
pbl_auth.c
pbl_mc.c
pbl_mc.c
pbl_error_handler.c
and
Code:
qhsusb\src\dci\qhsusb_dci.c
}^PBL_DloadVER1.0
!8}^
}]^}^
Q`omm
z8}]
DEBUG
SW_ID
OEM_ID
pbl_flash_onfi.c
pbl_flash_nand.c
pbl_flash_sflashc.c
pbl_loader.c
pbl_flash_sdcc.c
pbl_auth.c
pbl_auth\secboot.c
pbl_auth\secboot_x509.c
QUALCOMM COPYRIGHT 2009BOOT ROM VERSION: 1.4QHSUSB VERSION: 00.00.08
BOOT ROM AUTHOR: DHAVAL PATEL
07 0000 SHA1
does any one want the dump that can reverse it ?
Dumps & execute address
I also need the help of other SHV-E160? owners, i need dumps from working phones, i managed to create a 8660_msimage.mbn and flashed it, but i was using i717 bootloaders and i dont think they will work, i need working dumps from working phones, starting with partition table layout, sbl1.mbn and sbl2.mbn
Does anyone know if the is is correct
SBL1 exec address 0x2A000000
SBL2 exec address 0x2E000000
as i can upload the sbl to 0x2a000000 but not the sbl2 to 0x2e000000
i can also upload the tz.mbn to 0x2a020000
i am trying to use sec boot 3 based call stack but am unsure of the real exec values
Ive seen in another post these values
"
It looks like ours deviates slightly from this.
If the headers are to be believed,
TZ is loaded at 0x2A000000
SBL3 is loaded at 0x8FF00000
APPSBL/aboot is loaded at 0x88E00000
"
the post is
http://forum.xda-developers.com/showpost.php?p=30057296&postcount=243
it does explain why i cant load into 0x2e000000
Progress
So today i made real progress, I have been able to flash a basic program to allow me to access the EMMC, i have taken a full backup and now i need to start scanning the dump for need information,
I still need help from other users so please if you are will to provide me dumps of your working device that would help me a great deal
So Part One is a sucess, I have been able to flash my own code and power on the galaxy note. next step is rebuilding the emmc partition tables, testdisk can find the partitions but is not alowing me to write a non standard partition table (which emmc seems to be formatted with)
Thanks
darkspr1te
help QPST Software Download
Hi,
I'm stuck with the same problem can you tell me what image you use to the phone. I stuck here. I' m really don't know what to do?
Thank you for your help.
tyllerdurdent said:
Hi,
I'm stuck with the same problem can you tell me what image you use to the phone. I stuck here. I' m really don't know what to do?
Thank you for your help.
Click to expand...
Click to collapse
First thing i must say is dont flash your phone just yet!! walking blindly into this could render your phone useless due to certain data being lost for good.
if you still wish to continue i will upload a basic guide and files. My method is still in development, it has many bugs ( i flashed the phone with i717 roms, working, SHV-E120 roms, working, N7000 rom complete fail)
But first some questions,
Which model phone is it?
what happened to get you to the point of needing the flash ? ( i ask so i can trace why the bricks are happening and hopefully fix it)
thank you for your help, I will be waiting your method and your files.
Thank you so much for your help.
My phone is a samsung galaxy note SHV-E160L korean version.
what happen was:
I tried to upgrade the firmware with kies and suddenly the program crash. My phone enter in an error issue with the firmware and said use emergency recovery mode.
I tried the recovery several times (uninstalling kies and install it again but that never work).
So, I download odin and this files to restore the original firmware:
CSC - GT-N7000-MULTI-CSC-OZSLPF.tar.md5
Phone - MODEM_N7000XXLR1_REV_05_CL1144476.tar.md5
Bootloader- N7000_APBOOT_N7000ZSLPF_CL558430_REV02_user_low_sh ip.tar.md5
PDA - N7000_CODE_N7000ZSLPF_CL558430_REV02_user_low_ship .tar.md5
Pit for 16GB - Q1_20110914_16GB.pit
I connect my phone and try to install the firmware again, but odin fail and my samsung became a nice brick.
The phone currently does not turn on, the phone is in download mode and I install QPST and the program recognize the system in download mode.
I want to try your method because other information I collected said that I have to send it to guarantee.
Can I install i717 rom in the E160L?
I will be waiting for your post because sincerely I don't know how to repair it.
Thank you so much.
Hello darkspr1te
First of all, nice work there (though I didn't understood most of the things there, but seems there is some good work going on on our SHV-E160's
On your comment;
( i flashed the phone with i717 roms, working, SHV-E120 roms, working, N7000 rom complete fail)
Does that mean that i717 roms can work on the SHV-E160 devices? Please share if that is the case.
The geeky bits
tyllerdurdent said:
Thank you so much for your help.
My phone is a samsung galaxy note SHV-E160L korean version.
what happen was:
I tried to upgrade the firmware with kies and suddenly the program crash. My phone enter in an error issue with the firmware and said use emergency recovery mode.
I tried the recovery several times (uninstalling kies and install it again but that never work).
So, I download odin and this files to restore the original firmware:
CSC - GT-N7000-MULTI-CSC-OZSLPF.tar.md5
Phone - MODEM_N7000XXLR1_REV_05_CL1144476.tar.md5
Bootloader- N7000_APBOOT_N7000ZSLPF_CL558430_REV02_user_low_sh ip.tar.md5
PDA - N7000_CODE_N7000ZSLPF_CL558430_REV02_user_low_ship .tar.md5
Pit for 16GB - Q1_20110914_16GB.pit
I connect my phone and try to install the firmware again, but odin fail and my samsung became a nice brick.
The phone currently does not turn on, the phone is in download mode and I install QPST and the program recognize the system in download mode.
I want to try your method because other information I collected said that I have to send it to guarantee.
Can I install i717 rom in the E160L?
I will be waiting for your post because sincerely I don't know how to repair it.
Thank you so much.
Click to expand...
Click to collapse
Ok, as i said it's still a work in progress at the moment.
I used the i717 bootloaders (thats why we have a brick as it's not getting to the aboot loader or little kernel as some other refer to it) and E160 modem and application cpu as my first target is getting odin mode back.
I was able to also use the E120 bootloaders (screen was messed up though )
I've just got home from a very long shift so i will do a full and clear write up ( STILL a work in progress ) tomorrow (20th)
but i will explain the basic now as you do need to download large files before we continue.
First you need to download the same firmware as you were originally on before the brick, The reason is because between versions i suspect there is minor changes in partition tables (that why the n7000 roms brick )
If you dont have the latest QPST (2.7.3xx or higher ) please google for it now, there are many sites that offer it. (links will folllow tomorrow)
also down load :-
ABOOT_SGH-I717M_I717MUGLA2_user_CL875155_REV00.tar (or tar.md5 )
i717-GB-Modem.tar (or .md5)
now my initital work was based off a chinese link for the A820L
http://blog.csdn.net/su_ky/article/details/7773273
To save you the time of many hours of translation and cross reference here is the quick run down
When the phone is in QDLoad mode its because the PBL (Stored in ROM , read only memory) could not start SBL1 or SBL2 , it stores the error in IRAM location 0x3FF18 and then goes to QDLoad fail mode. At this point it has tried uart, sd-card before hand and those failed too.
IRAM is the small built in memory of the MSM8660 CPU, it has not initiated the main SYSTEM ram yet so our memory space ro running code is 87k and 256k (refer to document 8960_boot_architecture.pdf found the unlock bootloaders section.
Now because our partition table and or our bootloaders are damaged (or we have emmc brick bug) we have to rewrite that data again to revive our bricks.
This is where it gets hard, and where my warnings now come into play.
right now you must think of the EMMC chip (its the name for the internal SD-CARD we boot from and store our normal data, imei and all the other data of the system, it is just a sc-card with better security for our purpose)
This emmc chip holds all of you settings for phone function and we must not loose that,
But...
we have to write data to the chip to boot again, I am not fully aware of all the memory locations so this is assumptions on my part.
we are going to write a basic bootloader that turns the whole phone into a sd-card, then write new bootloaders
using QPST we upload 8660_msimage.mbn (its a out of the box emmc factory image) this file is ment for setting up of dev versions of the phone, it made up of the following parts
sector 0 partition table or (partition0.bin AFTER patching with info from patch0.xml) I do not have a real copy of the original of this, it can be pulled from a working SVH-E160x using the code at the end.
after the MBR (which is the first part of the partiton make up, EBR follows, we can have 3 primary partitions and the fourth is a extended which is just another partiton table pointing to the next EBR and so on, upto 29 parititons i think)
anyway, after the MBR is SBL1, which chainloads SBL2 then that side loads RPM, gets a go signal then loads SBL3, when SBL3 is done most of the device hardware has been mapped into the cpu's memory table, SDRAM is now ready for larger code,
aboot now loads
some of the above loading functions occur at the same time and some wait on go signals from other code in other CPU's and some fail due corruption and or security check fails( JTAG users can watch the memory as it changes and halt, change data and continue which is why JTAGers's have more power , we dont have loader outputting data yet so no feed back, hence the brick)
when aboot is loaded we now have access to odin, so thats the goal, get aboot loaded for now who cares about the rest of the funtions.
we do need to care about those function later so thats why we will backup the entire system, i dont know if this will really work when restored and bring back all of our settings, thats later,
So onto the writing and possibly overwriting of important information, WARNING, i dont know yet if we are overwriting imei or simalr data yet so proceed at your own risk.
We will get the required from factory (qualcomm test or dev board not samsung factory in the box for consumer) from the MUI phone firmware
http://bigota.d.miui.com/QDN43/Mioneplus_QDN43_fastboot_Android_4.0_d3d83nmdk2.zip
from this zip we want 8660_msimage.mbn, patch0.xml, partition0.bin MPRG8660.hex ( this file is uploaded first, its a serial bootloader that is loaded at 0x2a000000 (start of PBL IRAM space 256k in size) and that setups a emmc to command access (we use revskill to upload the same file and dump memory , sadly ive not found a way of pulling the entire emmc to a backup, if we can figure that out we can pull the entire boot chain, fix it and send it back with what ever versions we desire, for now revskill is used to read the PBL error so we can at least see why we cant boot, not quite jtag but best we got ))
so now we have a phone running a basic bit of code that allows us to use code sent to serial port to write (possibly read) the emmc
we then use QPST to write the 8660_msimage.mbn as a one to one copy to the very start of the emmc , reboot phone and then when the phone restarts, it sets up the ram, some hardware (charging system, you will now notice your phone gets warmer that before when plugged in) and gives us direct access to the emmc as if it was a sd-card
at this point you could move the phone to any pc and it's just a sd-card branded qualcomm
BUT at this point the pc or any other computer you connect it too only see's the partition table contained in the 8660_msimage.mbn file , you other data is there so i advise the next step you MUST do.
connect the phone to a linux computer (use a live cd or live usb if you are not a normal linux user)
you will then run the following command
Code:
dd if=/dev/sd? of=/mount/location/shv-e160-full-emmc.bin bs=512
? is the letter of the drive , use dmesg and look for sdb or sdc , if you dont understand this part then i would suggest waiting for a possible script/one click solution. right now i am still booting only 1 in 20 boots and do not yet know why the boots fail and why some work.
of=/mount... this is where you will place the entire 16GB (32GB for 32gb models ) which should be a one to one copy of the system
the bs=512 is very important, it's block size, again, if you dont understand then maybe wait.
Thats enough for now, i am going to spend a hour or two working on some theories i came up with today.
user with working phones, please google how to backup parts of your phone, this may happen to you so it's best to backup asap !!!
from the blog.csd site a script to grab the partition table data, if a working usr could please run this and post the file, it does not contain user data only the partiton table and a direct 1 to 1 restore for any phone, i think it possible to write that direct back to a QDLoad mode phone, re write the bootloaders from linux and bingo working phone. i dont have backups as it's not my phone, it belongs to a client who knows i like to tinker with electronics.
anyway, once i have the partition file i can overlay it on my test phone (which i can activate QSLoad at any time, hence it's unbrick-able dev mode)
once the partition file is written to my phone, i can build a script to backup your important data, write known working bootloaders, and reboot the phone into a usable device.
here is the script in python (user linux live cd with a copy of adb, just google adb linux pack, there is a windows and linux allin one pack)
or you can get the original from the link above, i've not tested this as i dont have a device in adb mode but i've read through it and it looks sound but never tested by me.
Well i hope that enlightens you, am sorry i dont have a all in one solution for you, it's still a dev project and most of the information i have has only been collected over the past week, i only discovered it's QSDload after getting a msm8660 schematic and i still dont know what i am trully shorting out to trigger the QSDload when ever i want, even when it's booted
If any one from the unbrickable project(s) want to get in touch to share info i would be happy, i am also sure this is a usable solution for HTC phones as well
oh and one last thing
i read only a hour ago (via cell phone while in a car so not 100%) that once the phone is in QSDload and stays in QSDload on every power cycle then we can write the partition table to a SD-CARD and it will boot that, i have not tested that yet, i will try and see if the 8660_msimage.mbn file written to a sd-card works
I also suspect that some of my good boots have been when i've mixed up the sdcard with system.img.ext4 etc on it with the one with just update.zip on it. it's one my list of things to check , any suggestions are welcome as to how i correctly format the card (heads,cylinders, block size etc)
ok folks, hope this helps
COPY TEXT BELOW ONLY INTO A FILE AND RUN WITH PYTHON (linux is easier, may be possible to use a vm box, i am but linux is my main os and windows is the vm)
Code:
import os
from struct import *
def mbr():
global offset, partitions
os.popen("adb shell su -c 'dd if=/dev/block/mmcblk0 of=/cache/partition0.bin bs=512 count=1'").close()
os.popen("adb shell su -c 'cp /cache/partition0.bin /sdcard/partition0.bin'").close()
os.popen("adb pull /sdcard/partition0.bin .").close()
f = open("partition0.bin", 'rb')
data = f.read()
f.close()
partitions = [ ]
n=0
while True:
buf = data[446+(16*n):446+(16*(n+1))]
partition = dict(zip(('boot', 'id', 'start', 'size'), unpack('4I', buf)))
partition['type'] = "MBR"
n += 1
partition['no'] = n
partitions.append(partition)
if partition['id'] == 5:
offset = partition['start']
break
def ebr():
global offset, partitions
n = 0
while True:
a = 0
os.popen("adb shell su -c 'dd if=/dev/block/mmcblk0 of=/cache/ebr bs=512 count=1 skip=" + str(offset+n) + "\'").close()
n += 1
os.popen("adb shell su -c 'dd if=/cache/ebr of=/cache/partition0.bin bs=512 count=1 seek=" + str(n) + "'").close()
os.popen("adb shell su -c 'cp /cache/ebr /sdcard/partition0.bin'").close()
os.popen("adb pull /sdcard/partition0.bin .").close()
f = open("partition0.bin", 'rb')
data = f.read()
f.close()
while True:
buf = data[446+16*a:446+16*(a+1)]
partition = dict(zip(('boot', 'id', 'start', 'size'), unpack('4I', buf)))
if partition['id'] == 5:
break
if partition['id'] == 0:
return
partition['type'] = "EBR"
partition['no'] = n
partition['start'] += n-1+offset
partitions.append(partition)
a += 1
if __name__ == "__main__":
mbr()
ebr()
os.popen("adb shell su -c 'cp /cache/partition0.bin /sdcard/partition0.bin'").close()
os.popen("adb pull /sdcard/partition0.bin .").close()
for part in partitions:
print "%s %2i, Boot: 0x%02X, Id: 0x%02X, Start: 0x%08X (%8i), Size: 0x%08X (%8i, %8i KB)" % (part['type'], part['no'], part['boot'],part['id'], part['start'], part['start'], part['size'], part['size'], part['size']/2)
Click to expand...
Click to collapse
beginning
thank you for your help,
I currently have the qpst version 2.7 build 373. You think is enough of download the same version of Chinese post QPST.2.7.374.rar
I will begin to download the other files required and I will be commenting my progress.
Thank you so much for your help, i really appreciate that you share you r knowledge.
Requests
While i try some theories if othe users could possibly provide me with :-
Original partition table via script above and also via adb
use
adb and run
Code:
cat /proc/partitions > /sdcard/partitions.txt
fdisk -l /dev/block/mmcblk0 > /sdcard/fdisklist.txt
mount > /sdcard/mountlist.txt
Then on the pc side using ADB again do the following
Code:
adb pull /sdcard/partitions.txt
adb pull /sdcard/fdisklist.txt
adb pull /sdcard/mountlist.txt
and post those files.
there are many posts on it so wont repeat but later will add a link.
along with some spell checks :laugh:
if you can dump the boot loaders from a original e160x too as my data started currupt.
i also need to talk to someone who can assist me in writing a program to take the pit file and turn it into this
Code:
<?xml version="1.0" ?>
<data>
<!--NOTE: Sector size is 512bytes-->
<program file_sector_offset="0" filename="" label="SMD_HDR" num_partition_sectors="65536" physical_partition_number="0" size_in_KB="32768.0" start_sector="1"/>
<program file_sector_offset="0" filename="sbl1.mbn" label="SBL1" num_partition_sectors="1000" physical_partition_number="0" size_in_KB="500.0" start_sector="65537"/>
<program file_sector_offset="0" filename="sbl2.mbn" label="SBL2" num_partition_sectors="3000" physical_partition_number="0" size_in_KB="1500.0" start_sector="66537"/>
<program file_sector_offset="0" filename="rpm.mbn" label="RPM" num_partition_sectors="1000" physical_partition_number="0" size_in_KB="500.0" start_sector="69559"/>
<program file_sector_offset="0" filename="sbl3.mbn" label="SBL3" num_partition_sectors="4096" physical_partition_number="0" size_in_KB="2048.0" start_sector="70559"/>
<program file_sector_offset="0" filename="aboot.mbn" label="ABOOT" num_partition_sectors="5000" physical_partition_number="0" size_in_KB="2500.0" start_sector="74655"/>
<program file_sector_offset="0" filename="" label="BOOT" num_partition_sectors="20480" physical_partition_number="0" size_in_KB="10240.0" start_sector="79655"/>
<program file_sector_offset="0" filename="tz.mbn" label="TZ" num_partition_sectors="1000" physical_partition_number="0" size_in_KB="500.0" start_sector="100135"/>
<program file_sector_offset="0" filename="partition0.bin" label="MBR" num_partition_sectors="1" physical_partition_number="0" size_in_KB="0.5" start_sector="0"/>
<program file_sector_offset="1" filename="partition0.bin" label="EXT" num_partition_sectors="22" physical_partition_number="0" size_in_KB="11.0" start_sector="69537"/>
</data>
Click to expand...
Click to collapse
*edit
the partiton0.bin provided below is 8.5kb (.5kb MBR, 8kb EBR) and in raw_program0.xml bove it say 0.5kb and 11kb, making that file 11.5kb, i dont know if the A810 has larger or smaller EBR than us, it could be they pulled extra, in my reading of the dumps i've seen lots of padded 0's after files (between sbl2/ebr/rpm) anyway if you just copy paste it will throw a error, ive got it set at 0.5 and 8.
EDIT:- Do not use this file, ive uploaded newer files later on.
some of the questions i need to answer are :-
1. what is the first partition, it's dos, around 105mb and labled smd_hdr and is filled with smd_hdr.bin (or mbn)
2. what are the real sector locations of the files, above you will see the rawpartiton0.xml file, this tells QPST where in the emmc to put the data num_partiton_sectors does match data from the pit files, but i dont know the real offsets yet, (samsung or htc could put the rest of the partiton table in cpu qfuse data areas and not write it to the emmc to confuse us and write the real files to another location and use the pit file as a base+offset calculation)
start_sector is the real location on the emmc, where it starts writing the file.
at the end is partiton locations(its a generic file containing the first few byes of default partition table, patch0.xml then updates this data), i dont have our device specific figures yet, i also dont fully understand patch0.xml and the difference in figures used.
if we have a backup of each of the different version of android partitons we could just write that in replacement of partiton0.bin and we dont need patch0.xml, this file sole job to alter the generic files, oem's have the choice of changing this data.
Code:
<?xml version="1.0" ?>
<patches>
<!--NOTE: This is an ** Autogenerated file **-->
<!--NOTE: Patching is in little endian format, i.e. 0xAABBCCDD will look like DD CC BB AA in the file or on disk-->
<!--NOTE: This file is used by Trace32 - So make sure to add decimals, i.e. 0x10-10=0, *but* 0x10-10.=6.-->
<patch byte_offset="506" filename="partition0.bin" physical_partition_number="0" size_in_bytes="4" start_sector="0" value="NUM_DISK_SECTORS-208801." what="Update MBR with the length of the EXT Partition."/>
<patch byte_offset="506" filename="DISK" physical_partition_number="0" size_in_bytes="4" start_sector="0" value="NUM_DISK_SECTORS-208801." what="Update MBR with the length of the EXT Partition."/>
<patch byte_offset="458" filename="partition0.bin" physical_partition_number="0" size_in_bytes="4" start_sector="16" value="NUM_DISK_SECTORS-1695744." what="Update final partition with actual size."/>
<patch byte_offset="458" filename="DISK" physical_partition_number="0" size_in_bytes="4" start_sector="208816" value="NUM_DISK_SECTORS-1695744." what="Update final partition with actual size."/>
</patches>
Click to expand...
Click to collapse
please note that it's two lines of the same code except one is partition0.bin and the other is DISK,
Do we need both? i know if i dont add the partiton0 section used in raw_program.xml then the drive is blank in linux,
now it's my understanding that the ebr comes as the forth partiton and it point to the next one , above in patch0.xml it start at NUM_DISK_SECTORS-1695744
i am still trying to better understand these figures,
Well time to grab coffee, i guess it's a dev night in.
the file MPRG8660.HEX can be renamed EMMCBLD.HEX and it triggers QPST to always look for a QDLoad mode phone and not debug, you can place all the files you need in one folder, i advise you to keep the originals in one location and only extract what your need to your worrking folder, copy emmcswdowload.exe from the QPST folder there too, we might need to do command line work, ive read that you can pre-create images in emmcswdownload (the same way 8660_msimage.mbn was created ) that you could just drop onto a phone once it's in emmc sd-card mode, almost a one click.
More info, plus help offered
Your welcome tyllerdurdent,
I am going to be putting a few hours into the dev from now actually for if you want assistance then no problems,
I also advise the following, download ubuntu live cd, it has a lot of tools your going to need to extract data you require, if we go step by step we might be good, i did a lot of test writing before i got my first boot, and that again only happens one in 20, i dont know why.
the rawpartiton0.xml above is incorrect for our devices as it states the first partion is 32mb, (i think it's ment to be amss.mbn, or NON-HLOS.mbn , our pit file which i did extract from my emmc dump says it's 105mb. i am confused and to why rawpartiton0.xml says the first bootloader is at start_sector="65537" but fdisk shows it as start 204801, i think someone needs to show me how to convert from blocks to sectors,
in patch0.xml it says
Code:
<patch byte_offset="506" filename="partition0.bin" physical_partition_number="0" size_in_bytes="4" start_sector="0" value="NUM_DISK_SECTORS-208801." what="Update MBR with the length of the EXT Partition."/>
Click to expand...
Click to collapse
208801 is where we have our ebr start,
i also think the IROM based pbl, sbl etc use the partition types in some way, why else have so many types? can any one explain that
this is a fdisk view of what i think our partition table looks like
Code:
Device Boot Start End Blocks Id System
/dev/sdb1 1 204800 102400 c W95 FAT32 (LBA)
/dev/sdb2 * 204801 205800 500 4d QNX4.x
/dev/sdb3 205801 208800 1500 51 OnTrack DM6 Aux1
/dev/sdb4 208801 208801 0 5 Extended
/dev/sdb5 212992 213991 500 47 Unknown
/dev/sdb6 221184 225279 2048 45 Unknown
/dev/sdb7 229376 234375 2500 4c Unknown
/dev/sdb8 237568 258047 10240 48 Unknown
/dev/sdb9 262144 263143 500 46 Unknown
/dev/sdb10 270336 271335 500 5d Unknown
/dev/sdb11 278528 279527 500 91 Unknown
/dev/sdb12 286720 307199 10240 93 Amoeba
/dev/sdb13 311296 511999 100352 c W95 FAT32 (LBA)
/dev/sdb14 516096 522239 3072 4a Unknown
/dev/sdb15 524288 530431 3072 4b Unknown
/dev/sdb16 532480 538623 3072 58 Unknown
/dev/sdb17 540672 741375 100352 8f Unknown
/dev/sdb18 745472 751615 3072 59 Unknown
/dev/sdb19 753664 759807 3072 5a Unknown
/dev/sdb20 761856 29843455 14540800 5b Unknown
/dev/sdb21 770048 790527 10240 ab Darwin boot
/dev/sdb22 794624 815103 10240 60 Unknown
/dev/sdb23 819200 839679 10240 94 Amoeba BBT
/dev/sdb24 843776 3911679 1533952 a5 FreeBSD
/dev/sdb25 3915776 8114175 2099200 a6 OpenBSD
/dev/sdb26 8118272 8736767 309248 a8 Darwin UFS
/dev/sdb27 8740864 9005055 132096 a9 NetBSD
/dev/sdb28 9011200 10035199 512000 95 Unknown
/dev/sdb29 10035200 30777343 10371072 90 Unknown
Oh, download wxdhex or wimlar program, you going to need a hex editor that can load BIG files , 16gb worth
i717-GB-Modem.zip IS THE SAME AS TAR?
i717-GB-Modem.zip 21.35 MB 7 0 2012-06-30 08:45:11
I could not find the i717-gb as tar file but I find it as a zip file. but I'm not sure about thif the contents are correct. Could you check
http://d-h.st/1aP
i717-GB-Modem.zip contents
META-INF
COM
GOOGLE
ANDROID
update-binary
updater-script
TMP
amss.bin
mdm.bin
Blocks and sectors
This may explain it , the different figure in the xml files
Because sectors are logical on the drive (Logical Block Addressing = LBA) you need to convert between LBA and physical (file system) sectors. This is pretty easy to do:
First - get a table of the start and end sectors of the partition table:
Code:
[[email protected] ~]# fdisk -lu /dev/hda
Disk /dev/hda: 120.0 GB, 120034123776 bytes
255 heads, 63 sectors/track, 14593 cylinders, total 234441648 sectors
Units = sectors of 1 * 512 = 512 bytes
Device Boot Start End Blocks Id System
/dev/hda1 * 63 208844 104391 83 Linux
/dev/hda2 208845 4401809 2096482+ 83 Linux
/dev/hda3 4401810 8482319 2040255 82 Linux swap
/dev/hda4 8482320 234436544 112977112+ 5 Extended
/dev/hda5 8482383 29447144 10482381 83 Linux
/dev/hda6 29447208 50411969 10482381 83 Linux
/dev/hda7 50412033 52516484 1052226 83 Linux
/dev/hda8 52516548 234436544 90959998+ 83 Linux
Use this to determine what partition the bad sector is in. In this case 232962120 is inside the start and end values for /dev/hda5
NOTE: This is in partition 5 - ignore partition 4 as it is the extended partition. Any block from partitions 5 through 8 will also be in partition 4, but you want the real partition, not the extended partition.
Next, calculate the file system block using the formula:
b = (int)((L-S)*512/B)
where:
b = File System block number B = File system block size in bytes (almost always is 4096) L = LBA of bad sector S = Starting sector of partition as shown by fdisk -lu and (int) denotes the integer part.
For example:
The reported sector from the smart log above is 232962120, thus:
((14858312 - 8482383) * 512) / 4096 = 796991.125
^Bad Sec. ^Start Sec. ^Cha Ching! This is the sector!
(Use the block number from the smart test section, not from the smart error log section. They are using different methods of reporting file system vs. physical blocks.)
((BadBLock - StartPartition) * 512) / 4096
You can just paste this into Google as a template
Any fraction left indicates the problem sector is in the mid or latter part of the block (which contains a number of sectors). Ignore the fraction and just use the integer.
Next, use debugfs to locate the inode and then file associated with that sector:
Click to expand...
Click to collapse
[[email protected]]# debugfs
debugfs 1.35 (28-Feb-2004)
debugfs: open /dev/hda5
debugfs: icheck 796991
Block Inode number
796991 <block not found>
debugfs: quit
Ah! It didn't give the inode! It if did, you could have found the file with:
[[email protected]]# debugfs
debugfs 1.35 (28-Feb-2004)
debugfs: open /dev/hda5
debugfs: icheck 796991
Block Inode number
796991 41032
debugfs: ncheck 41032
Inode Pathname
41032 /S1/R/H/714197568-714203359/H-R-714202192-16.gwf
So what the heck? Why no inode? Well, remember how it said the sector might be bad?
Click to expand...
Click to collapse
the above copied from
http://timelordz.com/wiki/SMART_Rewriting_Bad_Sectors
i have a feeling we may need to shift our files (the basic files need to start odin are listed in rawpatch0 above, i dont know if that 100% true but it was the only files i wrote on by first sucess)
also
http://forum.xda-developers.com/showthread.php?p=31843525&postcount=13
in the above link they talk about the header of the qualcomm file
+------------+
|Dbl-preamble|
+------------+
|Dbl-header |
+------------+
|Dbl.bin |
+------------+
Click to expand...
Click to collapse
and
data_ptr = autodetectpage;
*data_ptr = sbl_header.codeword;
data_ptr++;
*data_ptr = sbl_header.magic;
data_ptr++;
*data_ptr = AUTODETECT_PAGE_SIZE_MAGIC_NUM;
Click to expand...
Click to collapse
now i used this in a way to find my bootloaders (i717 by this time, not shve-160l )
and to find the partitons
you will see in a hex editor at the start of each boot loader
something else to think about, my lack of success that last two days to produce a boot could be because my partitons are not clean , thats is to say if i write my sbl1 to 1000, and the trailing 0000 of the partition definition of my 99 block ebr/mbr ends at 999 , if i have dirt data between 999 and 1000 the cpu/pbl my interpret that as code(some of my boots is brick, some are into QDLoad, i have no pattern yet) , something i must test or confirm, or just worry about.
tyllerdurdent said:
i717-GB-Modem.zip 21.35 MB 7 0 2012-06-30 08:45:11
I could not find the i717-gb as tar file but I find it as a zip file. but I'm not sure about thif the contents are correct. Could you check
http://d-h.st/1aP
i717-GB-Modem.zip contents
META-INF
COM
GOOGLE
ANDROID
update-binary
updater-script
TMP
amss.bin
mdm.bin
Click to expand...
Click to collapse
Yes thats correct
updater script btw contains text, binary is the flashing exe i think,
Code:
run_program("/sbin/dd", "if=/tmp/mdm.bin", "of=/dev/block/mmcblk0p17");
run_program("/sbin/dd", "if=/tmp/amss.bin", "of=/dev/block/mmcblk0p13");
Click to expand...
Click to collapse
and a google of a simlar sansung product the skyrocket gives me a simlar pit layout
Device Name Size Part Name ODIN tar file Mount Point
mmcblk0boot0 512KB (empty) n/a (empty partition)
mmcblk0boot1 512KB (empty) n/a (empty partition)
mmcblk0p1 100MB SMD_HDR (partition info)
mmcblk0p2 500KB SBL1 sbl1.mbn
mmcblk0p3 1500KB SBL2 sbl2.mbn
mmcblk0p4 1KB (unnamed partition with '55 AA' MBR signature)
mmcblk0p5 500KB RPM rpm.mbn
mmcblk0p6 2MB SBL3 sbl3.mbn
mmcblk0p7 2500KB ABOOT aboot.mbn
mmcblk0p8 10MB BOOT boot.img
mmcblk0p9 500KB TZ tz.mbn
mmcblk0p10 500KB SSD n/a (empty partition)
mmcblk0p11 500KB PIT celox.pit
mmcblk0p12 10MB PARAM param.lfs
mmcblk0p13 98MB MODEM amss.bin /system/etc/firmware/misc
mmcblk0p14 3MB MSM_ST1 efs.img
mmcblk0p15 3MB MSM_ST2 n/a
mmcblk0p16 3MB MSM_FSG n/a
mmcblk0p17 98MB MDM mdm.bin /system/etc/firmware/misc_mdm
mmcblk0p18 3MB M9K_EFS1 efsclear1.bin
mmcblk0p19 3MB M9K_EFS2 efsclear2.bin
mmcblk0p20 3MB M9K_FSG n/a
mmcblk0p21 10MB DEVENC enc.img.ext4 /efs
mmcblk0p22 10MB RECOVERY recovery.img
mmcblk0p23 3MB FOTA n/a
mmcblk0p24 598MB SYSTEM system.img.ext4 /system
mmcblk0p25 2GB USERDATA userdata.img.ext4 /data
mmcblk0p26 302MB CACHE cache.img.ext4 /cache
mmcblk0p27 129MB TOMBSTONES tomb.img.ext4 /tombstones
mmcblk0p28 11.2GB UMS ums.rfs /mnt/sdcard
Click to expand...
Click to collapse
Other files
contents of the i717 boot loaders i used
ABOOT_SGH-I717M_I717MUGLA2_user_CL875155_REV00
Code:
527K Jan 6 2012 aboot.mbn
115K Jan 6 2012 rpm.mbn
72K Jan 6 2012 sbl1.mbn
111K Jan 6 2012 sbl2.mbn
601K Jan 6 2012 sbl3.mbn
117K Jan 6 2012 tz.mbn
other files pulled from
ABOOT_SGH-I717M_I717MUGLA2_user_CL875155_REV00 (no bootloader but all the other system files )
#include <std_disclaimer.h>
/*
* Your warranty is now void.
*
* I am not responsible for bricked devices, dead SD cards,
* thermonuclear war, or you getting fired because the alarm app failed. Please
* do some research if you have any concerns about features included in this ROM
* before flashing it! YOU are choosing to make these modifications, and if
* you point the finger at me for messing up your device, I will laugh at you.
*
*/
Click to expand...
Click to collapse
WARNING : MESSING WITH KERNEL AND RECOVERY PARTITIONS IS VERY DANGEROUS FOLLOW THIS GUIDE AT YOUR OWN RISK
In this guide you will learn how to increase the size of kernel and recovery partitions. the method should work for other samsung devices.
So it will be something like that .....
Before
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
After
The way we are going to increase the size of the partitions is to repartition the partition so first you must read this guide here and understand it well as we will need it .
Steps to do this are :
Repartition device memory.
Edit pit file for the device.
BEFORE DOING ANYTHING YOU SHOULD TAKE BACKUP OF THE PARTITION WE WILL WORK ON
First we will start with kernel partition and please don't touch recovery partition until you make sure that you have done all the steps correctly and your system is working then go for recovery partition
Tools will be used :
Parted : Here .
PIT editor : Here .
This method can work if you want to repartition any other partitions like data or whatever you want .
If you find anything wrong, typo, broken links or even flying elephant please let me know.
One last thing if you did like this guide or you didn't you can push that thanks button
Repartitioning device storage .
Repartitioning device storage
After you read the thread I've mentioned before... start repartitioning your device,but actually I won't write every steps of repartitioning but I'll clear some points and give you important tips when you repartition the device .
Let me clear something, the way we are going to use is that we will cut some space from any unimportant partitions and glue it to kernel or recovery partition .
Tip 1 :
So what are the unimportant and important partitions ?
Important and dangerous partitions :
PIT , MD5HDR , Product info , DSP , Modem , odin reserved , EFS , ......
Unimportant and safe partitions :
System , User data , Cache partitions
This doesn't mean that you can mess up with those partitions, it's just mean that you can only take space from those partitions without any worries of break phone functions .
Tip2 :
when you repartition the device you must know where you are and specify your situation ....
There are two situation :
Lucky one .
Unlucky one .
Lucky situation :
the lucky situation is that when your recovery and kernel partitions aren't next to any dangerous partitions.you will just cut some space of the unimportant partitions and glue it to kernel and recovery partition
like those ones ....
Unlucky situation :
the lucky situation is that when your recovery and kernel partitions are next to any dangerous partitions. so in this situation you will have to change and rearrange places of kernel and recovery partitions.
this is unlucky situation....
Tip3 :
If kernel and recovery partitions are next to each other and you're in the unlucky situation you will just need to move one partition from its place then give its space to the other partition and you should move the kernel partition and give its space for recovery partition as it's safer than moving recovery partition. In case you're in the lucky situation you will just cut the space of unimportant partition and glue it to the partition... look here :
This is unlucky situation : kernel and recovery partitions are next to each other so I'll just delete kernel partition, cut some space of system partition, make that space for kernel partition and give old kernel partition space for recovery partition .
Before :
After :
This is the lucky situation : You will remove kernel partition and safe_partition then make new kernel partition and new safe_partition, but leave some free space before kernel partition because you will add this space to recovery partition later when you make sure that you have done the steps correctly and the kernel is loaded.
Before :
After :
Tip4 :
If kernel and recovery partitions aren't next to each other and you are in lucky situation. You will cut some space and glue it to the partition you want .
And if you are in the unlucky situation you will just move the partition from its place, then cut some space from any safe partition and make this space for the kernel/recovery partition.
Tip 5 :
How much space should you make for kernel and recovery partitions ?
It's good to make each of them about 20~25 MG and don't go too high like 40 or more unless you really this much of space and keep in mind that you take this space from other partitions like system , user data or cache partitions .Also it's good to take the space from your system or cache partitions as you will not need them a lot like user-data partition .
Tip 6 :
Be organized and do everything in order So If you have to remove system and kernel partitions and you will make anything like formate or anything do it in order so first start with removing system partition and recreate it in smaller size then remove kernel partition and recreate it in the new size. WHY ? as if you just removed kernel and system partitions at the same time when you recreate them again you will end up with wrong partition number and your phone won't boot .
Tip 7 :
While you're repartitioning you will find free space at the beginning and end of your device do mess up with them they are related to bootloader and other stuff ... just act like you don't see them at all \.
Let's get started :
-What I will do is remove system partition, cut some space of it, recreate it again in new size, make new kernel partition then assign old kernel space to recovery partition. (I am in unlucky situation) .
You will need parted program to do all partitioning stuff .
-I do recommend using TWRP recovery as it's so powerful .
-Make sure to put parted program in safe place away from the partitions you will take space from it
Put parted in you internal storage .
Boot to recovery .
Plug your device to your pc .
Give parted execution permission ... open a new terminal/console and type "adb shell" then type "chmod a+x /sdcard/parted"
From current shell type "/sdcard/parted /dev/block/mmcblk0p" or "/sdcard/parted /dev/mmcblk0" if your device uses /dev/mmcblk0*" then type "unit mb" then "print". you should see some thing like that .
Then open new terminal/console , type "/sdcard/parted /dev/block/mmcblk0" or "/sdcard/parted /dev/mmcblk0" . then type "unit s" then "print". you should see some thing like that .
Remove system partition "rm 21 " . then type "print free"
Recreate system partition in the new size . "mkpart partition_name start_sector end_sector"
-I'll take 26MB from system partition so new partition size will be ( old size in sectors - the amount of space I want in sectors[(26*1024*1024)/sector_size] )
so new size will be 1,835,008 - [(26*1024*1024)/512]=1781760-To get end sector: ( start sector + partition size in sectors ) so mine will be ( 1252864 + 1781760 )=3034623
finally the command is "mkpart system 1252864 3034623"
Put a name for system partition "name partition_number new_name" the name should be like old partition name so if it was system then name it system and if it was KERNEL name it KERNEL
so mine should be "name 21 system"
Make new kernel partition and name it . "mkpart KERNEL 3034624 3087871 " -> "name 5 KERNEL" .
Also make partition instead at old kernel partition space and just name it anything then formate it as fat16 .
this steps just to make us sure that the phone is using new kernel partition not the old one .
so for me I'll do... "mkpart dummy 64512 84992" -> "name 28 dummy" -> "mkfs" -> "yes"->"28"->"fat16"
Now you will have to formate system , kernel partitions as fat16/fat32 ...type "mkfs" then type "Yes" then type partition number then type fat16 or fat32 .
-But , why ? Let's say that system partition was 1000 sectors and I made it 900 sectors only the device will still read last 100 sectors as the old filesystem type which will make errors because those 100 sectors will be kernel partition and it will be a mess .Don't worry they will be back to their old filesystem types when we restore system and kernel again .
-Why fat16 and fat32 ? Because parted only supports fat16/fat32/ext2 , and ext2 cause recovery not to mount system and kernel partitions .
-OK , which one to use fat16 or fat32 ? fat16 for small partitions like kernel and fat32 for large partitions like system .
-Now it will be like that .
I won't add the space of old kernel partition to recovery until I make sure that everything is okay.
Now I will edit pit map for my device.
After that restore kernel and system and see if the system is booting or not .
If the system booted with the new kernel partition I'll remove recovery partition so it will be merged with the old kernel space then I'll recreate recovery partition again then formate it to fat16 after that I'll edit pit file again then push it to device then put it back to its partition.
Now you can either use heimdall or odin to flash the recovery and make sure that it works well.
Edit PIT file .
Edit PIT
After you repartition kernel/recovery partition you will have to edit pit file to finish up working and make new partitions useable and make your phone work .
There is some points I should clear out first .
What is PIT file ?
It is a file contains a lot of informations about all partitions in your phone .
What is PIT used for ?
This file is used by device bootloader to know where is kernel/recovery partition to load it .
Heimdall and ODIN , they use this file to know what goes where so they know where to put kernel,recovery,system,modem and everything else .
What I'll edit in PIT file ?
You will have to edit all information for partitions you have changed them .
Let's get started :
Get pit file for your device . How ?
from parted type print and look for the partition with contains pit file . for me the file is in partition number 26 .
Copy that pit file to your sdcard or external card .
open another terminal/console then type "adb shell" then the copy command "dd if=/dev/block/block_that_contains_pit of=where_ever_you_want_to_put_pit_in/any_name.pit"
so for me I'll type "dd if=/dev/block/mmcblk0p26 of=/sdcard/mint.pit"
Pull pit file from the phone through this command . "adb pull /sdcard/mint.pit"
Open pit editor and choose "PIT file analysis" then open your pit file .
Click on "Copy to clipboard" and paste in any new text file as you will need some of those information later in case you messed anything up .
Now go to "PIT file editor tab" and open your PIT file.
PIT entry list choose the entries you will edit .
if you have edited system and kernel partitions so you will need to modify 2 entries ,but which two ?
let's say that system partition number is 15 and kernel is 9 so you will edit entries number 15 & 9 .
For my I'll edit entries number 5 and 21 .
You only will edit two values "Block size " and "Block Count" .
In "Block size" you will enter start sector of your block . and in "Block count" you will enter the size of your partition in sectors .
To get those values open new terminal/console then type "adb shell" then "/sdcard/parted /dev/block/mmcblk0" or "/sdcard/parted /dev/mmcblk0" then "unit s" then "print"
So for my system partition : block size = 1,252,864 and block count = 1,781,760
and for my kernel partition : block size = 3,034,624 and block count = 53,248
Then hit save and go to "PIT file analysis" then open your pit file . and make sure that your changes have been saved .
Now push that PIT file to your device storage and copy it back to it's own partition "adb push pit_name.pit /sdcard/mint.pit" but for you should copy it back with it's original name. to find it go to "PIT file editor " and select the entry number for pit partition . it will be the same as your pit partition number so for me my partition number is 26 so I'll select entry number 26 . then look at "Flash file name" . so for me my pit file name is mint.pit
Now copy pit file back to its partition "dd if=/sdcard/mint.pit of=/dev/block/mmcblk0p26"
Finally I'll restore kernel and system and reboot and see if the system boots or not .
For devs:If you've changed partitions sizes (cut space of them) and you're going to port a ROM or build on from source, make sure to change partitions size in BoardConfing.mk or them ROM won't boot and you'll need to reformat the partitions again. After you finished working and the ROM is stable enough to release or you just want to publish it for testing purpose make sure that you rebuild ROM with the original partitions sizes again.
Oh He left me
Cool I'll ask for divorce
one more for the future (Maybe)
If you want to make something like this for your device, check out this guide here
Since I no longer have an OP 7 series device, this mod is now deprecated and won't be receiving any more updates. @invernomut0 has made a continuation of this mod using orangefox recovery. Check it out here!
Team Win Recovery Project 3.x, or twrp3 for short, is a custom recovery built with ease of use and customization in mind. Its a fully touch driven user interface no more volume rocker or power buttons to mash. The GUI is also fully XML driven and completely theme-able. You can change just about every aspect of the look and feel.
Code:
#include <std_disclaimer.h>
/*
*
* We are not responsible for bricked devices, dead SD cards,
* thermonuclear war, or you getting fired because the alarm app failed. Please
* do some research if you have any concerns about features included in this ROM
* before flashing it! YOU are choosing to make these modifications, and if
* you point the finger at us for messing up your device, we will laugh at you.
*
*/
Compatibility
This has only been tested by me on Oxygen OS Stable - Android Q.
Disclaimer
This is a DANGEROUS mod. Anything involving repartitioning is. If you fail to read and bad things happen, that's on you. Although I thoroughly tested this (managed to brick my phone once), there's always the possibility that something could go wrong with the worst case scenario resulting in a brick.
YOU'VE BEEN WARNED - Use at your own risk
What is this?
This is @mauronofrio's TWRP (see official thread here) that's been modified for true dual booting by splitting userdata into a/b slots (also does the same for metadata for encryption support). The installer script repartitions userdata for dualboot or stock based on your input.
Limitations
See the section in the github readme. MAKE SURE YOU READ THIS!
Features:
Same as mauronofrio's TWRP
Can choose between stock layout, a/b userdata, or a/b/c userdata where 'c' is a common data partition that'll show up in both roms - it's quite handy
Option to choose between ext4 and f2fs
Disables verity - fstabs are modified for dual boot and so this is a must unless you choose stock layout in which case it's optional
Option to disable forced encryption
Option to install magisk
Common Data
I recommend the a/b/c layout which includes this common data partition
If you choose a/b/c layout - you'll have a/b userdata, but you'll also get a 3rd userdata partition I call 'Common Data'
The name 'Common Data' gives away its purpose - to store files that you'll access on both slots/roms. So stuff like zips, pictures, music, TWRP backups, etc.
In TWRP, this shows up as another storage option for backup/restore and on your pc as well - your phone will have 'Common Storage' and 'Internal Storage'
In order to be accessible when booted, some parts of the system are modified so that the it'll be accessible WITHOUT root by the following mechanisms:
- The common data partition is mounted to /sdcard/CommonData
- .nomedia file is placed in CommonData so files in it won't be picked up twice if you decide to mount over internal storage as outlined below
- Furthermore, if your use case is like mine where my music files are in common data, you can make 'mounts.txt' file in /datacommon containing a list of every FOLDER to mount directly over top of sdcard. So for example:
/datacommon/Music -> /sdcard/Music
+ This of course mounts over anything there (overwrites it for as long as it's mounted) so make sure that you don't have the same folder in both datacommon and regular data
+ Note that there are 3 exceptions to this folder mounting rule:
1) All - if this is the FIRST line, ALL folders in datacommon will be mounted
2 )Android
3) lost+found
+ The reasoning should be obvious - lost+found isn't something you should need to mess with and Android is for regular data partition only - that's OS specific and should be on separate slots
+ Note that you should have 1 folder listed on every line, for example:
Code:
DCIM
Music
Pictures
ViPER4AndroidFX
Flashing Instructions
You MUST be booted into TWRP already when flashing this zip. You can grab a bootable twrp img from here
Since this modifies data - the zip CANNOT be on sdcard or data at all UNLESS you do not want to repartition/format
- If you flash from data, the zip will copy itself to /tmp and instruct you to flash it from there OR you can just install twrp/magisk/disver-fec
- You could do the above or copy it to a place like /dev or /tmp and flash it from there
- Alternatively, you can adb sideload it
Read through ALL the prompts - there's lots of options
Note that if you change partition layout, THIS WILL WIPE ALL DATA INCLUDING INTERNAL STORAGE
How to Flash Roms - If you're NOT stock layout
Nothing changes here except ONLY FLASH IN TWRP
- Roms always flash to the opposite slot. Keep that in mind and you'll be fine
- So don't take an OTA while booted - boot into twrp, switch slots, reboot into twrp, flash rom
Normal flash procedure:
1) Boot into twrp
2) reboot into twrp selecting slot you do NOT want rom installed to
3) Flash rom
4) Flash this zip
5) Reboot into twrp
6) Flash everything else
Help! I Can't Boot!
Usually this is because you switched roms without formatting data first. This should be flashing 101 but we all forget sometimes. Plus this slot stuff can get confusing
If it only happens with a/b/c and not any other layout, there's a good chance it's selinux related. Try setting selinux to permissive at kernel level with this mod(source here). If this doesn't fix it, it could be because selinux can't be set to enforcing even with the mod depending on the rom
How to Manually Repartition Back to Stock
In the event any step in the repartioning fails, the entire installer aborts. The good news is that this prevents a potential brick. The bad is that you need to manually revert back. See the README on github for the procedure. Note that if the install went fine and you want to switch back to stock later, just flash the installer again and choose stock layout
Download
Source Code
Credits
Mauronofrio
Teamwin
CosmicDan
TopJohnWu
Very ****ing badass. ?
Wow, this is cool. Always wondered if something like this would be possible on AB partitioned devices.
Looking forward to testing it out
Does the dual boot mean I can boot two roms?
jaggillararla said:
Does the dual boot mean I can boot two roms?
Click to expand...
Click to collapse
Ya. You can have a different rom on each slot
Will it impact on my original data partition if I flashed this TWRP.( I means whether my original data being splitted into 2-individual-parition + 1-common-partition and I need to reinstall my data after entering system ?)
Kris Chen said:
Will it impact on my original data partition if I flashed this TWRP.( I means whether my original data being splitted into 2-individual-parition + 1-common-partition and I need to reinstall my data after entering system ?)
Click to expand...
Click to collapse
The installer will tell you if it'll wipe internal storage or not.
Basically, if you choose to change the partition layout, data will all be wiped since it'll be repartitioned. If you choose to keep your partition layout at the beginning of the install, your data will be fine.
You could just use this zip as twrp, magisk, verity/fec modifer/installer to save you the extra steps and keep with stock layout
This is super cool. Will be testing soon. Just to confirm, this means I can have a custom rom on one slot and oxygen os on the other? Also f2fs should work fine with common data right?
f41lbl0g said:
This is super cool. Will be testing soon. Just to confirm, this means I can have a custom rom on one slot and oxygen os on the other? Also f2fs should work fine with common data right?
Click to expand...
Click to collapse
Yup. You can do whatever you want with either slot. This mod formats all data partitions as ext4 since that's what oneplus does. You can always reformat userdata to f2fs in twrp gui later if you want though. Same goes for common data although I don't think there's a gui option for that
How does this zip to allocate the each size of userdata ? Can be customized by ourself or automated by zip itself ?
Kris Chen said:
How does this zip to allocate the each size of userdata ? Can be customized by ourself or automated by zip itself ?
Click to expand...
Click to collapse
From what I see it can not be customized through the flasher (may be possible by editing values in the zip). In case you were wondering the size of the partitions, they are 96.7gb for the common storage and 62.4gb each for the individual storages.
Kris Chen said:
How does this zip to allocate the each size of userdata ? Can be customized by ourself or automated by zip itself ?
Click to expand...
Click to collapse
f41lbl0g said:
From what I see it can not be customized through the flasher (may be possible by editing values in the zip). In case you were wondering the size of the partitions, they are 96.7gb for the common storage and 62.4gb each for the individual storages.
Click to expand...
Click to collapse
It's automated by installer. If you have a 128gb device:
32gb for each userdata slot, commondata gets what's left
256gb device:
Everything's doubled from above
Thank you for this work I have screwed up all of my partitions on my Oneplus and could use a pointer on how to restore all of the correct partitions... :-0
I must have screwed up one of the commands on restoring my original partitions here is what I have now
C:\Users\The Family>adb shell
OnePlus7Pro:/ # sgdisk /dev/block/sda --print
Creating new GPT entries.
Disk /dev/block/sda: 61409280 sectors, 234.3 GiB
Logical sector size: 4096 bytes
Disk identifier (GUID): B0281E2A-8376-4F4B-98C6-BF5221AD8A20
Partition table holds up to 128 entries
First usable sector is 6, last usable sector is 61409274
Partitions will be aligned on 256-sector boundaries
Total free space is 61409269 sectors (234.3 GiB)
Number Start (sector) End (sector) Size Code Name
OnePlus7Pro:/ #
What commands do I need to fix this. I can still get into adb shell
edit: msmtool cannot restore from this because the partitions are not correct from the way it looks when I try it. when in recovery touch does not work.
eyespunker said:
Thank you for this work I have screwed up all of my partitions on my Oneplus and could use a pointer on how to restore all of the correct partitions... :-0
I must have screwed up one of the commands on restoring my original partitions here is what I have now
C:\Users\The Family>adb shell
OnePlus7Pro:/ # sgdisk /dev/block/sda --print
Creating new GPT entries.
Disk /dev/block/sda: 61409280 sectors, 234.3 GiB
Logical sector size: 4096 bytes
Disk identifier (GUID): B0281E2A-8376-4F4B-98C6-BF5221AD8A20
Partition table holds up to 128 entries
First usable sector is 6, last usable sector is 61409274
Partitions will be aligned on 256-sector boundaries
Total free space is 61409269 sectors (234.3 GiB)
Number Start (sector) End (sector) Size Code Name
OnePlus7Pro:/ #
What commands do I need to fix this. I can still get into adb shell
edit: msmtool cannot restore from this because the partitions are not correct from the way it looks when I try it. when in recovery touch does not work.
Click to expand...
Click to collapse
I have the steps outlined here: https://github.com/Zackptg5/TWRP-DualBoot-Guac-Unified/#how-to-manually-repartition-back-to-stock
But what did you do? It looks like you formatted all of /dev/block/sda which is essentially a brick. You are able to restore that with msmtool btw but there will still be some device specific data that is lost and you'll likely need to file warranty claim
Zackptg5 said:
I have the steps outlined here: https://github.com/Zackptg5/TWRP-DualBoot-Guac-Unified/#how-to-manually-repartition-back-to-stock
But what did you do? It looks like you formatted all of /dev/block/sda which is essentially a brick. You are able to restore that with msmtool btw but there will still be some device specific data that is lost and you'll likely need to file warranty claim
Click to expand...
Click to collapse
It was this step that I really messed up
Final step is to format the new userdata partition: mke2fs -t ext4 -b 4096 /dev/block/sda$userdata_num $userdata_size - where userdata_size can be calculated with this shell command: sgdisk /dev/block/sda --print | grep "^ *$userdata_num" | awk '{print $3-$2+1}'
with this step I used the result from sgdisk /dev/block/sda --print | grep "^ *$userdata_num" | awk '{print $3-$2+1}' I do not remember the value into the spot where userdata_size was
It looks like have been able to flash partitions manually in fastboot but the two partitions that are no longer recognized are the system_a and system_b the reason I say that is because vendor and boot flash fine on both a and b partitions. and when I send the commands to flash system a or b the reply is partition not found?! I am not sure if it would fix my problem but if I could get help to restore system partitions maybe I can get this thing to boot up.
eyespunker said:
It was this step that I really messed up
Final step is to format the new userdata partition: mke2fs -t ext4 -b 4096 /dev/block/sda$userdata_num $userdata_size - where userdata_size can be calculated with this shell command: sgdisk /dev/block/sda --print | grep "^ *$userdata_num" | awk '{print $3-$2+1}'
with this step I used the result from sgdisk /dev/block/sda --print | grep "^ *$userdata_num" | awk '{print $3-$2+1}' I do not remember the value into the spot where userdata_size was
It looks like have been able to flash partitions manually in fastboot but the two partitions that are no longer recognized are the system_a and system_b the reason I say that is because vendor and boot flash fine on both a and b partitions. I am not sure if it would fix my problem but if I could get help to restore system partitions maybe I can get this thing to boot up.
Click to expand...
Click to collapse
The formatting steps is how I initially bricked my phone when I was figuring this stuff out - I since fixed that issue and made sure it'd never happen again in the zip :/
Why were you manually restoring? Did the zip cut off with partition error?
You'll need to use msmtool in this case. Even if your partition block is completely toast, it's able to bring it all back. You can grab the latest one from here: https://androidfilehost.com/?w=files&flid=296306
And here's the guide for it: https://forum.xda-developers.com/oneplus-7-pro/how-to/msm-tool-guac-t3934691
Zackptg5 said:
The formatting steps is how I initially bricked my phone when I was figuring this stuff out - I since fixed that issue and made sure it'd never happen again in the zip :/
Why were you manually restoring? Did the zip cut off with partition error?
You'll need to use msmtool in this case. Even if your partition block is completely toast, it's able to bring it all back. You can grab the latest one from here: https://androidfilehost.com/?w=files&flid=296306
And here's the guide for it: https://forum.xda-developers.com/oneplus-7-pro/how-to/msm-tool-guac-t3934691
Click to expand...
Click to collapse
When I run the latest 10.4 global I get "device does not match image" and then under status I loose connection. I have also tried the 10.31 file with no luck either.
eyespunker said:
When I run the latest 10.4 global I get "device does not match image" and then under status I loose connection. I have also tried the 10.31 file with no luck either.
Click to expand...
Click to collapse
In msmtool? Do you have the right variant?
Latest global: https://androidfilehost.com/?fid=4349826312261732245
Latest europe: https://androidfilehost.com/?fid=4349826312261732244
Download mode is really tricky too. It times out after several seconds so you pretty much have to keep holding down the key combo until msmtool picks it up and then you can release them
Zackptg5 said:
In msmtool? Do you have the right variant?
Latest global: https://androidfilehost.com/?fid=4349826312261732245
Latest europe: https://androidfilehost.com/?fid=4349826312261732244
Download mode is really tricky too. It times out after several seconds so you pretty much have to keep holding down the key combo until msmtool picks it up and then you can release them
Click to expand...
Click to collapse
I have now tried the latest two and have come up with the same results on the update when the device param load the result of the last communication is device does not match image.
eyespunker said:
I have now tried the latest two and have come up with the same results on the update when the device param load the result of the last communication is device does not match image.
Click to expand...
Click to collapse
Sounds like you may need to file a warranty claim then :/