[GUIDE]Overclocking NAND Devices with PLL2 - HTC Pico (Explorer)

/**** THIS GUIDE IS ONLY FOR ADVANCED USERS, WHO KNOW HOW TO COMPILE AND MAKE MODIFICATIONS TO KERNEL AND MODIFYING VARIOUS PARAMETERS IN RAMDISK ****/
Hello guys, here I am giving you a detailed tutorial for Overclocking devices that comes with NAND and having only PLL2 support.
Although this guide is written for HTC Explorer, the method can also be applied on similar devices.
So, before we begin you should understand the difference between OCing with PLL4 and OCing with PLL2.
XDA user @rootdefyxt320 has written an excellent post that tells the exact difference between PLL4 OC and PLL2 OC. I am quoting it:
PLL2 overclock can be compared to FSB overclocking in computers i.e locked multiplier overclocking in the BIOS. FSB overclocking involves overclocking of the PC buses such as the Memory Bus, PCI/ PCI-Express bus and AGP buses (older computers) and the CPU. It works out by XXXXMHz multiplied by X multiplier and that will give the CPU speed. PLL2 overclock does the same thing because PLL2 controls the bus speeds (exists in the SOC). It overclocks the memory buses, SOC clock, internal storage (database IO) speed and of course the CPU. It works out by XX multiplied by 19/2 and that gives the CPU speed. That's why PLL2 on 800MHz is faster in performance than PLL4 on 800MHz . Therefore that's the reason why people complain of burnt NANDs on HTC Explorer and Motorola Defy Mini XT320/321.
PLL4 overclock can be compared to unlocked multiplier overclocking where you adjust the multiplier in the BIOS and it will automatically adjust the clock speed depending on the multiplier of the CPU. Therefore this only overclocks the CPU. PLL4 overclock only overclocks the CPU and NOT the buses so it can go at much higher frequencies than PLL2 overclock. PLL4 overclock does NOT adjust bus speeds so therefore it is much safer to overclock and it doesn't burn out your SOC.
Click to expand...
Click to collapse
In case of HTC Explorer, it uses Qualcomm MSM7225A chipset. This chipset does not have PLL4 support. So the only way to overclock is by OC'ing PLL2. But OC'ing PLL2 causes not only the CPU but also everything connected to the board to OC as well. This includes the External Bus Interface (EBI). Our NAND is connected to EBI and when OC happens the Write access through NAND becomes so high causing every block in those partitions which are mounted as RW to become Bad. This is what we call "NAND BURN".
The partitions in NAND that are affected by OC are /data and /cache. This is because only these two partitons are mounted with RW access. As I mentioned above the increased Write access during OC is what causing the blocks to corrupt. All other partitions including /misc, /devlog, /boot, /system and /recovery are mounted as Read-Only and therefore are not affected.
The Workaround for this dilemma is to disable both /data and /cache partitions ( By disable, I mean not even mounting them ) in NAND and use a portion of your SDcard to act as /data and /cache. This is what we are going to do.
/* FOLLOWING PROCEDURE IS FOR AOSP ROMS ONLY */​
THE PROCEDURE
================
The procedure consists of four parts. They are listed below:
Preparing The SDcard
Kernel Level Changes
Setting Up RamDisk
Removing Memory Increasing Script
Detailed description of each part is given below:
PART 1 : Preparing The SDcard
==========================
********YOU MUST USE CLASS 10 OR ATLEAST CLASS 6 SDCARD WITH MINIMUM 8GB CAPACITY*******
CLASS 4 and CLASS 2 SDcards will definitely cause slow responsiveness because /data/data is on SDcard. Furthermore these SDcards can't handle OC at high frequencies and will die out quickly.
SO PROCEED ONLY IF YOU ARE HAVING CLASS 6 OR CLASS 10 SDCARD. YOU CAN TRY CLASS 4 SDCARD BUT YOU CAN'T OVERCLOCK ABOVE A CERTAIN LIMIT AND NO GUARANTEE ABOUT HOW LONG THE CARD WILL LAST.
We are going to create two EXT4 partitions ( First one for replacing /data and second one for replacing /cache in NAND ) on the SDcard, in addition to the normal FAT32 partition.
Using MiniTool Partition Wizard, create two EXT4 partitions as shown in following figure:
{
"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"
}
For SD-DATA, you can give whatever size you want. This where the user applications are installed.
For SD-CACHE, around 65MB is enough.
You should keep the order in which partitions are created. Partition Type for both SD-DATA and SD-CACHE should be Primary.
Assuming you have successfully prepared SDcard, lets go the second part:
PART 2 : Kernel Level Changes
==========================
First, you need to replace arch/arm/mach-msm/acpuclock-7201 with this one: https://dl.dropboxusercontent.com/u/95625633/acpuclock-7201.c
This contains the overclocked frequencies and logic to dynamically calculate PLL2 values according to different frequencies.
When you look through the overclocked frequencies, you can see I have disabled 900MHz. This is because Class 4 SDcards can't handle data rate at this frequency. Those who have Class 10 SDcards can enable and try whether it is stable for them.
**** DO NOT OC GPU. ITS FAKE AND ACTUALLY DEGRADES PERFORMANCE. REVERT GPU OC IF YOU HAVE ENABLED IT ****
Next, you need to edit the configuration file ( pico_defconfig in my case ) and enable the following option. Its disabled by default so you have to enable it:
Code:
[COLOR="Blue"][B]CONFIG_LBDAF=y[/B][/COLOR]
That's all. Now compile your kernel.
PART 3 : Setting Up RamDisk
========================
Since, we are not using /data and /cache in NAND anymore, the changes must be made in RamDisk.
All modifications are performed on init.rc file.
Open init.rc and perform the following modifications:
1. Find the following line:
Code:
[B][COLOR="Red"]mount yaffs2 [email protected] /data nosuid nodev[/COLOR][/B]
Replace the above line with following:
Code:
[B][COLOR="Blue"]# Mount SD-DATA
wait /dev/block/mmcblk0p2
wait /dev/block/mmcblk0p2
wait /dev/block/mmcblk0p2
wait /dev/block/mmcblk0p2
mount ext4 /dev/block/mmcblk0p2 /data nosuid nodev noatime nodiratime barrier=0 data=ordered commit=15 noauto_da_alloc nouser_xattr errors=continue[/COLOR][/B]
2. Now find the following line:
Code:
[B][COLOR="Red"]mount yaffs2 [email protected] /cache nosuid nodev[/COLOR][/B]
Replace the above line with following:
Code:
[B][COLOR="Blue"]# Mount SD-CACHE
wait /dev/block/mmcblk0p3
wait /dev/block/mmcblk0p3
wait /dev/block/mmcblk0p3
wait /dev/block/mmcblk0p3
mount ext4 /dev/block/mmcblk0p3 /cache nosuid nodev noatime nodiratime barrier=0 data=ordered commit=15 noauto_da_alloc nouser_xattr errors=continue[/COLOR][/B]
3. Since we are extensively using SDcard, we should adjust the read_ahead_kb parameter for maximum performance:
Add the following lines after the line: mount ext4 /dev/block/mmcblk0p3 /cache nosuid nodev noatime nodiratime barrier=0 data=ordered commit=15 noauto_da_alloc nouser_xattr errors=continue
Code:
[B][COLOR="Blue"]# SDcard read speed boost
write /sys/block/mmcblk0/bdi/read_ahead_kb 2048[/COLOR][/B]
PART 4 : Removing Memory Increasing Script
=====================================
*** This is very important. You should remove any memory increasing script that you were using. Because /data partition is now on SDcard, using memory increasing script will cause conflict and makes ROM unbootable. ***
That's all, now you can flash your favourite ROM with the new OCed boot image and enjoy overclocking.
NOTE: A new Recovery must be made to support the new /SD-CACHE partition.

/* FOLLOWING PROCEDURE IS FOR SENSE 4.1 ROM ONLY */​
THE PROCEDURE
================
The procedure consists of four parts. They are listed below:
Preparing The SDcard
Kernel Level Changes
Setting Up RamDisk
Removing Memory Increasing Script
Detailed description of each part is given below:
PART 1 : Preparing The SDcard
==========================
********YOU MUST USE CLASS 10 OR ATLEAST CLASS 6 SDCARD WITH MINIMUM 8GB CAPACITY*******
CLASS 4 and CLASS 2 SDcards will definitely cause slow responsiveness because /data/data is on SDcard. Furthermore these SDcards can't handle OC at high frequencies and will die out quickly.
SO PROCEED ONLY IF YOU ARE HAVING CLASS 6 OR CLASS 10 SDCARD. YOU CAN TRY CLASS 4 SDCARD BUT YOU CAN'T OVERCLOCK ABOVE A CERTAIN LIMIT AND NO GUARANTEE ABOUT HOW LONG THE CARD WILL LAST.
We are going to create three EXT4 partitions ( First one for /sd-ext, second one for replacing /data and third one for replacing /cache in NAND ) on the SDcard, in addition to the normal FAT32 partition.
Using MiniTool Partition Wizard, create three EXT4 partitions as shown in following figure:
For SD-EXT, around 512MB is enough. It contains only system files.
For SD-DATA, you can give whatever size you want. This where the user applications are installed.
For SD-CACHE, around 65MB is enough.
You should keep the order in which partitions are created. Partition Type for SD-EXT, SD-DATA and SD-CACHE should be Primary.
Assuming you have successfully prepared SDcard, lets go the second part:
PART 2 : Kernel Level Changes
==========================
First, you need to replace arch/arm/mach-msm/acpuclock-7201 with this one: https://dl.dropboxusercontent.com/u/95625633/acpuclock-7201.c
This contains the overclocked frequencies and logic to dynamically calculate PLL2 values according to different frequencies.
When you look through the overclocked frequencies, you can see I have disabled 900MHz. This is because Class 4 SDcards can't handle data rate at this frequency. Those who have Class 10 SDcards can enable and try whether it is stable for them.
**** DO NOT OC GPU. ITS FAKE AND ACTUALLY DEGRADES PERFORMANCE. REVERT GPU OC IF YOU HAVE ENABLED IT ****
Next, you need to edit the configuration file ( pico_defconfig in my case ) and enable the following option. Its disabled by default so you have to enable it:
Code:
[COLOR="Blue"][B]CONFIG_LBDAF=y[/B][/COLOR]
That's all. Now compile your kernel.
PART 3 : Setting Up RamDisk
========================
Since, we are not using /data and /cache in NAND anymore, the changes must be made in RamDisk.
All modifications are performed on init.rc file.
Open init.rc and perform the following modifications:
1. Find the following line:
Code:
[B][COLOR="Red"]mount yaffs2 [email protected] /data nosuid nodev[/COLOR][/B]
Replace the above line with following:
Code:
[B][COLOR="Blue"]
# Mount SD-EXT
wait /dev/block/mmcblk0p2
wait /dev/block/mmcblk0p2
wait /dev/block/mmcblk0p2
wait /dev/block/mmcblk0p2
mount ext4 /dev/block/mmcblk0p2 /sd-ext nosuid nodev noatime nodiratime barrier=0 data=ordered commit=15 noauto_da_alloc nouser_xattr errors=continue
# Mount SD-DATA
wait /dev/block/mmcblk0p3
wait /dev/block/mmcblk0p3
wait /dev/block/mmcblk0p3
wait /dev/block/mmcblk0p3
mount ext4 /dev/block/mmcblk0p3 /data nosuid nodev noatime nodiratime barrier=0 data=ordered commit=15 noauto_da_alloc nouser_xattr errors=continue
[/COLOR][/B]
2. Now find the following line:
Code:
[B][COLOR="Red"]mount yaffs2 [email protected] /cache nosuid nodev[/COLOR][/B]
Replace the above line with following:
Code:
[B][COLOR="Blue"]# Mount SD-CACHE
wait /dev/block/mmcblk0p4
wait /dev/block/mmcblk0p4
wait /dev/block/mmcblk0p4
wait /dev/block/mmcblk0p4
mount ext4 /dev/block/mmcblk0p4 /cache nosuid nodev noatime nodiratime barrier=0 data=ordered commit=15 noauto_da_alloc nouser_xattr errors=continue[/COLOR][/B]
3. Since we are extensively using SDcard, we should adjust the read_ahead_kb parameter for maximum performance:
Add the following lines after this line: mount yaffs2 [email protected] /persist nosuid nodev
Code:
[B][COLOR="Blue"]# SDcard read speed boost
write /sys/block/mmcblk0/bdi/read_ahead_kb 2048[/COLOR][/B]
PART 4 : Removing Memory Increasing Script
=====================================
*** This is very important. You should remove any memory increasing script that you were using. Because /data partition is now on SDcard, using memory increasing script will cause conflict and makes ROM unbootable. ***
That's all, now you can flash your favourite ROM with the new OCed boot image and enjoy overclocking.
NOTE: A new Recovery must be made to support the new /SD-DATA and /SD-CACHE partitions.

Our devices need new recovery that can make multiples partition :thumbup:

/* FOLLOWING PROCEDURE IS FOR SENSE 4.0a AND DERIVED ROMS ONLY */​
THE PROCEDURE
================
The procedure consists of four parts. They are listed below:
Preparing The SDcard
Kernel Level Changes
Setting Up RamDisk
Removing Memory Increasing Script
Detailed description of each part is given below:
PART 1 : Preparing The SDcard
==========================
********YOU MUST USE CLASS 10 OR ATLEAST CLASS 6 SDCARD WITH MINIMUM 8GB CAPACITY*******
CLASS 4 and CLASS 2 SDcards will definitely cause slow responsiveness because /data/data is on SDcard. Furthermore these SDcards can't handle OC at high frequencies and will die out quickly.
SO PROCEED ONLY IF YOU ARE HAVING CLASS 6 OR CLASS 10 SDCARD. YOU CAN TRY CLASS 4 SDCARD BUT YOU CAN'T OVERCLOCK ABOVE A CERTAIN LIMIT AND NO GUARANTEE ABOUT HOW LONG THE CARD WILL LAST.
We are going to create three ext2 partitions ( First one for /sd-ext, second one for replacing /data and third one for replacing /cache in NAND ) on the SDcard, in addition to the normal FAT32 partition.
Using MiniTool Partition Wizard, create three ext2 partitions as shown in following figure:
For SD-EXT, around 512MB is enough. It contains only system files.
For SD-DATA, you can give whatever size you want. This where the user applications are installed.
For SD-CACHE, around 65MB is enough.
You should keep the order in which partitions are created. Partition Type for SD-EXT, SD-DATA and SD-CACHE should be Primary.
Assuming you have successfully prepared SDcard, lets go the second part:
PART 2 : Kernel Level Changes
==========================
First, you need to replace arch/arm/mach-msm/acpuclock-7201 with this one: https://dl.dropboxusercontent.com/u/95625633/acpuclock-7201.c
This contains the overclocked frequencies and logic to dynamically calculate PLL2 values according to different frequencies.
When you look through the overclocked frequencies, you can see I have disabled 900MHz. This is because Class 4 SDcards can't handle data rate at this frequency. Those who have Class 10 SDcards can enable and try whether it is stable for them.
**** DO NOT OC GPU. ITS FAKE AND ACTUALLY DEGRADES PERFORMANCE. REVERT GPU OC IF YOU HAVE ENABLED IT ****
Next, you need to edit the configuration file ( pico_defconfig in my case ) and enable the following option. Its disabled by default so you have to enable it:
Code:
[COLOR="Blue"][B]CONFIG_LBDAF=y[/B][/COLOR]
That's all. Now compile your kernel.
PART 3 : Setting Up RamDisk
========================
Since, we are not using /data and /cache in NAND anymore, the changes must be made in RamDisk.
All modifications are performed on init.rc file.
Open init.rc and perform the following modifications:
1. Find the following line:
Code:
[B][COLOR="Red"]mount yaffs2 [email protected] /data nosuid nodev[/COLOR][/B]
Replace the above line with following:
Code:
[B][COLOR="Blue"]
# Mount SD-EXT
wait /dev/block/mmcblk0p2
wait /dev/block/mmcblk0p2
wait /dev/block/mmcblk0p2
wait /dev/block/mmcblk0p2
mount ext2 /dev/block/mmcblk0p2 /sd-ext nosuid nodev noatime nodiratime barrier=0 data=ordered commit=15 noauto_da_alloc nouser_xattr errors=continue
# Mount SD-DATA
wait /dev/block/mmcblk0p3
wait /dev/block/mmcblk0p3
wait /dev/block/mmcblk0p3
wait /dev/block/mmcblk0p3
mount ext2 /dev/block/mmcblk0p3 /data nosuid nodev noatime nodiratime barrier=0 data=ordered commit=15 noauto_da_alloc nouser_xattr errors=continue
[/COLOR][/B]
2. Now find the following line:
Code:
[B][COLOR="Red"]mount yaffs2 [email protected] /cache nosuid nodev[/COLOR][/B]
Replace the above line with following:
Code:
[B][COLOR="Blue"]# Mount SD-CACHE
wait /dev/block/mmcblk0p4
wait /dev/block/mmcblk0p4
wait /dev/block/mmcblk0p4
wait /dev/block/mmcblk0p4
mount ext2 /dev/block/mmcblk0p4 /cache nosuid nodev noatime nodiratime barrier=0 data=ordered commit=15 noauto_da_alloc nouser_xattr errors=continue[/COLOR][/B]
3. Since we are extensively using SDcard, we should adjust the read_ahead_kb parameter for maximum performance:
Add the following lines after this line: mount yaffs2 [email protected] /persist nosuid nodev
Code:
[B][COLOR="Blue"]# SDcard read speed boost
write /sys/block/mmcblk0/bdi/read_ahead_kb 2048[/COLOR][/B]
PART 4 : Removing Memory Increasing Script
=====================================
We are going to remove the memory scripts in the rom.But sense 4 roms have some of their system folder mounted to sd-ext.So to remove it we have to make some changes to the updater script
1.Find and remove all lines in the updater script with sd-ext in them.
2.Next paste the following lines just after the line "package_extract_dir("system", "/system");"
Code:
[B][COLOR="Blue"]
ui_print("Mounting sd-ext");
ui_print("------------------");
run_program("/sbin/mkdir", "/sd-ext");
run_program("/sbin/busybox", "mount", "-t", "auto", "/dev/block/mmcblk0p2", "/sd-ext");
ui_print("Preparing sd-ext for flashing");
ui_print("------------------");
run_program("/sbin/mkdir","/sd-ext/app_s");
set_progress(0.25);
ui_print("Flashing stuff to sd-ext");
ui_print("------------------");
package_extract_dir("sd-ext/app_s", "/sd-ext/app_s");
set_perm_recursive(0, 0, 0755, 0644, "/sd-ext/app_s");
ui_print("Linking /sd-ext contents to /system");
ui_print("-----------------------------------");
symlink("/sd-ext/app_s", "/system/app");[/COLOR][/B]
3.(Rom dependend):Some Sense 4 roms have more folders in sd-ext.To know that just check in the sd-ext folder of your rom.zip.Then add the required lines under right sections.
Code:
[B][COLOR="Blue"]
ui_print("Preparing sd-ext for flashing");
ui_print("------------------");
run_program("/sbin/mkdir","/sd-ext/system_s");
run_program("/sbin/mkdir","/sd-ext/usr_s");
run_program("/sbin/mkdir","/sd-ext/media_s");
ui_print("Flashing stuff to sd-ext");
ui_print("------------------");
package_extract_dir("sd-ext/media_s", "/sd-ext/media_s");
package_extract_dir("sd-ext/usr_s", "/sd-ext/usr_s");
package_extract_dir("sd-ext/system_s", "/sd-ext/system_s");
set_perm_recursive(0, 0, 0755, 0644, "/sd-ext/media_s");
set_perm_recursive(0, 0, 0755, 0644, "/sd-ext/usr_s");
set_perm_recursive(0, 0, 0755, 0644, "/sd-ext/system_s");
package_extract_dir("bootanimation", "/sd-ext/media_s");
ui_print("Linking /sd-ext contents to /system");
ui_print("-----------------------------------");
symlink("/sd-ext/usr_s", "/system/usr");
symlink("/sd-ext/system_s", "/system/app");
symlink("/sd-ext/media_s", "/system/media");[/COLOR][/B]
4.Now remove the memory script. Try to find the name of the memory script as it is different for different roms.
*** This is very important. You should remove any memory increasing script that you were using. Because /data partition is now on SDcard, using memory increasing script will cause conflict and makes ROM unbootable. ***
NOTE: A new Recovery must be made to support the new /SD-DATA and /SD-CACHE partitions.

abhinavthms said:
Trying now....
Click to expand...
Click to collapse
This method is only for Cyanogenmod ROMs. Dont try with Sense ROMs. For Sense ROMs, some modifications are required in the procedure.

cute_prince said:
This method is only for Cyanogenmod ROMs. Dont try with Sense ROMs. For Sense ROMs, some modifications are required in the procedure.
Click to expand...
Click to collapse
Wht if carbon, jellybeer etc, ??
Sent from my HTC Explorer A310e using xda app-developers app

sanpedro_bonita said:
Wht if carbon, jellybeer etc, ??
Sent from my HTC Explorer A310e using xda app-developers app
Click to expand...
Click to collapse
Should work on all aosp based ROMs

If I understand you correctly ,
Will overclocking Burn NAND if I mount /system as RW with Root explorer or adb remount ??

Thanks a ton man !!!
btw i tried it on aokp JB and it DOES WORK
i even uploaded a boot.img for the masses to try out... here : http://forum.xda-developers.com/showpost.php?p=42929950&postcount=282
but one thing i've noticed that if we mount the whole data.. but still wouldn't it affect nand some where.. ?
@cute_prince did you try dsmeg ? did it show any bad blocks ?

ayushrox said:
Thanks a ton man !!!
btw i tried it on aokp JB and it DOES WORK
i even uploaded a boot.img for the masses to try out... here : http://forum.xda-developers.com/showpost.php?p=42929950&postcount=282
but one thing i've noticed that if we mount the whole data.. but still wouldn't it affect nand some where.. ?
@cute_prince did you try dsmeg ? did it show any bad blocks ?
Click to expand...
Click to collapse
No it wont affect any Read-Only portions of NAND. I have already told the reason in OP. Seems like you didnt read it
Yes, I regularly checked dmesg and there is no Bad Block.
The partitions in NAND that are affected by OC are /data and /cache. This is because only these two partitons are mounted with RW access. As I mentioned above the increased Write access during OC is what causing the blocks to corrupt. All other partitions including /misc, /devlog, /boot, /system and /recovery are mounted as Read-Only and therefore are not affected.
Click to expand...
Click to collapse

satiz said:
If I understand you correctly ,
Will overclocking Burn NAND if I mount /system as RW with Root explorer or adb remount ??
Click to expand...
Click to collapse
It's possible. It can also burn your recovery if you try to flash it from phone using "flash_image". So DO NOT try mounting system as rw and always use fastboot for flashing recovery

satiz said:
If I understand you correctly ,
Will overclocking Burn NAND if I mount /system as RW with Root explorer or adb remount ??
Click to expand...
Click to collapse
There is a high probability. But dont worry, before mounting System as RW, set frequency to 600MHz. After System is unmounted you can restore OverClock

Can we use data and cache partions as system because They are now directed to sd card this will increase the size of system ...??

@cute_prince
Awesome job man
i was at hospital,,feeling bad bcuz injured but this great news make me happy
Thanks man

cute_prince said:
3. Since we are extensively using SDcard, we should adjust the read_ahead_kb parameter for maximum performance:
Add the following lines after this line: mount yaffs2 [email protected] /persist nosuid nodev
Code:
[B][COLOR="Blue"]# SDcard read speed boost
write /sys/block/mmcblk0/bdi/read_ahead_kb 2048[/COLOR][/B]
Click to expand...
Click to collapse
Dude i cant find the line you stated below which i have to add read_ahead line
so i randomly added that line and now am stuck at htc screen!

ateeq72 said:
Dude i cant find the line you stated below which i have to add read_ahead line
so i randomly added that line and now am stuck at htc screen!
Click to expand...
Click to collapse
Upload your init.rc

cute_prince said:
Upload your init.rc
Click to expand...
Click to collapse
here you go bro!
http://www.mediafire.com/download/hhvdsdzcesm6chi/init.rc
try fixing this or else just upload your Ramdisk! and thanks for damn fast reply!

cute_prince said:
No it wont affect any Read-Only portions of NAND. I have already told the reason in OP. Seems like you didnt read it
Yes, I regularly checked dmesg and there is no Bad Block.
Click to expand...
Click to collapse
oops sorry my bad.. :angel:
but gr8 work anyway
---------- Post added at 06:58 PM ---------- Previous post was at 06:52 PM ----------
ateeq72 said:
here you go bro!
http://www.mediafire.com/download/hhvdsdzcesm6chi/init.rc
try fixing this or else just upload your Ramdisk! and thanks for damn fast reply!
Click to expand...
Click to collapse
hey bro,you can paste that just below the cache mounting..

ayushrox said:
hey bro,you can paste that just below the cache mounting..
Click to expand...
Click to collapse
bro i just did what you said but now am kinda getting bootloops the the 'htc' splash screen shows for a while and then goes blank and then shows up again! and this process repeats!.

@cute_prince
If we are using SD card for data and cache partition wouldn't it will decrease performance as internal is faster than SD card

Related

Journal Disabler For Pico! :D

----------------------- Journaling Disabler For Pico ----------------------
This is just a simple Zip to Disable Journaling on pico! as we use 2 or 3 extra ext4 partitions for OC!
It even clear's /sd-data,/sd-cache - for aosp
and /sd-ext,/sd-data,/sd-cache - for sense 4
Which means you need not always format your sd-card to switch between roms! .. But if you are switching from aosp rom to sense 4 you need to partition the sd-card appropriately!
Steps to USE:
******* Use this Zip Only when installing a Rom from scratch!... cause it wipes everything! ******
-- clear almost everything you can from recovery e.g factory-reset,/system,/boot,/cache etc
-- install this Zip! as like you do with any other zip (Prefered Recovery TWRP 2.4.X)
-- Flash Your Favourite Rom Now!!
I can use this even if i am not oc'ing?? Just like superwipe?
Disabling journal wont harm anything! Right?
Parth_14 said:
I can use this even if i am not oc'ing?? Just like superwipe?
Disabling journal wont harm anything! Right?
Click to expand...
Click to collapse
From the wikipedia's article:
A journaling file system is a file system that keeps track of the changes that will be made in a journal (usually a circular log in a dedicated area of the file system) before committing them to the main file system. In the event of a system crash or power failure, such file systems are quicker to bring back online and less likely to become corrupted.[1]
Click to expand...
Click to collapse
For overclocking, the SD Card is used for the /data and /cache partition. In that case, the SD Card would be read more frequently as the /data and /cache partitions are the most frequently accessed and modified partitions while running the Android system. In that case, using a Journal would slow down the memory access times if the SD Card is not fast enough. Also, as many modifications are made to the /data and /cache partition, the SD Card would be going through the read/write cycle twice the number of times, once for the journaling and once for the "commiting them to the main file system". So, it is likely that the SD Card might get corrupted faster than it normally should. That is the reason why Class 4 and below SD Cards are likely to "go dead" soon when overclocking with cute_prince's new PLL2 overclocking method. And, this is why ateeq72 has made this flashable zip to disable journaling. It would reduce the possibility/risk of losing your SD Card and at the same time allow you to OC your phone.
Using this when you are not OC'ing your phone? I wouldn't recommend that you flash this zip, but you would need a slightly modified zip. Also, journaling, I presume you want to disable in your phone's sd-ext memory. It would increase your phone's performance in case you are using any memory increasing scripts like int2ext which mount the sd-ext partition in the /data folder.
vineethraj49 said:
Using this when you are not OC'ing your phone? I wouldn't recommend that you flash this zip, but you would need a slightly modified zip. Also, journaling, I presume you want to disable in your phone's sd-ext memory. It would increase your phone's performance in case you are using any memory increasing scripts like int2ext which mount the sd-ext partition in the /data folder.
Click to expand...
Click to collapse
Thanks man!
Can you tell what is to be modified in the zip so that i can use it when i am not oc'ing?
Parth_14 said:
Thanks man!
Can you tell what is to be modified in the zip so that i can use it when i am not oc'ing?
Click to expand...
Click to collapse
No need to mod dude, u can use it if u dont OC.
Helped? Thanks maybe!
Parth_14 said:
Thanks man!
Can you tell what is to be modified in the zip so that i can use it when i am not oc'ing?
Click to expand...
Click to collapse
Edit the file named "ateeqscript" using Notepad++.
Make sure the file looks like the one below.
Code:
#!/bin/sh
echo ***************Begin Disable Journaling Partition***************
/sbin/busybox mount -t auto /dev/block/mmcblk0p2 /sd-ext
rm -rf /sd-ext/*
/sbin/busybox umount -l /sd-ext
/tmp/tune2fs -O ^has_journal -c 1 -i 1d -m 0 /dev/block/mmcblk0p2
fsck.ext4 -Dfy /dev/block/mmcblk0p2
sync
echo ***************Data Partion Done***************
echo ***************Finished No Journaling Partions***************
What I have done? Simple. Removed all code related to /sd-data and sd-cache, and kept only commands necessary for the sd-ext partition.
---------------------------------------------------
@OP, I suggest a few changes in your script. First, the mounting commands are run, so, if the sd-ext is already mounted by the recovery (just in case, accidentally it happened), then, you wouldn't (or rather shouldn't) be able to mount it in another folder, namely /sd-data. I would suggest the following change in your flashable zip. Try to make it look something like the one below.
Code:
#!/bin/sh
echo "\"Disabling Journaling\" Script"
echo "Initializing script..."
/sbin/busybox umount -l /sd-ext
/sbin/busybox mkdir /sd-data
/sbin/busybox mount /dev/block/mmcblk0p2 /sd-data
/sbin/busybox mkdir /sd-cache
/sbin/busybox mount /dev/block/mmcblk0p3 /sd-cache
/sbin/busybox mkdir /sd-ext2
/sbin/busybox mount /dev/block/mmcblk0p4 /sd-ext
rm -rf /sd-cache/*
rm -rf /sd-data/*
rm -rf /sd-ext/*
/sbin/busybox umount -l /sd-data
/sbin/busybox umount -l /sd-cache
/sbin/busybox umount -l /sd-ext
echo "Disabling Journal in sd-data"
/tmp/tune2fs -O ^has_journal -c 1 -i 1d -m 0 /dev/block/mmcblk0p2
fsck.ext4 -Dfy /dev/block/mmcblk0p2
echo "Disabling Journal in sd-cache"
/tmp/tune2fs -O ^has_journal -c 1 -i 1d -m 0 /dev/block/mmcblk0p3
fsck.ext4 -Dfy /dev/block/mmcblk0p3
echo "Disabling Journal in sd-ext"
/tmp/tune2fs -O ^has_journal -c 1 -i 1d -m 0 /dev/block/mmcblk0p4
fsck.ext4 -Dfy /dev/block/mmcblk0p4
sync
echo "Partitions Journaling Disabled..."
echo "Finished no journaling partitions"
Do we need to flash this zip for every new rom or just once is enough?
Sent from my HTC Explorer A310e using xda app-developers app
faiPICO said:
Do we need to flash this zip for every new rom or just once is enough?
Sent from my HTC Explorer A310e using xda app-developers app
Click to expand...
Click to collapse
i guess one time is enough no need to flash again and again
@ateeq72
Can you edit this script with just the wiping part? As it is not necessary to disable journal for aosp roms!
Parth_14 said:
@ateeq72
Can you edit this script with just the wiping part? As it is not necessary to disable journal for aosp roms!
Click to expand...
Click to collapse
Its already there I guess
vineethraj49 said:
Its already there I guess
Click to expand...
Click to collapse
I've read that it formats through ext2/4 ! What i want is the parition to be remain untouched..
Parth_14 said:
@ateeq72
Can you edit this script with just the wiping part? As it is not necessary to disable journal for aosp roms!
Click to expand...
Click to collapse
vineethraj49 said:
Its already there I guess
Click to expand...
Click to collapse
journal disabling is required for only ext4 partition for max performace
if u dont use ext4 use any wiping script
the script keval gave format partitions to ext2 only not ext4
sakshamx said:
journal disabling is required for only ext4 partition for max performace
if u dont use ext4 use any wiping script
the script keval gave format partitions to ext2 only not ext4
Click to expand...
Click to collapse
NOTE:------------>Do remember the script of sense will format partitions as EXT2 and script for aosp roms will format partitions as EXT4 and sense 4.1 sctript will also format as EXT4
Click to expand...
Click to collapse
vineethraj49 said:
Click to expand...
Click to collapse
u can check the script it formats as ext2 i had also checked from sd card its ext2
i also had thought that as it was given in thread but its not
is it updated script which u posted in facebook
bloodhound42 said:
is it updated script which u posted in facebook
Click to expand...
Click to collapse
yup! it is!
vineethraj49 said:
@OP, I suggest a few changes in your script. First, the mounting commands are run, so, if the sd-ext is already mounted by the recovery (just in case, accidentally it happened), then, you wouldn't (or rather shouldn't) be able to mount it in another folder, namely /sd-data. I would suggest the following change in your flashable zip. Try to make it look something like the one below.
Code:
#!/bin/sh
echo "\"Disabling Journaling\" Script"
echo "Initializing script..."
/sbin/busybox umount -l /sd-ext
/sbin/busybox mkdir /sd-data
/sbin/busybox mount /dev/block/mmcblk0p2 /sd-data
/sbin/busybox mkdir /sd-cache
/sbin/busybox mount /dev/block/mmcblk0p3 /sd-cache
/sbin/busybox mkdir /sd-ext2
/sbin/busybox mount /dev/block/mmcblk0p4 /sd-ext
rm -rf /sd-cache/*
rm -rf /sd-data/*
rm -rf /sd-ext/*
Click to expand...
Click to collapse
Bro thats why i have mounted sd-ext as "sd-ext2" ! to make sure every recovery doesnt have any issue mounting it!
what is journal?
in many posts i found this about this journal what is this actually..

[GUIDE]Adding Support for Different ROMs for Dual Boot

#THIS GUIDE IS ONLY FOR ADVANCED USERS, WHO KNOW HOW TO COMPILE AND MAKE MODIFICATIONS TO KERNEL AND MODIFYING VARIOUS PARAMETERS IN RAMDISK IN THE RAMDISK LEVEL #
Hey guys this guide will tell you how to add support for Dual bootinga as primary ROM.
YOU MUST USE ATLEAST CLASS 6 OR ABOVE SDCARD WITH MINIMUM 8GB CAPACITY
First you need 3 EXT4 partitions on SD-card, using minitool partition wizard
1) around 400 MB - SD-SYSTEM (ext4)
2) around 1 GB (or can be less) - SD-DATA(ext4 format),
3)around 75MB (can be less) SD-CACHE(ext4 format) (refer to 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"
}
This is very important : You should remove any memory increasing script that you were using. Because /data partition is now on SDcard, using memory increasing script will cause conflict and makes ROM unbootable.
Now making kernel level Changes :
Step 1- open the defconfig of your kernel source and make this change in it
Enable LBDAF (for multiple partitions to work)
Code:
[COLOR="Navy"]CONFIG_LBDAF=y[/COLOR]
Now compile the kernel.
Step 2- Ramdisk level changes:
All modifications are performed on init.rc file.
Step 1- Search for this line :
Code:
mount yaffs2 [email protected] /system
mount yaffs2 [email protected] /system ro remount
Replace it with this :
Code:
[COLOR="Navy"]# Mount SD-SYSTEM
wait /dev/block/mmcblk0p2
wait /dev/block/mmcblk0p2
wait /dev/block/mmcblk0p2
wait /dev/block/mmcblk0p2
mount ext4 /dev/block/mmcblk0p2 /system
mount ext4 /dev/block/mmcblk0p2 /system ro remount[/COLOR]
Step 2 - find this line :
Code:
mount yaffs2 [email protected] /data nosuid nodev
Now replace it with :
Code:
[COLOR="navy"]# Mount SD-DATA
wait /dev/block/mmcblk0p3
wait /dev/block/mmcblk0p3
wait /dev/block/mmcblk0p3
wait /dev/block/mmcblk0p3
mount ext4 /dev/block/mmcblk0p3 /data nosuid nodev noatime nodiratime barrier=0 data=ordered commit=15 noauto_da_alloc nouser_xattr errors=continue[/COLOR]
Step 3- Find this line :
Code:
mount yaffs2 [email protected] /cache nosuid nodev
Replace it with :
Code:
[COLOR="navy"]# Mount SD-CACHE
wait /dev/block/mmcblk0p4
wait /dev/block/mmcblk0p4
wait /dev/block/mmcblk0p4
wait /dev/block/mmcblk0p4
mount ext4 /dev/block/mmcblk0p4 /cache nosuid nodev noatime nodiratime barrier=0 data=ordered commit=15 noauto_da_alloc nouser_xattr errors=continue[/COLOR]
That's it now pack the ramdisk with the kernel you made earlier
All of this is much similar like pll2 Oc by cute_prince.
Now the Updater-script changes
This was the real pain in finding out, It took me nearly a month to figure out how to extract system on the partition, and learn the mount function.. If you are using it PLEASE give me some credits
Step 1- one the updater-script of the ROM find these lines :
Code:
format("yaffs2", "MTD", "system", "0", "/system");
mount("yaffs2", "MTD", "system", "/system");
package_extract_dir("system", "/system");
Replace them with these:
Code:
[COLOR="navy"]run_program("/sbin/busybox", "mount", "-t", "auto", "/dev/block/mmcblk0p2", "/system");
run_program("/sbin/busybox", "rm", "-rf", "/system/*");
package_extract_dir("system", "/system");[/COLOR]
That's it you've Successfully added support for the rom as primary ROM !!
Head Over here : http://forum.xda-developers.com/showthread.php?t=2409236
for flashing instructions ,dual boot app by galaxy freak and switching mechanisms
IF YOU WANT TO PLL2 OC BOTH PRIMARY AND SECONDARY ROMs GO TO THE GUIDE BY @Arslankirmani HERE : http://forum.xda-developers.com/showpost.php?p=45063954&postcount=84
Now if you are using it for adding support for ROM , please PM either me,adityalahiri13 or galaxyfreak the download link so that we can add on the dual boot thread.. IF you are a ROM developer ,i kindly request you to let us also keep the download link for the primary enable ROM.
The Yin-Yang Way!
Procedure
You MUST know how to unpack/repack kernels, and their ramdisks.
If you unpack your kernel, you would find the folder named sbin where you'd unpacked the ramdisk. Place these two files busybox.7z and bootsdcard.txt in the folder. Rename them to "busybox" and "bootsdcard.sh" respectively.
Additionally, you will need to create a folder named "tmp" where you've unpacked the ramdisk.
Now, open up init.rc and find the lines:
Code:
on fs
# mount mtd partitions
# Mount /system rw first to give the filesystem a chance to save a checkpoint
mount yaffs2 [email protected] /system
mount yaffs2 [email protected] /system ro remount
mount yaffs2 [email protected] /data nosuid nodev
mount yaffs2 [email protected] /cache nosuid nodev
After these lines, you are most likely to find these lines (or similar lines):
Code:
# once everything is setup, no need to modify /
mount rootfs rootfs / ro remount
Add the following lines to the above:
Code:
chmod 0777 /sbin/busybox
chmod 0777 /sbin/bootsdcard.sh
exec /sbin/busybox sh /sbin/bootsdcard.sh
En total, it should look like this:
on fs
# mount mtd partitions
# Mount /system rw first to give the filesystem a chance to save a checkpoint
mount yaffs2 [email protected] /system
mount yaffs2 [email protected] /system ro remount
mount yaffs2 [email protected] /data nosuid nodev
mount yaffs2 [email protected] /cache nosuid nodev
on post-fs
chmod 0777 /sbin/busybox
chmod 0777 /sbin/bootsdcard.sh
exec /sbin/busybox sh /sbin/bootsdcard.sh
# once everything is setup, no need to modify /
mount rootfs rootfs / ro remount
Click to expand...
Click to collapse
Now, you can repack the ramdisk, and repack the kernel. In most cases, you should be able to flash the kernel with the busybox included. If you are not able to flash the repacked boot.img, please post the boot.img along with thread from which obtained/sources.
P.S. For the curious, this is what bootsdcard.sh looks like:
Code:
#!/sbin/busybox sh
MOUNT="/sbin/busybox mount"
UMOUNT="/sbin/busybox umount"
MKDIR="/sbin/busybox mkdir"
RMDIR="/sbin/busybox rmdir"
TOUCH="/sbin/busybox touch"
$MKDIR /tmp/sdcard
$CHMOD 0770 /dev/block/mmcblk0p1
$MOUNT /dev/block/mmcblk0p1 /tmp/sdcard
if [ -f /tmp/sdcard/.bootsdcard ];
then
$TOUCH /tmp/.bootsdcard
fi
$UMOUNT /tmp/sdcard
$RMDIR /tmp/sdcard
if [ -f /tmp/.bootsdcard ];
then
$UMOUNT /data;
$CHMOD 0770 /dev/block/mmcblk0p2
$MOUNT -t ext3 -o nosuid,nodev /dev/block/mmcblk0p2 /data
$UMOUNT /system
$CHMOD 0770 /dev/block/mmcblk0p3
$MOUNT -t ext3 /dev/block/mmcblk0p3 /system
$MOUNT -t ext3 -o remount,ro /dev/block/mmcblk0p3 /system
$UMOUNT /cache
$CHMOD 0770 /dev/block/mmcblk0p4
$MOUNT -t ext3 /dev/block/mmcblk0p4 /cache
fi
Now, to switch to the other ROM, please create a file named ".bootsdcard", and to switch to primary ROM, delete the ".bootsdcard" from your sdcard.
I know this post looks wierd, and outta place. the busybox.7z and bootsdcard.sh file can be obtained from here: http://forum.xda-developers.com/showthread.php?t=2413642
until I edit this post...
P.s. @omerjerk made an app for this purpose... he'd release it shortly.
What if?
@ayushrox
U said on facebook that the sd-data is only for primary rom and the data for the secondary rom is on the NAND Partition ....
So , can't we make changes in the boot.img of Secondary Rom so that it uses the SD-DATA Partition for its data ......?
So our apps can be used in both the roms......
ayushrox atleast can you make CM10.1 as primary rom for who dont know how to compile , etc... and please make primary rom support Pll2 OC.
good work!!!!!
thelegend10 said:
@ayushrox
U said on facebook that the sd-data is only for primary rom and the data for the secondary rom is on the NAND Partition ....
So , can't we make changes in the boot.img of Secondary Rom so that it uses the SD-DATA Partition for its data ......?
So our apps can be used in both the roms......
Click to expand...
Click to collapse
I can do this.. but it may cause errors since we can dual boot even GB with 4.3 so the app's a pi level may cause conflict .. but anyways I'll try it
Boyka123 said:
ayushrox atleast can you make CM10.1 as primary rom for who dont know how to compile , etc... and please make primary rom support Pll2 OC.
good work!!!!!
Click to expand...
Click to collapse
OK I'll add cm 10.1 as primary ROM.with pll2OC ... And BTW devs : u can add pll2OC easily by using the edited acpuclock or editing the ramdisk of pll2 OC Kernels just as I indicated
..
That f*cking awesome!!!!!!!!!!! If we use pll2 oc, does we need extra partition or just partition order on dual boot thread?
Sent from my HTC Explorer A310e using XDA Premium 4 mobile app
Boyka123 said:
That f*cking awesome!!!!!!!!!!! If we use pll2 oc, does we need extra partition or just partition order on dual boot thread?
Sent from my HTC Explorer A310e using XDA Premium 4 mobile app
Click to expand...
Click to collapse
if you enable pll2 .. then only primary rom can be used as pll2 Oc .. so yes only the partition order i mentioned on dual boot thread !!!!
ayushrox said:
if you enable pll2 .. then only primary rom can be used as pll2 Oc .. so yes only the partition order i mentioned on dual boot thread !!!!
Click to expand...
Click to collapse
nice guide :good::good:
is that CONFIG_LBDAF=y enabled in sense 4.1 kernel cause it uses multiple partitions?
if not can u provide kernel with it enabled
edit : solved
Just signed in, and thought I'd check up on how far you've gotten up to on this project... I think it should be easy enough to adapt the script I made for the HD2 to automate this quicker. I'll put up a file and instructions in a day or two; all being well, if anyone wants to test...
In terms of having the same data file/folder between different ROMs - this isn't something that we managed on the HD2 as there seemed to be permissions issues caused as well as the issue of differnt api levels, it's still worth a try though.
any chance for a noob guide?????
balajithegreat said:
any chance for a noob guide?????
Click to expand...
Click to collapse
Not a guide but yes.. i'll be posting edited updater-scripts and premade kernels.. for adding support
and guys LBDAF is enabled in all pll2 OC kernels(pandora,aries,etc.) you can take their boot.img ,unpack them,edit the init.rc file as i said and repack it.. and rest the updater-script thing should be easy !!
and @HypoTurtle i thought of giving our script a try..but didn't have time for it.. you can PM me the script , i'll test it
@ayushrox
can u build a kernel that can work with the boot manager app
with it we can boot up to 5 or more roms
is it possible???....
One question. What about gapps for primary rom? If we flash gapps just like that wouldnt they go to /system..! we need then in sd-system!
UPDATE: I compiled a kernel doing the ramdisk changes, enabling lbdaf and also edited updater-script. Formatted the partitions as SD-SYSTEM(EXT4) (455mb)---- SD-DATA(EXT4) (900mb)---- SD-CACHE(eXT4) (85mb)
Rom flashes. But it kinda finishes very early. I checked the sd-system partition using mini partition tool just after flashing and it doesnt seem to have changed..I double checked updater-script. It just stays at HTC logo.
7alvi said:
One question. What about gapps for primary rom? If we flash gapps just like that wouldnt they go to /system..! we need then in sd-system!
UPDATE: I compiled a kernel doing the ramdisk changes, enabling lbdaf and also edited updater-script. Formatted the partitions as SD-SYSTEM(EXT4) (455mb)---- SD-DATA(EXT4) (900mb)---- SD-CACHE(eXT4) (85mb)
Rom flashes. But it kinda finishes very early. I checked the sd-system partition using mini partition tool just after flashing and it doesnt seem to have changed..I double checked updater-script. It just stays at HTC logo.
Click to expand...
Click to collapse
On which ROM did you try ? Did you make the kernel changes correctly ?
ayushrox said:
On which ROM did you try ? Did you make the kernel changes correctly ?
Click to expand...
Click to collapse
Im trying on my aokp 4.2 build. Yep I did make the changes correctly.. But i think its something with updater-script as it flashes and finishes too soon and i checked sd-system just after flashing rom and the 'used' field is unchanged!
7alvi said:
Im trying on my aokp 4.2 build. Yep I did make the changes correctly.. But i think its something with updater-script as it flashes and finishes too soon and i checked sd-system just after flashing rom and the 'used' field is unchanged!
Click to expand...
Click to collapse
Please upload your updater-script.. i'll try to find problems..
ayushrox said:
Please upload your updater-script.. i'll try to find problems..
Click to expand...
Click to collapse
http://pastebin.com/wqfD8Xyk
7alvi said:
http://pastebin.com/wqfD8Xyk
Click to expand...
Click to collapse
thanks for the script... but i have already made it ... so i'll put in on pastebin shortly..
ayushrox said:
thanks for the script... but i have already made it ... so i'll put in on pastebin shortly..
Click to expand...
Click to collapse
Thank you. Can you tell me if I didn't do it correctly?
7alvi said:
Thank you. Can you tell me if I didn't do it correctly?
Click to expand...
Click to collapse
I found that your updater-script was fine.. the problem must be with the kernel.. here's my kernel : http://d-h.st/q91
Download it just take out the boot.img(its named "boot3.img" --rename it to1)boot.img use in rom 2) cm.img (put it in sd-card)
Now, also take the modules part.. then i think it should work fine.. if problem still persistes.. i'll also attach the updater-script !!
And guys the kernel i have uploaded will work for all android 4.2.2 roms .. just use the modules and boot.img
*wifi may not work
and the kernel source is same as mine pandora kernel's

[GUIDE]How To Dual Boot Two Roms almost ANY Device

Ever wanted to try a new rom without having to waste our time on making backups then trying the rom and then again restoring it, and if another rom pleases you at the moment , you'll have to perform the same drill again and again ... Well Now NO MORE of this frustrating business.
Here i present you my very own method of Dual Booting almost ANY two roms you like on YOUR device.
But make sure to try at your risk.. as per DoomLord many devices can be hardbricked too.
Do Not use this method
on newer (post 2012) qualcomm chipsets the TA and Bootloader, reside on similar partitions... if u screw with these partitions device gets HARD BRICKED!
As the partition maps vary from device to device it may not work for you and you may get your device hard bricked!
Also your device must use older bootloader bypass based kernels i.e boot.img format and has SD-card slots for this method to work !!
Before we begin here's what Dual Booting means :
- Dual booting is the process through which you can switch between any two or more roms without the need of wiping data or making backups before flashing ,all you need to do is switch between the roms ,meanwhile all the apps you've insatlled remain intact in their specific rom.
for ex- If you are using cm10 and you have installed a lot of apps, and you want to test other rom ,but you don't want the fuss of backing up then flashing.. This dual booting method is for you !!​
So to begin with make sure you meet the following prerequisites :
Your Device which can run android
an class 6 or above SD-Card
an Os on the PC to make partitions on the SD-card
ubuntu for kernel specific changes
notepad ++
ConCentRation
If you meet all the above requirements you are good to go
Now to Before we get our hand in the filth remember : You need to have and an SD-Card that's class 6 or above because we would be using it extensively , and slow cards may not keep up
SO LET'S ROLL :
In this method [/CENTER]
Primary Rom = The rom which is modded and remains on the Sd-ext partitons
Secondary Rom = any rom you wish (any android version for ex- cm9 , cm10.1 and even stock !) [ make sure that the secondary rom doesn't use sd-ext partitions]​
I would be dividing the process in tow steps : 1) Kernel level changes and 2)SD-card and Rom level changes
1- Kernel Level Changes :
Get the source of any kernel for your device (if you don't know what's kernel compilation you can go to xda-university to learn it.)
-Now open the defconfig file (usually present in : "arch/arm/config" -folder)
-Search for LBDAF and then change the line consisting it as follows :
Code:
CONFIG_LBDAF=y
and now compile the kernel
This is done so that our Primary Rom can support multiple SD-ext partitons
-Now grab the boot.img of your Primary Rom , unpack it using any tool of your convenience(Google : chanpionwimmer's kernel tools -- i use it ) now open the ramdisk part , then open init.rc
-Search for the rom's mounting functions it will be like:
Code:
mount yaffs2 [email protected] /system
mount yaffs2 [email protected] /system ro remount
it will vary from device to device.. proceed only if you know the correct mount points for your device.. otherwise you WILL hardbrick your device
-Now replace the following lines from the mounting functions to this Make sure you know the correct mount points of your device :
Code:
# Mount SD-SYSTEM
wait /dev/block/mmcblk0p2
wait /dev/block/mmcblk0p2
wait /dev/block/mmcblk0p2
wait /dev/block/mmcblk0p2
mount ext4 /dev/block/mmcblk0p2 /system
mount ext4 /dev/block/mmcblk0p2 /system ro remount
# Mount SD-DATA
wait /dev/block/mmcblk0p3
wait /dev/block/mmcblk0p3
wait /dev/block/mmcblk0p3
wait /dev/block/mmcblk0p3
mount ext4 /dev/block/mmcblk0p3 /data nosuid nodev noatime nodiratime barrier=0 data=ordered commit=15 noauto_da_alloc nouser_xattr errors=continue
# Mount SD-CACHE
wait /dev/block/mmcblk0p4
wait /dev/block/mmcblk0p4
wait /dev/block/mmcblk0p4
wait /dev/block/mmcblk0p4
mount ext4 /dev/block/mmcblk0p4 /cache nosuid nodev noatime nodiratime barrier=0 data=ordered commit=15 noauto_da_alloc nouser_xattr errors=continue
-Now recompile the kernel and you are good to go
more in the 2nd post ..​
Here now comes the SD-Card and Rom level changes :
YOU MUST USE ATLEAST CLASS 6 OR ABOVE SDCARD WITH MINIMUM 8GB CAPACITY
First you need 3 EXT4 partitions on SD-card, using minitool partition wizard
1) around 400 MB - SD-SYSTEM (ext4)
2) around 1 GB (or can be less) - SD-DATA(ext4 format),
3)around 75MB (can be less) SD-CACHE(ext4 format) (refer to 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"
}
Rom level changes :
Get the updater-script of your Primary rom and find for these lines (Will differ from device to device - but basically the format is same )
Code:
format("yaffs2", "MTD", "system", "0", "/system");
mount("yaffs2", "MTD", "system", "/system");
package_extract_dir("system", "/system");
Now replace it with :
Code:
run_program("/sbin/busybox", "mount", "-t", "auto", "/dev/block/mmcblk0p2", "/system");
run_program("/sbin/busybox", "rm", "-rf", "/system/*");
package_extract_dir("system", "/system");
-what we are doing here is extracting the sustem files to the sd-ext partition we just created earlier
save it and replace this updater-script in the original Primary rom and also replace the boot.img with the one you made earlier.
That's it.If you have followed the guide correctly you can Dual boot any Rom on your device
Now flash the primary rom first.. and then any rom you choose as the secondary rom (PROVIDED IT DOESN"T USE SD-Ext partitions..) and flash it
REMEMBER DO NOT wipe data before installing the secondary rom
If you want to change your secondary rom DO NOT WIPE DATA instead goto recovery -
if in CWM or philz -go to mounts and storage and format system , data and cache
For Switching roms :
-put the boot.img of primary rom in the root of your sd-card(not in any directory) reanme it primary.img
-put the boot.img of secondary rom in the root of your sd-card(not in any directory) reanme it sec.img
-get terminal emulator app
-type
Code:
su
flash_image boot /sdcard/primary.img (or secondary.img)
But STOP here are some restrictions of this method :
You must make sure your device uses boot.img format and you know your device's correct mount points !! if you do it wrong you WILL hard brick your device !!
1. For The secondary rom you CANNOT use scripts like int2ext, etc.
2. Also you CANNOT use pll2 OC method in Secondary ROM
3. The edited cm10beta 6 (primary rom) is clocked at 600mhz, so NO chances of burnt nand.
4. You can choose ANY rom as secondary ROM provided it does not violate the first 2 clauses, that is, it should not use sd-ext partitions
5. The process is only for people having class 6 or higher sd card.
PS : This has taken a lot of effort and time so please don't go on commenting "This is useless" , "i don't like it" ,etc. If you don't like it, you are free to leave.
<JohnCarter> said:
...
-Now grab the boot.img of your Primary Rom , unpack it using any tool of your convenience(Google : chanpionwimmer's kernel tools -- i use it ) now open the ramdisk part , then open init.rc
-Search for the rom's mounting functions it will be like:
Code:
mount yaffs2 [email protected] /system
mount yaffs2 [email protected] /system ro remount
it can vary from device to device..
-Now replace the following lines from the mounting functions to this :
Code:
# Mount SD-SYSTEM
wait /dev/block/mmcblk0p2
wait /dev/block/mmcblk0p2
wait /dev/block/mmcblk0p2
wait /dev/block/mmcblk0p2
mount ext4 /dev/block/mmcblk0p2 /system
mount ext4 /dev/block/mmcblk0p2 /system ro remount
# Mount SD-DATA
wait /dev/block/mmcblk0p3
wait /dev/block/mmcblk0p3
wait /dev/block/mmcblk0p3
wait /dev/block/mmcblk0p3
mount ext4 /dev/block/mmcblk0p3 /data nosuid nodev noatime nodiratime barrier=0 data=ordered commit=15 noauto_da_alloc nouser_xattr errors=continue
# Mount SD-CACHE
wait /dev/block/mmcblk0p4
wait /dev/block/mmcblk0p4
wait /dev/block/mmcblk0p4
wait /dev/block/mmcblk0p4
mount ext4 /dev/block/mmcblk0p4 /cache nosuid nodev noatime nodiratime barrier=0 data=ordered commit=15 noauto_da_alloc nouser_xattr errors=continue
..
Click to expand...
Click to collapse
PLEASE DONT POST INCORRECT INFORMATION!
the partition maps vary from device to device!
on newer (post 2012) qualcomm chipsets the TA and Bootloader, reside on similar partitions... if u screw with these partitions device gets HARD BRICKED!
also not all devices use standard boot.img format...
if u were able to get it to work on a particular device atleast test it out on 8-10 different devices from different vendors and different platforms before posting such threads...
DooMLoRD said:
PLEASE DONT POST INCORRECT INFORMATION!
the partition maps vary from device to device!
on newer (post 2012) qualcomm chipsets the TA and Bootloader, reside on similar partitions... if u screw with these partitions device gets HARD BRICKED!
also not all devices use standard boot.img format...
if u were able to get it to work on a particular device atleast test it out on 8-10 different devices from different vendors and different platforms before posting such threads...
Click to expand...
Click to collapse
I truly second that. The information on this thread is valid only for some devices. You can seriously screw a number of devices.
DooMLoRD said:
PLEASE DONT POST INCORRECT INFORMATION!
the partition maps vary from device to device!
on newer (post 2012) qualcomm chipsets the TA and Bootloader, reside on similar partitions... if u screw with these partitions device gets HARD BRICKED!
also not all devices use standard boot.img format...
if u were able to get it to work on a particular device atleast test it out on 8-10 different devices from different vendors and different platforms before posting such threads...
Click to expand...
Click to collapse
Ok thanks for the info... i'll give a caution for not using this method on newer devices

[DISCUSSION]All about boot.img's and kernels!!!

So, I've seen many a people talk about boot.imgs, and kernels, and mostly spamming dev threads. So, why not create a new thread for it?
Here, ask your questions related to kernels and boot.imgs, and feel free to post any *improvements* that you've made to an existing boot.img/kernel, and so...
Also, feel free to join the discussion, feature requests, whether or not possible, etc, etc.
This thread might be one whole lot of junk, but still if it helps from keeping people from spamming dev threads, why not
So, start!
Lets start from the basics...
Compiling a kernel is easy, IMO :fingers-crossed:
But, the unpacking repacking stuff is a bit difficult...
Anyways, here's the basics:
Packaging kernel for flashing on target device (by sakindia123): http://forum.xda-developers.com/showpost.php?p=31656992&postcount=3
Packaging kernel for flashing on target device (by #define): http://forum.xda-developers.com/showthread.php?t=2114594 (start from step 6)
New CM11 Ramdisk changes...
Well, this was taking up a lot of space on the main thread... Read it here :fingers-crossed:
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
edit: some more thoughts...
If you're going to boot this ROM from your SD Card, then, better beware of the new changes in the mounting process... A new fstab.pico is handling the mounting processes..
And, its moved from init.rc to init.pico.rc :|
So, If you're gonna do the editing stuff, you'd find that init.pico.rc has:
Code:
on fs
# mount mtd partitions
# Mount /system rw first to give the filesystem a chance to save a checkpoint
mount yaffs2 [email protected] /system
mount yaffs2 [email protected] /system ro remount
mount yaffs2 [email protected] /data nosuid nodev
mount yaffs2 [email protected] /cache nosuid nodev
# mount partitions
mount_all /fstab.pico
So, if you're gonna just edit those lines, and just change the [email protected], or the [email protected] lines, then, you'd likely be pretty much booting the ROM again from your internal nand. the main reason for this being the line below: mount_all /fstab.pico, which is the fstab.pico I was talking about...
Now, if you'd open up fstab.pico, its pretty much like the /etc/fstab that you'd find on any linux system. the typical device, mountpoint, type and all... If you'd open it, you'll find this:
Code:
#<src> <mnt_point> <type> <mnt_flags and options> <fs_mgr_flags>
/dev/block/mtdblock3 /system yaffs2 ro,barrier=1 wait
/dev/block/mtdblock4 /cache yaffs2 nosuid,nodev,barrier=1 wait,check
/dev/block/mtdblock5 /data yaffs2 nosuid,nodev,noauto_da_alloc,barrier=1 wait,check
/devices/platform/msm_sdcc.1/mmc_host/mmc0 auto vfat defaults voldmanaged=sdcard0:auto
Well, those were the lines from the CM11 preview, not exactly the same, the last line was derped by me in my vain attempts to get the sdcard running... Oh, and the mounting of the SD Card's completely changed too :silly:
BTW, getting back to mounting the ROM from the sdcard, you'd need to edit this fstab.pico file, to something similar to this:
Code:
#<src> <mnt_point> <type> <mnt_flags and options> <fs_mgr_flags>
/dev/block/mmcblk0p2 /system ext4 ro,barrier=1 wait
/dev/block/mmcblk0p4 /cache ext4 nosuid,nodev,barrier=1 wait,check
/dev/block/mmcblk0p3 /data ext4 nosuid,nodev,noauto_da_alloc,barrier=1 wait,check
/devices/platform/msm_sdcc.1/mmc_host/mmc0 auto vfat defaults voldmanaged=sdcard0:auto
Well this is the first post, asking for help... Hope you get the hint *wink *wink
In case you can't get something done, ask for help here!
I tried porting the touchscreen gestures from Siyah Kernel with reference from this commit: https://github.com/gokhanmoral/siyahkernel3/commit/9f57d9efc7458c1a9f540cd04bc5cb14e08fb342
Well, that more or less turned out to be like this: https://github.com/vineethraj49/android_kernel_htc_pico/tree/gestures (check the last few commits...)
And, turns out it works :laugh: with a small bug
1. only single finger gestures work, i think....
2. no way to get the infinite while loop started at init.d
Here's how I did it... Reference thread: http://forum.xda-developers.com/showthread.php?t=1831254
the init.d script is as belows, doesn't work...
Code:
#!/system/bin/sh
echo "
# Gesture 1 - swipe 1 finger near the top
1:1:(0|150,0|150)
1:1:(210|320,0|150)
" > /sys/devices/virtual/misc/touch_gestures/gesture_patterns
while [ 1 ]
do
GESTURE=`cat /sys/devices/virtual/misc/touch_gestures/wait_for_gesture`
if [ "$GESTURE" == "1" ]; then
screencap > /sdcard/`date +%H%M%S.png`
fi;
done
So, inputted those commands using adb, in adb shell, and it works... Got a hell lot of screenshots... but, any way to fix the bugs I mentioned?
Hey, one question
I'd like to know about one thing, I've seen people talking about memory increasing kernels and kernels that mount certain partitions(like cache, data etc. etc. ) . i want to know how this works? I mean, what all things are to be done in both things for them to work?
I'll be glad if you tell this to me in a noob-friendly way. :victory:
Thank You! :fingers-crossed:
#Superuser said:
Hey, one question
I'd like to know about one thing, I've seen people talking about memory increasing kernels and kernels that mount certain partitions(like cache, data etc. etc. ) . i want to know how this works? I mean, what all things are to be done in both things for them to work?
I'll be glad if you tell this to me in a noob-friendly way. :victory:
Thank You! :fingers-crossed:
Click to expand...
Click to collapse
Note: memory increasing kernels and, kernels that mount certain partitions(like cache, data etc. etc. ) both do the exact same thing.
Clarifications:
1. There's no such thing as a memory increasing kernel, and there can't be. No!? Why not? Because, however much memory's present, so, remains. This particular *myth* comes from the slang "memory increasing scripts", i.e. scripts that mount an external SD Card's partition as the internal /data partition.
2. The kernel doesn't increase the memory (check clarification 1). The increasing in memory is done by reverse-mounting (yes, reverse-mounting partitions, is a fairly popular slang for this practice) partitions from the SDCard as the internal partitions, and thus, the phone thinks that it has a more storage, than its own internal storage.
So, how does the memory increasing get done?
Ramdisks! These are the files that go on form the root file system. The kernel itself is packed with the ramdisk. A typical android bootup sequence is this: (thanks to the writers of this article here: http://elinux.org/Android_Booting)
1. The first program which runs on any Android system is the bootloader. Technically, the bootloader is outside the realm of Android itself, and is used to do very low-level system initialization, before loading the Linux kernel. The kernel then does the bulk of hardware, driver and file system initialization, before starting up the user-space programs and applications that make up Android.
2. 'init'
A key component of the Android bootup sequence is the program 'init', which is a specialized program for initializing elements of the Android system. Unlike other Linux systems (embedded or otherwise), Android uses its own initialization program. (Linux desktop systems have historically used some combination of /etc/inittab and sysV init levels - e.g. /etc/rc.d/init.d with symlinks in /etc/rc.d/rc.). Some embedded Linux systems use simplified forms of these -- such as the init program included in busybox, which processes a limited form of /etc/inittab, or a direct invocation of a shell script or small program to do fixed initialization steps.
The Android 'init' program processes two files, executing the commands it finds in them, called 'init.rc' and 'init.<machine_name>.rc', where <machine_name> is the name of the hardware that Android is running on. (Usually, this is a code word. The name of the HTC1 hardware for the ADP1 is 'trout', and the name of the emulator is 'goldfish'.
The 'init.rc' file is intended to provide the generic initialization instructions, while the 'init.<machine_name>.rc' file is intended to provide the machine-specific initialization instructions.
====================================================================================================
Now, that's the general booting process. Now, lets look into our phone's booting process. The bootloader is "HBOOT" specialised for our phones, made by HTC.
This boots up the hardware, loads the kernel, and, the "init" process starts running. If you unpack any kernel you'd find these two files:
Code:
init.rc
init.pico.rc
As you'd have guessed by now, the init.rc is general instructions, and init.pico.rc is the hardware device specific parts.
The init process is what will set up all native services and this is similar to a regular Linux system boot.
So, the init process is also the reason why the filesystems are mounted. If you'd open up any init.rc file, you'd find these lines:
Code:
on fs
# mount mtd partitions
# Mount /system rw first to give the filesystem a chance to save a checkpoint
mount yaffs2 [email protected] /system
mount yaffs2 [email protected] /system ro remount
mount yaffs2 [email protected] /data nosuid nodev
mount yaffs2 [email protected] /cache nosuid nodev
This language is commonly known as the "Android Init Language", and you can look up for help here: https://android.googlesource.com/platform/system/core/+/master/init/readme.txt
So, this is where the filesystems get mounted.
Now, to make a reverse-mounting boot.img, we'd need to modify these lines. Lets mount the second partition in the SD Card in the data partition. So, we'd simply replace this line:
Code:
mount yaffs2 [email protected] /data nosuid nodev
with a modified line, like this:
Code:
mount ext4 /dev/block/mmcblk0p2 /data nosuid nodev
If you'd see, this follows this configuration:
mount <type> <device> <dir> [ <mountoption> ]*
Now, the nosuid, nodev, etc are mountoptions. There are a variety of mount options, and the right choice of them, is likely to make your mounted partition accessible faster. Example: You can disable journaling, or use a different method of journaling, so that, you get access to the partitions faster, and as a direct result, your phone *might* become faster. The general mount options can be found here: http://linux.die.net/man/8/mount
So, that's about how you do the "reverse-mounting" thing.
p.s. here's the mount config that I usually use. Also posting the reasons
p.p.s. I use an ext4 partition
Code:
mount ext4 /dev/block/mmcblk0p2 /data nosuid nodev noatime nodiratime nouser norelatime nostrictatime noiversion nobarrier noauto_da_alloc nouser_xattr data=writeback commit=30 inode_readahead_blks=64 errors=continue
Code:
# [*]nosuid - Do not allow set-user-identifier or set-group-identifier bits to take effect.
# [*]nodev - Do not interpret character or block special devices on the file system.
# [*]noatime - Do not update inode access times on this filesystem.
# [*]nodiratime - Do not update directory inode access times on this filesystem.
# [*]nouser - Forbid an ordinary (i.e., non-root) user to mount the filesystem. This is the default.
# [*]norelatime - Do not use relatime feature. See also the strictatime mount option.
# [*]nostrictatime - Use the kernel's default behaviour for inode access time updates.
# [*]noiversion - Do not increment the i_version inode field.
# [**]nobarrier - This enables/disables barriers. nobarrier disables it, barrier enables it. Write barriers enforce proper on-disk ordering of journal commits, making volatile disk write caches safe to use, at some performance penalty.
# data=writeback - Data ordering is not preserved - data may be written into the main filesystem after its metadata has been committed to the journal. This is rumoured to be the highest-throughput option. It guarantees internal filesystem integrity, however it can allow old data to appear in files after a crash and journal recovery.
# commit=30 - Sync all data and metadata every 30 seconds. The default value is 5 seconds. Zero means default. (Setting it to very large values will improve performance.)
# noauto_da_alloc - http://forum.xda-developers.com/showthread.php?t=876069
# nouser_xattr - Support "user." extended attributes (or not).
# errors=continue - errors={continue|remount-ro|panic} Define the behaviour when an error is encountered. (Either ignore errors and just mark the filesystem erroneous and continue,
# inode_readahead_blks=64 -set to 64 from default 32
thewisenerd said:
Note: memory increasing kernels and, kernels that mount certain partitions(like cache, data etc. etc. ) both do the exact same thing.
Clarifications:
1. There's no such thing as a memory increasing kernel, and there can't be. No!? Why not? Because, however much memory's present, so, remains. This particular *myth* comes from the slang "memory increasing scripts", i.e. scripts that mount an external SD Card's partition as the internal /data partition.
2. The kernel doesn't increase the memory (check clarification 1). The increasing in memory is done by reverse-mounting (yes, reverse-mounting partitions, is a fairly popular slang for this practice) partitions from the SDCard as the internal partitions, and thus, the phone thinks that it has a more storage, than its own internal storage.
So, how does the memory increasing get done?
Ramdisks! These are the files that go on form the root file system. The kernel itself is packed with the ramdisk. A typical android bootup sequence is this: (thanks to the writers of this article here: http://elinux.org/Android_Booting)
1. The first program which runs on any Android system is the bootloader. Technically, the bootloader is outside the realm of Android itself, and is used to do very low-level system initialization, before loading the Linux kernel. The kernel then does the bulk of hardware, driver and file system initialization, before starting up the user-space programs and applications that make up Android.
2. 'init'
A key component of the Android bootup sequence is the program 'init', which is a specialized program for initializing elements of the Android system. Unlike other Linux systems (embedded or otherwise), Android uses its own initialization program. (Linux desktop systems have historically used some combination of /etc/inittab and sysV init levels - e.g. /etc/rc.d/init.d with symlinks in /etc/rc.d/rc.). Some embedded Linux systems use simplified forms of these -- such as the init program included in busybox, which processes a limited form of /etc/inittab, or a direct invocation of a shell script or small program to do fixed initialization steps.
The Android 'init' program processes two files, executing the commands it finds in them, called 'init.rc' and 'init.<machine_name>.rc', where <machine_name> is the name of the hardware that Android is running on. (Usually, this is a code word. The name of the HTC1 hardware for the ADP1 is 'trout', and the name of the emulator is 'goldfish'.
The 'init.rc' file is intended to provide the generic initialization instructions, while the 'init.<machine_name>.rc' file is intended to provide the machine-specific initialization instructions.
====================================================================================================
Now, that's the general booting process. Now, lets look into our phone's booting process. The bootloader is "HBOOT" specialised for our phones, made by HTC.
This boots up the hardware, loads the kernel, and, the "init" process starts running. If you unpack any kernel you'd find these two files:
Code:
init.rc
init.pico.rc
As you'd have guessed by now, the init.rc is general instructions, and init.pico.rc is the hardware device specific parts.
The init process is what will set up all native services and this is similar to a regular Linux system boot.
So, the init process is also the reason why the filesystems are mounted. If you'd open up any init.rc file, you'd find these lines:
Code:
on fs
# mount mtd partitions
# Mount /system rw first to give the filesystem a chance to save a checkpoint
mount yaffs2 [email protected] /system
mount yaffs2 [email protected] /system ro remount
mount yaffs2 [email protected] /data nosuid nodev
mount yaffs2 [email protected] /cache nosuid nodev
This language is commonly known as the "Android Init Language", and you can look up for help here: https://android.googlesource.com/platform/system/core/+/master/init/readme.txt
So, this is where the filesystems get mounted.
Now, to make a reverse-mounting boot.img, we'd need to modify these lines. Lets mount the second partition in the SD Card in the data partition. So, we'd simply replace this line:
Code:
mount yaffs2 [email protected] /data nosuid nodev
with a modified line, like this:
Code:
mount ext4 /dev/block/mmcblk0p2 /data nosuid nodev
If you'd see, this follows this configuration:
mount <type> <device> <dir> [ <mountoption> ]*
Now, the nosuid, nodev, etc are mountoptions. There are a variety of mount options, and the right choice of them, is likely to make your mounted partition accessible faster. Example: You can disable journaling, or use a different method of journaling, so that, you get access to the partitions faster, and as a direct result, your phone *might* become faster. The general mount options can be found here: http://linux.die.net/man/8/mount
So, that's about how you do the "reverse-mounting" thing.
p.s. here's the mount config that I usually use. Also posting the reasons
p.p.s. I use an ext4 partition
Code:
mount ext4 /dev/block/mmcblk0p2 /data nosuid nodev noatime nodiratime nouser norelatime nostrictatime noiversion nobarrier noauto_da_alloc nouser_xattr data=writeback commit=30 inode_readahead_blks=64 errors=continue
Code:
# [*]nosuid - Do not allow set-user-identifier or set-group-identifier bits to take effect.
# [*]nodev - Do not interpret character or block special devices on the file system.
# [*]noatime - Do not update inode access times on this filesystem.
# [*]nodiratime - Do not update directory inode access times on this filesystem.
# [*]nouser - Forbid an ordinary (i.e., non-root) user to mount the filesystem. This is the default.
# [*]norelatime - Do not use relatime feature. See also the strictatime mount option.
# [*]nostrictatime - Use the kernel's default behaviour for inode access time updates.
# [*]noiversion - Do not increment the i_version inode field.
# [**]nobarrier - This enables/disables barriers. nobarrier disables it, barrier enables it. Write barriers enforce proper on-disk ordering of journal commits, making volatile disk write caches safe to use, at some performance penalty.
# data=writeback - Data ordering is not preserved - data may be written into the main filesystem after its metadata has been committed to the journal. This is rumoured to be the highest-throughput option. It guarantees internal filesystem integrity, however it can allow old data to appear in files after a crash and journal recovery.
# commit=30 - Sync all data and metadata every 30 seconds. The default value is 5 seconds. Zero means default. (Setting it to very large values will improve performance.)
# noauto_da_alloc - http://forum.xda-developers.com/showthread.php?t=876069
# nouser_xattr - Support "user." extended attributes (or not).
# errors=continue - errors={continue|remount-ro|panic} Define the behaviour when an error is encountered. (Either ignore errors and just mark the filesystem erroneous and continue,
# inode_readahead_blks=64 -set to 64 from default 32
Click to expand...
Click to collapse
Three words - YOU ARE GREAT! I mean, in the whole explanation you did, I just knew that there is some reverse mounting in init.rc in which few partitions are mounted as data/cache and you cleared my concepts. One more thing related to this I'd like to ask, in sense based roms(For our device) is it possible to do changes in init.rc(which I guess would be required) so that apps are directly installed in sd-ext and the symlink also gets done.
Once again,
THANKS
thewisenerd said:
Note: memory increasing kernels and, kernels that mount certain partitions(like cache, data etc. etc. ) both do the exact same thing.
Clarifications:
Click to expand...
Click to collapse
Lol thats a huge explanation! :good: :highfive:
#Superuser said:
Three words - YOU ARE GREAT! I mean, in the whole explanation you did, I just knew that there is some reverse mounting in init.rc in which few partitions are mounted as data/cache and you cleared my concepts. One more thing related to this I'd like to ask, in sense based roms(For our device) is it possible to do changes in init.rc(which I guess would be required) so that apps are directly installed in sd-ext and the symlink also gets done.
Once again,
THANKS
Click to expand...
Click to collapse
Yes, it is possible. Open your init.rc and find the following line:
Code:
mkdir /data/app 0771 system system
mkdir /data/app-private 0771 system system
mkdir /data/app-asec 0700 root root
mkdir /data/app-lib 0771 system system
Now change it like this:
Code:
# For installing apps directly to /sd-ext:
mkdir /sd-ext/app 0771 system system
mkdir /sd-ext/app-private 0771 system system
mkdir /sd-ext/app-asec 0700 root root
mkdir /sd-ext/app-lib 0771 system system
# Now the symlinking part:
symlink /sd-ext/app /data/app
symlink /sd-ext/app-private /data/app-private
symlink /sd-ext/app-asec /data/app-asec
symlink /sd-ext/app-lib /data/app-lib
NOTE: Before doing this make sure that you have mounted /sd-ext partition.
@thewisenerd....excellent post.....cleared so many doubts....You are really great.
I have a question, I am no dev but just trying to learn some basics about android. As u said that ramdisk does the job of mounting sd partitions using the reverse mounting thing. What is the job of the scripts like int2ext or ungaze or mount2sd.
Is it like when the reverse mounting is not done in ramdisk we need to use these scripts. If yes, then how do these scripts talk 2 ramdisk or kernel to tell them to mount these sd partitions.
I know this may sound noob to you. But m just trying to learn some basics.
@cute_prince Thanks. Now, I'm gonna post all my doubt related to kernels and ramdisks! Thanks to @thewisenerd as well!
cuteitsme said:
@thewisenerd....excellent post.....cleared so many doubts....You are really great.
I have a question, I am no dev but just trying to learn some basics about android. As u said that ramdisk does the job of mounting sd partitions using the reverse mounting thing. What is the job of the scripts like int2ext or ungaze or mount2sd.
Is it like when the reverse mounting is not done in ramdisk we need to use these scripts. If yes, then how do these scripts talk 2 ramdisk or kernel to tell them to mount these sd partitions.
I know this may sound noob to you. But m just trying to learn some basics.
Click to expand...
Click to collapse
Everyone's a newbie (unless they remain to stay a n00b). Anyways, let's get back to on-topic.
So... How does these files in
Code:
/system/init.d/<insert-script-name>
cause the reverse-mount?
For this, we look back, into the init.rc and init.pico.rc files
If you'd read this, https://android.googlesource.com/platform/system/core/+/master/init/readme.txt, you'd find that the Android Init Language gives you an "exec" command for running apps/scripts. So, you should have gotten the hint by now
So, open up init.rc and search for any "exec" command. I can just make it easier, but I want you to find any "exec" call that runs processes from /system/*.
OFC, I'd be telling the answer below, but I want you to find it too
So, here's the key. You're likely to find lines as the same as, or similar to below lines:
Code:
# Run sysinit
exec /system/bin/sysinit
in any one of the *.rc files (mostly init.rc or init.pico.rc).
So, lets take a look at this file.
Below is the above file (/system/bin/sysinit) from CM10.2, weekly 9
Code:
#!/system/bin/sh
export PATH=/sbin:/system/sbin:/system/bin:/system/xbin
/system/bin/logwrapper /system/xbin/run-parts /system/etc/init.d
So, what's this, exactly?
Linux users would be familiar with the PATH variable name
And, logwrapper? Here's standard help:
Code:
Usage: logwrapper [-d] BINARY [ARGS ...]
Forks and executes BINARY ARGS, redirecting stdout and stderr to
the Android logging system. Tag is set to BINARY, priority is
always LOG_INFO.
-d: Causes logwrapper to SIGSEGV when BINARY terminates
fault address is set to the status of wait()
So, its going to execute a binary file, but which?
The next "argument" reads "/system/xbin/run-parts"
Again, here's standard help:
Code:
BusyBox v1.20.2-cm9 bionic (2012-11-18 13:31 +0100) multi-call binary.
Usage: run-parts [-t] [-l] [-a ARG] [-u MASK] DIRECTORY
Run a bunch of scripts in DIRECTORY
-t Print what would be run, but don't actually run anything
-a ARG Pass ARG as argument for every program
-u MASK Set the umask to MASK before running every program
-l Print names of all matching files even if they are not executable
So, run a bunch of scripts in a directory?
That pretty much explains why the next "argument" follows as "/system/etc/init.d ".
So, that's how init.d works :cyclops:
============================================================================================================
Now, moving on to memory increasing scripts (oh! I hate that slang)
Anyways, so, we found out that during the boot, the init.rc file is calling the /system/bin/sysinit file. If you'd notice, a few lines "above",
Here's something from http://www.kpbird.com/2012/11/in-depth-android-boot-sequence-process.html
Below is the sequence of android booting. Note that until all these processes are completed, you still see the boot logo. So, if your phone's struck at green htc screen, then, any one of this processes is.. hung.
on early-init:
Set init and its forked children's oom_adj.
Set the security context for the init process.
on init
setup the global environment
Create cgroup mount point for cpu accounting and many other things...
on fs
mount mtd partitions
on post-fs
change permissions of system directories
on post-fs-data
change permission of /data folders and sub folders
on boot
basic network init ,Memory Management ,etc
service servicemanager
start system manager to manage all native services like location, audio, shared preference etc..
service zygote
start zygote as app_process
So, the "/system/bin/sysinit" runs at the "boot" service. Also, it is run by the bootloader. So, it has full access to the root file system that the ramdisk creates. Now, to be noted: the "boot" service runs after the "fs" service, evidently, because else, you wouldn't be able to access the "/system/bin/sysinit" otherwise.
So, the "sysinit" script runs, running all the files from /system/etc/init.d with the help of busybox
That's about it
But, how does the reverse-mounting take place!?
Let me take the example of the simplest reverse mounting script I've ever found: int2ext. I've seen the mounts2sd script, and think its bloated, IMO, because why have a 1000+ lines script, when a script with >40 lines can do it :angel: ) (no offense). For me, just placing script, setting permissions, rebooting should increase the memory of my device. No roundabout stuff.
So, I'd be explaining how int2ext works, below:
Note: before you proceed, you'd have noticed that the sysinit file set the PATH variable. Its the location for all the accessible binary files. (if you don't understand this, using linux might help you understand this better ) This is similar to the PATH variable in windows too.. This just tells the system where to look for executable binary files/programs.
So, here's a very minimal int2ext script (modified to make this post smaller):
The purple lines ("Royal Blue" according to XDA), are the lines of code. Rest are my comments.
Credits go to original file, got from here: https://github.com/croniccorey/cronmod-scripts/blob/master/int2ext%20scripts/INT2EXT
## Only continue if mmcblk0p2 exists
if [ ! -e /dev/block/mmcblk0p2 ] //If /dev/block/mmcblk0p2 doesn't exist
then //then
exit //this script exists. this code's here for safety.
fi;
## Set SD cache size
SD_CACHE=/sys/devices/virtual/bdi/179:0/read_ahead_kb //read_ahead_kb is the amount of kb that the kernel reads, beforehand.
if [ -e $SD_CACHE ] //checking the existence of the file, just in case...
then
busybox echo "2048" > $SD_CACHE; //2048 is found to be an optimum value for sdcards, class 4 and better.
fi;
## Make /sd-ext directory if needed and unmount /sd-ext if it already mounted
##why? because the writer croniccorey, has done some thinking here
##will explain side by side... If the directory /sd-ext doesn't exist, its created here.
##note: the commands run by the init.rc have full access to the root file system created.
if [ ! -e /sd-ext ] //if doesn't exist sd-ext foler in root file system
then
busybox mount -o remount,rw /; //mount the root file system "/" as rewritable
busybox mkdir /sd-ext; //create a directory named sd-ext
busybox mount -o remount,ro /; //mount the file system as read-only again
else
busybox umount /sd-ext; //else, unmount the sd-ext partition, i.e. partition in the sd-card.
fi;
## Move /data mount point to /sd-ext
INT_DATA=$(busybox mountpoint -n /data | cut -d ' ' -f1) //this gets the mountpoint of the data partition.
// this command "busybox mountpoint -n /data | cut -d ' ' -f1" is actually runnable, and you'd get the mount point
// of the /data partition in the internal memory (which is this: /dev/block/mtdblock5)
busybox umount /data; //unmount the /data partition too/
// the data partition is unmounted because we're going to do some stuff
busybox mount $INT_DATA /sd-ext;
// mount the internal data partition in the sd-ext folder
## Mount mmcblk0p2 to /data
busybox mount -o noatime,nodiratime,nosuid,nodev /dev/block/mmcblk0p2 /data; //well, this is self-explanatory. mount the partition in sdcard into internal memory.
busybox chown 1000:1000 /data; //chown the folder by root (get more help by running "man chown" in a shell)
busybox chmod 771 /data; //chmod the folder (get more help by running "man chmod" in a shell)
## Move existing files
if [ ! -e /data/app ] //why /data/app? simply, it can also be anything else like /data/data...
then
busybox mv /sd-ext/* /data;
// the sd-ext folder has the files of the internal /data partition
// those are moved to the sd-card's partition, which is mounted in /data now.
fi;
## Unmount /sd-ext
//unmount the internal data partition.
// we have the partition from the sd-card mounted in the /data partition currently.
busybox umount /sd-ext;
sync;
//sync changes with file system
Click to expand...
Click to collapse
the comments should explain almost everything...
This script, is almost flawless. Couldn't find any bugs in it. Does what would have been done by changing the mount point in the "on fs" part, where it mounts the file system.
An added advantage is that this can be put into use any time you want... Example, you use your phone, internal memory gets filled up, just put this script in /system/etc/init.d, and set permissions, and reboot! voila! memory increased!
Note: reversing this can't be done by just deleting the script. an appropriate script that moves back user data to internal partitions may be needed.
Also note:
You can always tweak this command:
busybox mount -o noatime,nodiratime,nosuid,nodev /dev/block/mmcblk0p2 /data;
for better performance. Check my config, in post 8 or so... 1'st page..
You should've also guessed why we set permissions to executable, by now... Else, the file wouldn't be able to "execute"
P.S. Adding a few lines to init.rc should make it possible to have no permission change, but, that can wait for another day...
Simply awesome.....what an explanation sirji....
Still trying to understand some part but i will have to do more reading for that first....that i will do.....but must say U rock man.....thanks a lot for this....
thewisenerd said:
Everyone's a newbie (unless they remain to stay a n00b). Anyways, let's get back to on-topic.
So... How does these files in
Code:
/system/init.d/<insert-script-name>
cause the reverse-mount?
For this, we look back, into the init.rc and init.pico.rc files
If you'd read this, https://android.googlesource.com/platform/system/core/+/master/init/readme.txt, you'd find that the Android Init Language gives you an "exec" command for running apps/scripts. So, you should have gotten the hint by now
So, open up init.rc and search for any "exec" command. I can just make it easier, but I want you to find any "exec" call that runs processes from /system/*.
OFC, I'd be telling the answer below, but I want you to find it too
So, here's the key. You're likely to find lines as the same as, or similar to below lines:
Code:
# Run sysinit
exec /system/bin/sysinit
in any one of the *.rc files (mostly init.rc or init.pico.rc).
So, lets take a look at this file.
Below is the above file (/system/bin/sysinit) from CM10.2, weekly 9
Code:
#!/system/bin/sh
export PATH=/sbin:/system/sbin:/system/bin:/system/xbin
/system/bin/logwrapper /system/xbin/run-parts /system/etc/init.d
So, what's this, exactly?
Linux users would be familiar with the PATH variable name
And, logwrapper? Here's standard help:
Code:
Usage: logwrapper [-d] BINARY [ARGS ...]
Forks and executes BINARY ARGS, redirecting stdout and stderr to
the Android logging system. Tag is set to BINARY, priority is
always LOG_INFO.
-d: Causes logwrapper to SIGSEGV when BINARY terminates
fault address is set to the status of wait()
So, its going to execute a binary file, but which?
The next "argument" reads "/system/xbin/run-parts"
Again, here's standard help:
Code:
BusyBox v1.20.2-cm9 bionic (2012-11-18 13:31 +0100) multi-call binary.
Usage: run-parts [-t] [-l] [-a ARG] [-u MASK] DIRECTORY
Run a bunch of scripts in DIRECTORY
-t Print what would be run, but don't actually run anything
-a ARG Pass ARG as argument for every program
-u MASK Set the umask to MASK before running every program
-l Print names of all matching files even if they are not executable
So, run a bunch of scripts in a directory?
That pretty much explains why the next "argument" follows as "/system/etc/init.d ".
So, that's how init.d works :cyclops:
============================================================================================================
Now, moving on to memory increasing scripts (oh! I hate that slang)
Anyways, so, we found out that during the boot, the init.rc file is calling the /system/bin/sysinit file. If you'd notice, a few lines "above",
Here's something from http://www.kpbird.com/2012/11/in-depth-android-boot-sequence-process.html
Below is the sequence of android booting. Note that until all these processes are completed, you still see the boot logo. So, if your phone's struck at green htc screen, then, any one of this processes is.. hung.
on early-init:
Set init and its forked children's oom_adj.
Set the security context for the init process.
on init
setup the global environment
Create cgroup mount point for cpu accounting and many other things...
on fs
mount mtd partitions
on post-fs
change permissions of system directories
on post-fs-data
change permission of /data folders and sub folders
on boot
basic network init ,Memory Management ,etc
service servicemanager
start system manager to manage all native services like location, audio, shared preference etc..
service zygote
start zygote as app_process
So, the "/system/bin/sysinit" runs at the "boot" service. Also, it is run by the bootloader. So, it has full access to the root file system that the ramdisk creates. Now, to be noted: the "boot" service runs after the "fs" service, evidently, because else, you wouldn't be able to access the "/system/bin/sysinit" otherwise.
So, the "sysinit" script runs, running all the files from /system/etc/init.d with the help of busybox
That's about it
But, how does the reverse-mounting take place!?
Let me take the example of the simplest reverse mounting script I've ever found: int2ext. I've seen the mounts2sd script, and think its bloated, IMO, because why have a 1000+ lines script, when a script with >40 lines can do it :angel: ) (no offense). For me, just placing script, setting permissions, rebooting should increase the memory of my device. No roundabout stuff.
So, I'd be explaining how int2ext works, below:
Note: before you proceed, you'd have noticed that the sysinit file set the PATH variable. Its the location for all the accessible binary files. (if you don't understand this, using linux might help you understand this better ) This is similar to the PATH variable in windows too.. This just tells the system where to look for executable binary files/programs.
So, here's a very minimal int2ext script (modified to make this post smaller):
The purple lines ("Royal Blue" according to XDA), are the lines of code. Rest are my comments.
Credits go to original file, got from here: https://github.com/croniccorey/cronmod-scripts/blob/master/int2ext%20scripts/INT2EXT
the comments should explain almost everything...
This script, is almost flawless. Couldn't find any bugs in it. Does what would have been done by changing the mount point in the "on fs" part, where it mounts the file system.
An added advantage is that this can be put into use any time you want... Example, you use your phone, internal memory gets filled up, just put this script in /system/etc/init.d, and set permissions, and reboot! voila! memory increased!
Note: reversing this can't be done by just deleting the script. an appropriate script that moves back user data to internal partitions may be needed.
Also note:
You can always tweak this command:
busybox mount -o noatime,nodiratime,nosuid,nodev /dev/block/mmcblk0p2 /data;
for better performance. Check my config, in post 8 or so... 1'st page..
You should've also guessed why we set permissions to executable, by now... Else, the file wouldn't be able to "execute"
P.S. Adding a few lines to init.rc should make it possible to have no permission change, but, that can wait for another day...
Click to expand...
Click to collapse
I read somewhere, that init.d scripts run alphabetically, maybe this is the reason int2ext is named as 40int2ext so that it starts first?
#Superuser said:
I read somewhere, that init.d scripts run alphabetically, maybe this is the reason int2ext is named as 40int2ext so that it starts first?
Click to expand...
Click to collapse
Yeah....I guess that's the linux thing. I think the higher the no. the late the script will be called. This is basically to run the more important scripts before the other scripts.
hi i unpacked the boot.img files of cm11 beta 1 and 2 in order to understand this better and understood many things which u have explained.
I did found those lines starting with exec in some init. files.
Thanks a lot for this. Since u must be aware that the sd-ext is not mounting in buid 2 and thus int2ext is not working. So, out of curiosity I was trying to understand the difference between these two files from different builds(beta 1 and 2) but not able to find any.
Can u give any hint as to why even after having the same lines in fstab.pico of build 1 and build 2 int2ext was working in buld 1 and not in build 2. Of course by doing reverse mounting we can overcome this issue. But I am just trying to understand the difference between the two builds at ramdisk level.
cuteitsme said:
hi i unpacked the boot.img files of cm11 beta 1 and 2 in order to understand this better and understood many things which u have explained.
I did found those lines starting with exec in some init. files.
Thanks a lot for this. Since u must be aware that the sd-ext is not mounting in buid 2 and thus int2ext is not working. So, out of curiosity I was trying to understand the difference between these two files from different builds(beta 1 and 2) but not able to find any.
Can u give any hint as to why even after having the same lines in fstab.pico of build 1 and build 2 int2ext was working in buld 1 and not in build 2. Of course by doing reverse mounting we can overcome this issue. But I am just trying to understand the difference between the two builds at ramdisk level.
Click to expand...
Click to collapse
Hmm... Could you post the two boot.img's here? I'd like to have a look
thewisenerd said:
Hmm... Could you post the two boot.img's here? I'd like to have a look
Click to expand...
Click to collapse
Sure y not.....here u go
@thewisenerd: does the ION Kernel used in cyanogenmod 11 support swap
PiCo HackR said:
@thewisenerd: does the ION Kernel used in cyanogenmod 11 support swap
Click to expand...
Click to collapse
The question is: Why do you need swap?

Phone manufacturers hate it! Get true adoptable storage with this trick!

Joke title aside, I had an idea for getting unencrypted and thereby instantly mounting sdcard as internal storage.
The idea is simply going inti the fstab and simply changing the entry for /data into
Code:
/dev/block/mmcblk1p1
. This requires the sdcard to be freshly formatted I think (probably in either ext4 or f2fs)
Going even further, we could get back the internal storage and make it appear as an external sdcard, so it's not totally wasted. (In theory, maybe I'm overlooking something). For now, it's not in the modified fstab.
Only do this if you don't have anything to lose on the phone and on the sdcard
Here's the modified fstab. Would be interesting to see if someone could test it. Copy and paste the text in the spoiler into a new file called fstab.qcom (make sure to save in Linux line breaks if you're on Windows).
Make sure to make a backup of /system/vendor/etc/fstab.qcom before proceeding via adb pull or some other method.
Reboot to TWRP
Again, make sure you have backed up the file you're about to overwrite
Do adb push fstab.qcom /system/vendor/etc/
Reboot
See what happens
Spoiler
Code:
# The filesystem that contains the filesystem checker binary (typically /system) cannot
# specify MF_CHECK, and must come before any filesystems that do specify MF_CHECK
#<src> <mnt_point> <type> <mnt_flags and options> <fs_mgr_flags>
/dev/block/bootdevice/by-name/system / ext4 ro,barrier=1,discard wait,slotselect
/dev/block/mmcblk1p1 /data f2fs nosuid,nodev,noatime,discard,fsync_mode=nobarrier wait,check,encryptable=footer,quota
/dev/block/mmcblk1p1 /data ext4 nosuid,nodev,noatime,noauto_da_alloc wait,check,encryptable=footer,quota,formattable
/dev/block/bootdevice/by-name/persist /mnt/vendor/persist ext4 nosuid,nodev,noatime wait,check
/dev/block/bootdevice/by-name/dsp /vendor/dsp ext4 ro,nosuid,nodev wait
/dev/block/bootdevice/by-name/modem /vendor/firmware_mnt vfat ro,shortname=lower,uid=1000,gid=1000,dmask=227,fmask=337,context=u:object_r:firmware_file:s0 wait,slotselect
/dev/block/bootdevice/by-name/misc /misc emmc defaults defaults
/dev/block/bootdevice/by-name/config /frp emmc defaults defaults
#/devices/platform/soc/7864900.sdhci/mmc_host* auto auto defaults wait,voldmanaged=sdcard1:auto,noemulatedsd,encryptable=userdata
/devices/platform/soc/7000000.ssusb/7000000.dwc3/xhci-hcd.0.auto* auto auto defaults wait,voldmanaged=usb:auto
#/dev/block/zram0 none swap defaults zramsize=536870912,max_comp_streams=8
Looking forward to hearing from someone if it worked and how the performance is.
Good Luck with testing.
"Phone manufacturers hate it! Get true garbage I/O performance with this trick!"
Emmc memory is much faster than sd-cards and even more importantly it's much more failproof than the regular consumer grade sd-card. But if low on storage for apps, sure
flex1911 said:
"Phone manufacturers hate it! Get true garbage I/O performance with this trick!"
Click to expand...
Click to collapse
Wel it wasn't intended to be a serious mod. I'm mostly just curious if it works and need a guinea pig as I can't afford wiping my phone right now ?
flex1911 said:
"Phone manufacturers hate it! Get true garbage I/O performance with this trick!"
Click to expand...
Click to collapse
LOL :laugh::laugh::laugh:

Categories

Resources