www.chinaphonearena.com

(2014-08-22, 23:58)tkitts Wrote: [Only registered and activated users can see links Click here to register] works well, but I agree with GrittyKitty that the sums for recalculating the EBR2 values on the last page are wrong. I used the "D" and "E" value calculations from the second page, and it worked for me.

It works, but I had a few questions which I would appreciate help with to fully understand the process
1. I tried first using asterx's excel spreadsheet - but couldn't figure out the correct hex offsets for the user partition start and length. What is the right hex offset?

2. Why doesn't the Blocks Map in MTK Droid Tools reflect the updated partition layouts? As show in the attachment, the "Free space" is correct, but the block map reflects the old layout! (1.2gb userdata, 12gb phone storage (FAT))

(2014-08-20, 12:36)over_dosis Wrote: [ -> ]

(2014-06-25, 23:33)asterx Wrote: [ -> ]

(2014-06-16, 06:38)over_dosis Wrote: [ -> ]dude, can you teach me. how to create a system partition as v3, the internal memory (13GB) = phone storage (13GB). such as merge partitions into one.

Warning: back up all Your data, as it will be lost from the phone!
According to my method You need CWM recovery, Diskinfo (from Play Store), HxD hex editor, SP Flash Tool and Your current partition info, ie. MBR and EBR files. With Diskinfo You can check the actual partition sizes and partition numbers - which is important, as that is the only information that can be used to identify the entries in the xBR files.
Get the xls from my previous post to do the calculations.
Fill up the current partitions part with the current partition info starting with MBR, then EBR1 and EBR2. If You want to change just data and internal SD partitions it is enough to copy the values for these two (or if there is any partiton definition between the two copy that as well, as the xls calculates in sequencial order). If You want to merge partitions, it's a bit more tricky, as You will have to edit the fstab as well, to remove the mount points of the removed partitions. If You want to have it simple, You leave a minimal size for the nt needed partiton, thus You don't have to edit the fstab.
So after entering the current entries, You change the sizes in the new partitions part (don't forget to extend the calculation to as many lines as You have in the current partitions part) and You get the byte values You have to enter with HxD into the xBR files. Then flash the files with SP Flash Tool and format the partitons from CWM. Now You can restore the backup, but use the advanced restore to restore the partitions one by one.

OK dude, Thanks you..
No problem dude, for partition EBR its OK.. and done for me, but I need to combine both his (internal and internalSD),Can you tell me how to change it in vold.fstab
because I only understood through vold.fstab to swap the internal SD and external SD, I do not know if to combine internal and internalSD.
Please dude tech me, how to get it like inew V3..

(2014-08-23, 14:40)petrolpro Wrote: [Only registered and activated users can see links Click here to register] works well, but I agree with GrittyKitty that the sums for recalculating the EBR2 values on the last page are wrong. I used the "D" and "E" value calculations from the second page, and it worked for me.

It works, but I had a few questions which I would appreciate help with to fully understand the process
1. I tried first using asterx's excel spreadsheet - but couldn't figure out the correct hex offsets for the user partition start and length. What is the right hex offset?

2. Why doesn't the Blocks Map in MTK Droid Tools reflect the updated partition layouts? As show in the attachment, the "Free space" is correct, but the block map reflects the old layout! (1.2gb userdata, 12gb phone storage (FAT))

(2014-01-14, 00:05)Burs Wrote: [Only registered and activated users can see links Click here to register]

Every byte has its meaning, and changing a specific one (for example the partition size) has an impact on one or more other bytes which also must reflect the new change (for example the end offset of the partition which size is beeing changed, and start offset of the next partition, if there is one).

I'm starting to believe that partition size mods are for eyes only. Sooner or later there could be a fatal problem. I just don't know what the factory format does after applying this mods? Does it retain the partition size and fix other values/bytes automaticaly? Because if it's not doing that, it could be the reason for the [Only registered and activated users can see links Click here to register] one of our forum members have.

Any thoughts about that? Oppinions? Theories?

(2014-09-06, 16:21)ferdzff Wrote: [Only registered and activated users can see links Click here to register]

Louis777

(2014-09-07, 03:36)Louis777 Wrote: [Only registered and activated users can see links Click here to register]

Louis777

Quote:In EBR1, one value is modified. In EBR2, two values are modified. For every increase in EBR1, we must make a decrease in the first value of EBR2 and an increase in the second value of EBR2.