Somebody asked me about a mod I tried on my tablet where the Cache size was decreased, giving a total of 2.95gb of internal storage. Seeing the internal storage at almost 3gb was pretty cool, although, it seemed as if the performance of the tablet decreased somewhat. After trying the mod again, noticed that some apps slowed down and others would not open. This reminded me of something learned in a college course, the instructor had said something about, the more space you have will give you better speed. Another words, if you install an 80gb hard drive with a RPM of 5400 and 4gb of RAM in your computer. Now if one were to upgrade that hard drive, without changing anything else, to 100gb with a RPM of 7200, you will notice the difference in speed. This made a little light click, thinking, well if there is more cache for apps, would the tablet run faster, in my opinion it does appear to run a little better then before.

What I noticed yesterday is that when playing with the numbers, in order to get a working number to enter in the EBR1, everything has to be in 16 bytes, so that the numbers, for the Internal Application Storage, are divisible by 32. A couple of of the caches sizes I did looked at are 126 MiB and 376 MiB. Not sure if there are any other sizes when it comes to the MTK6572, did successfully make a workable EBR1 work with a cache size of 512 MiB.

Where does the extra bytes come from? Well, if you do another math solution, it actually works out a little better when modding. Lets take a number that is divisible by 2, how about 376 MiB, and see what the hex value is.

It's 3F, using some imagination, you have to fill in the blanks zeros, x3xF is read from right to left, entered from left to right as F0 03 now here is a EBR1 from the THL TS MTK6572:

Quite slick of them wouldn't you say? This makes it so much easier, if somebody doesn't want to increase the cache by to much or decrease it to small, you just need a number that can be divided by 2. Lets play around with a random number, if the cache is 126, lets just double it, giving a value of 256.

Looking at the hexadecimal value, yes it shows 80, so one has to use their brain power. The hex total needs to be read from right to left, mentally add the 2 missing zeros from right to left then entering the hex value into the EBR1 from left to right. So the Hex value is read x8x0 then entered as 00 08.

Maybe a simple way of explainging would be, to obtain the correct numbers would be, if you are unsure of exactly what was increased/decreased, take the byte value from the original EBR1, subtract the byte value from the new byte value of the modified EBR1:

New EBR1: Partition 1: 256 MiB (268435456 bytes, 524288 sectors from 1136128) Type 0x83 (Linux)Original EBR1:Partition 1: 376 MiB (394264576 bytes, 770048 sectors from 1443328) Type 0x83 (Linux)394264576-268435456=125829120 should be added as USERDATA+FAT+125829120 if decreasing your cache.394264576-268435456=125829120 should be subtract as USERDATA+FAT-125829120 if increasing your cacheJust like the MTK6572 repartition mod for internal storage, the same rule applies, partition #2 start address needs to be one number higher then partition #1 end address.

To fix the second two hex numbers in the EBR1, this means that the end sector of partition #1, 1660415 needs to be 1660416 for the start sector of partition #2. In calculator enter 1660415 as a decimal value and you will get this:

Also, same rule applies, ignore the last two zeros and reading from right to left enter 1956 as 56 19 in your EBR1 like this:

Unlike the mod to increase the internal application storage, you do not need to worry about partition #3 end sector, this mod will not change it. If you want to move on to the next step, increasing internal application storage for MTK6572, just click the link and follow the directions according to the modified cache scatter text.

**WARNING** THIS MOD IS TRICKIER WHEN CHANGING THE CACHE PARTITION, THESE STEPS ARE IMPORTANT TO SUCCESSFULLY FLASH IN SPFLASH TOOLS

Open spflash tools, select the format tab and you need to manually format the three following areas and enter, ONE BY ONE, the linear_start_addr and partition_size according to the modified scatter.

After you have flashed, in clockwork mod recovery, restore ONLY the data and system. Do not do anything with the cache, your backup is according to the old cache size and will cause a soft brick, leaving the device stuck at the boot logo. You will need to create a new backup for future restores according to the cache size.

Monday, October 6, 2014

This is an update from my previous post, the first post works, this mod is a little simpler and when flashing the new EBR1 on the MTK6572, you will not have to do a system restore, it works almost perfectly.

Three things needed that will make this process quick and painless are:

A hex calculator, in Ubuntu, one is actually already installed, this tutorial will also teach you how to use it if you do not already know how, can also use an online hex calculator, here is a link to one. Google is also a good tool for doing mathematical functions using hexadecimal formulas, click here for an example.

A hex editing program, I prefer okteta in Ubuntu, it highlights the hex numbers, making it easier to view.

Linux can use terminal shell, not sure about windows, tried cygwin myself, just did not seem to like the EBR1 files for the MTK6572.

First thing that needs to be done is, in your MTK6572_Android_scatter.txt, you need to add the partition_size of USRDATA and FAT:

- partition_index: SYS17

partition_name: USRDATA

file_name: userdata.img

is_download: true

type: NONE

linear_start_addr: 0x43F40000

physical_start_addr: 0x43940000

partition_size: 0x20000000

region: EMMC_USER

storage: HW_STORAGE_EMMC

boundary_check: true

is_reserved: false

operation_type: UPDATE

reserve: 0x00

- partition_index: SYS18

partition_name: FAT

file_name: NONE

is_download: false

type: NONE

linear_start_addr: 0x63F40000

physical_start_addr: 0x63940000

partition_size: 0x87040000

region: EMMC_USER

storage: HW_STORAGE_EMMC

boundary_check: true

is_reserved: false

operation_type: INVISIBLE

reserve: 0x00

Open up the calculator, and under mode, select programming, now make sure that you have Hexadecimal enabled in the calculator and enter the two values, as so, and press enter:

While you have that hexadecimal value available, lets update the scatter text partition_size with the total number, in the USRDATA section, enter the total hexadecimal value, than for FAT 0x0. Found that leaving FAT as 0x0, even with the 110kb leftover internal storage forces that internal storage to become an unallocated space, this makes it easier to hide.

Now change the dropdown from hexadecimal to decimal, and divide that decimal into 32 from, then press enter:

Again, change the decimal drop down box back to hexadecimal, and this is going to be the new hex value in in Partition #2 of your EBR1. Note, in the calculator, the value is actually read from right to left but entered in the EBR1 from left to right, ignoring the 0000 at the end, as I highlighted in the calculator, the number 5382 will be entered as 82 53.

Here is an example of my EBR1 file for the Irulu 7inch MTK6572, I've highligted the first two numbers that are going to be changed:

00 00 83 00 00 00 00 06 16 00 00 C0 0B 00 00 00

00 00 83 00 00 00 00 C6 21 00 00 00 10 00 00 00

00 00 83 00 00 00 00 C6 31 00 FF 39 CE FF 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA

The 00 10 is now going to become 82 53. It is usually a good idea to save your EBR1 under a new name, it will load in SPFLASH tools under any name that you call the EBR1, in this case, it has been named as 2.5gb-EBR1.

In terminal shell, lets check the value of 2.5gb-EBR1, or whatever you chose to name yours:

As you can see, the number is exactly the value of my USRDATA+FAT, but....there is one little issue in using the entire value, all MTK6572 that this method has been tested on various devices The full value will not load, I have tried all different methods, just cannot figure out how to get it to work, this may be because the mod does not actually change your blocksmap. In terminal shell, if you type adb pull /etc/dumchar_info, before and after the mod, this is where MTKdroid tools pulls the blocks maps from, it will not be changed. There has to be a leftover value, the smallest being 110kb, in the EBR1, in order for the mod to actually work.

In the area where the old value was 00 10 but now is 82 53, for the first number, every one adds 110kb and for the second set of numbers, every one added is 32mb. The 82 need to be reduced by one, leaving a value of 81, enabling the modified EBR1 to successfully load without issues. If you want to try the full value yourself, don't be surprised when the tablet doesn't get past the boot logo.

Now in terminal, once you have reduced your first number by one, again type disktype 2.6gb-EBR1 and the value is now:

If you want, you can subtract that number from the first number, no matter what the size of your total USRDATA+FAT, it will come out to be 131072, which shows on the devices as 110kb.

The next thing is to fix the beginning and end sectors of the EBR1, in terminal enter gdisk 2.6gb-EBR1 and press p.

Number Start (sector) End (sector) Size Code Name

1 1443328 2213375 376.0 MiB 8300 Linux filesystem

2 2213376 7685887 2.6 GiB 8300 Linux filesystem

3 3261952 4294967294 2.0 TiB 8300 Linux filesystem

The end sector, 7685887 needs to be increased by one, there are two ways this can be done, I found the easiest being, taking the number, 7685887, adding one and in calculator getting the hex value, as so:

Just like before, the value 754700 is going to be read from right to left starting with 47 and ending with 75 making C631 become 47 75.

00 00 83 00 00 00 00 06 16 00 00 C0 0B 00 00

00 00 00 83 00 00 00 00 C6 21 00 00 81 53 00 00

00 00 00 83 00 00 00 00 C6 31 00 FF 39 CE FF 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA

Back in terminal shell, when typing gdisk 2.6gb-EBR1, you can see that the end sector of partition #2 is one number less then the beginning sector of partition #3. If you pay close attention though, you will notice that the end sector of partition #3 has reduced, this needs to be corrected in order for a successful flash in SPFLASH tools.

After taking a look at three different MTK6572 EBR1 files, it was discovered that all three ended with a value of 4294967294, to check for yourself, type gdisk EBR1 and you will see that indeed the value is 4294967294. To double check, gdisk your original EBR1 and check the end sector of partition #3.

What I found that works is, and if you want to try this on your own, subtracting the number, 4294967294, which is the end sector of partition #3, from the start sector of partition #3, in the original EBR1, making sure that the decimal dropdown is selected, then switch to hexadecimal, just as so:

Number Start (sector) End (sector) Size Code Name

1 1443328 2213375 376.0 MiB 8300 Linux filesystem

2 2213376 3261951 512.0 MiB 8300 Linux filesystem

3 32619524294967294 2.0 TiB 8300 Linux filesystem

Now in your original EBR1 file, you can see that is where the hex value for the number, 4294967294 comes from:

00 00 83 00 00 00 00 06 16 00 00 C0 0B 00 00

00 00 00 83 00 00 00 00 C6 21 00 00 81 53 00 00

00 00 00 83 00 00 00 00 47 75 00 FF 39 CE FF 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AAAll that has to be done is to take the same value, 4294967294, subtract that that from new start sector of partiion #3 in the 2.6gb-EBR1:

39 CE will now become B8 8A, in terminal shell, gdisk 2.6gb-EBR1 will now show:

Number Start (sector) End (sector) Size Code Name

1 1443328 2213375 376.0 MiB 8300 Linux filesystem

2 2213376 7685887 2.6 GiB 8300 Linux filesystem

3 7685888 4294967294 2.0 TiB 8300 Linux filesystem

This is going to leave a storage of 110kb for internal storage, When I tried formatting in gparted to hide, gparted said could not do anything with a size of -1mb. After a reboot it disappeared, doesn't even show in my file manager when enabling USB storage. Some system apps are gong to want to use that 110kb for various things. Google Chrome is one example, when trying to share photos in Chrome browser, if that 110kb internal storage is enabled, it will try to use it as a cache, causing a low memory error.