Attend XDA's Second Annual Developer Conference, XDA:DevCon 2014!
5,730,580 Members 40,689 Now Online
XDA Developers Android and Mobile Development Forum

[KERNEL][101111] Universal lagfix [EXT4,JFS] and tweak kernel [BLN2.2] {0.3}

Tip us?
 
sztupy
Old
(Last edited by sztupy; 21st December 2010 at 08:24 AM.) Reason: 0.3 + BLN2.2 released
#1  
sztupy's Avatar
Recognized Developer - OP
Thanks Meter 854
Posts: 1,054
Join Date: Dec 2008
Location: London

 
DONATE TO ME
Default [KERNEL][101111] Universal lagfix [EXT4,JFS] and tweak kernel [BLN2.2] {0.3}

Development continues here: http://forum.xda-developers.com/showthread.php?t=881837

Universal lagfix kernel project.

This project is aimed at multiple audiences.
  1. If you think you're an end user read on.
  2. For lagfix and kernel developers check the second post.
  3. Download, changelog, bugs and other links can be found at the third post.

Credits
  • ChainFire for the original cf-root initramfs
  • hardcore for the speedup hacks
  • nikademus for the compiled jfs utils
  • neldar for BackLightNotification
  • newmail for some kernel modules
  • RyanZA for OCLF and for being helpful
  • supercurio for Voodoo
  • ykk_five for being helpful (and for the memory tweaks)
  • z4ziggy for z4mod
  • and for everyone else I might have missed. (like myself - I'm an egoist you know... and for all the people that helped the guys I credited above. And for the people who helped the guys that helped the guys credited above. And for XDA of course.)

If you only care about points
OhmygodIcanget2kpointsatquadranttoobadI'vealreadys oldSGSbecauseitonlyhas300MBraminsteadof512asadvert isedandboughtadesirebecauseilikehowitcrapsatmultit ouch.

For the rest of the people

What is this about?
This project has multiple aims:
  • A JPM based kernel with ext4, jfs, tun and BLN support
  • An init script which supports multiple lagfix schemes
  • Init.d support (without early script support)
  • A modified ClockWorkMod that
    • Has better support for some features of the SGS-I9000
    • Includes support for rooting the device
    • Includes support for switching the lagfix schemes
    • Has some tweaking options
  • Various additions that might help the other lagfix/kernel developers

How does this work?
Simply flash the kernel to any JPM/JP6 based, unlagfixed ROM. By default it won't apply any lagfix scheme, so you might use it as a simple ROM, with built in ClockworkMod + rooting support. If you have a complete ROM package (with dbdata.rfs and an older csc file (it won't work with some of the newer csc files) ) you can also flash it with the other parts, just replace the zImage in the PDA.tar with the one supplied. The ROM was tested with the original JP6 and JPM ROMs, and with my Multinational 3.0 ROM.

How can I use the extra features?
Reboot your phone to recovery mode. Under "Advanced ULK", there are some new options:
  • Reboot to download: switches to download mode
  • Run 2e recovery: Switches to 2e recovery
  • Install superuser: installs busybox and superuser to the phone
  • Lagfix options: switch between various lagfix schemes
  • Tweak options: switch between various startup tweaks
  • BLN options: Turns BackLightNotification on or off
  • Reset permissions: Resets permissions to the same state as init does

What are the lagfix schemes?
They are ways on how to format and bind the various filesystems. You can chose how you want to format the partitions (data,dbdata and cache), whether you want to use an extra loop device or not, and whether you want to bind some directories from /data to /dbdata.

There are also 8 included pre-defined schemes:
  • OCLF: /data stays at rfs, but has an ext2 loop device on top of it
  • Voodoo: /data is ext4, all others are kept at rfs
  • JFS Voodoo: /data is jfs, all others are still rfs
  • No-RFS Standard: /data is rfs+ext2, all other partitions are ext4
  • No-RFS Advanced: all partitions are ext4
  • No-RFS Advanced JFS: all partitions are jfs
  • No-RFS Overkill: turns on all options: everything is ext4+ext2 and /data/data is bound to /dbdata
  • No-RFS Overkill JFS: turns on all options: everything is jfs+ext2 and /data/data is bound to /dbdata
(If using the overkill scheme using the bind option is dangerous if using too much apps, so you should disable it in the advanced menu.)

Although I used the names OCLF and Voodoo, the ROM is not compatible with any of them, it's just a naming convention I used. Hope RyanZA and supercurio won't mind

Which one should I use?
You decide. OCLF or Voodoo might seem simple but they are actually working great (but for those you can actually use the originals, they are probably much more stable), while NO-RFS Overkill might seem cool, it is clearly an overkill.

What happens after I chose a lagfix scheme?
If the chosen one is different from the active one the kernel will reformat your device the next start. Before reformatting it will create a nandroid backup, reformats the device then restores the data from your backup.

Is this ROM safe
alpha 0.2 means no. Switching between lagfix schemes might break, and data loss (mostly database corruption) can happen if you're using a lot of loop devices. And this kernel isn't thorougly tested anyway.

How to switch to another kernel/ROM
After disabling the lagfix everything should be fine (except for the possible data corruption). You can always flash another complete ROM package over this using Odin, you'll lose all your data however.

I've found a bug
And you'll find more of them. I'll try to collect them and answers to them at post #3
The Following 7 Users Say Thank You to sztupy For This Useful Post: [ Click to Expand ]
 
sztupy
Old
(Last edited by sztupy; 20th October 2010 at 10:03 PM.)
#2  
sztupy's Avatar
Recognized Developer - OP
Thanks Meter 854
Posts: 1,054
Join Date: Dec 2008
Location: London

 
DONATE TO ME
Internal workings.

In this post I'll try to describe how this works, and how it might be useful for other people.

The Kernel uses both the pre-init trick and the bootlogos trick to load up, and do it's stuff. In the pre-init phase it does the following:
  • initializes the devices
  • checks the actual state of the partitions, and decides which lagfix scheme is active
  • checks the config (resides in /system/etc/lagfix.conf), and if they differ runs the converter application
  • if they don't differ then it starts to mount the devices, and let's init run.
  • if during the mounting a fatal error occurs, it prints the log, waits for a couple of seconds and reboots the device.

It does the filesystem checks by mounting and checking whether mounting succeded or not. To defend against samsung's init's reformatting, it simply removes the fat.format command.

In the post-init phase it removes some files (mainly the symlinks to busybox, so they won't interfere with the busybox installed on the system). It also reinstalls fat.format, because it might be needed later.

The lagfixer is built inside clockworkmod, which has the following advantages:
  • Can use nandroid backup
  • Can use the framebuffer to show the progress (this makes it much easier to debug problems)

Besides the lagfixer there is also a "graphsh" application, which will run a specified command and prints its output to the framebuffer (the reasons for this are the same: it's much easier to debug this way than to check a log file copied to the sdcard). If a fatal error occurs this command is run so the end-user can see some logs. (all of this is still pre-init). The only problem with using the framebuffer is that core android won't boot up properly if the framebuffer was initialized beforehand (it switches to QVGA with overlapped screens... it's actually quite fun to try using android that way). That's why I always reboot after using either 'graphsh' or 'lagfixer', except for recovery modes, because CWM is using the same framebuffer anyway.

The initramfs is "ro.debuggable=1" so if anything happens one can connect to the phone in adb root mode, to check for errors. Adb is enabled by default in both CWM and base android mode. I don't know the drawbacks of using debuggable=1.

CWM was modified in order to be able to handle the various lagfix schemes. If it tries to mount, unmount or format /data,/dbdata or /cache, it asks for the lagfixer to do the actual mount, unmount or format. Therefore if one saves or restores a backup it will always see and use the actual files, and not the loop device file.

There were some other minor modifications, like binding the home button too to the enter key, using /mnt/sdcard instead of /sdcard, and the ability to back up the efs partition too. (/efs won't be restored however).

There is also a small modification in how the updates work. If there is an update, the init will always run samsung's 2e recovery, if not it will use CWM (you can use CWM's menu to run an update using CWM if desired). This is to maximize compatibility with updates.

About the compiled files:
I had a hard time getting the binaries to work, even when compiling in static mode. All of the binaries are either compiled by me using bionic (AOSP), or used from other sources (but they seem to be using bionic too). The main advantage is that the recovery binary is actually only around 700k, but has a working busybox implementation, a working recovery and some other small stuff. The main problem is with the other binaries (mainly with e2fsprogs). If I could cut from the size the whole initramfs might fit into an official kernel, so it could be used by anyone.
 
sztupy
Old
(Last edited by sztupy; 11th November 2010 at 09:14 PM.) Reason: v0.3 released
#3  
sztupy's Avatar
Recognized Developer - OP
Thanks Meter 854
Posts: 1,054
Join Date: Dec 2008
Location: London

 
DONATE TO ME
Links

Changelog
Version 0.3
- before the lagfix gets applied there are now multiple options to chose from:
-- backup+restore (the original way)
-- backup, but don't restore (this eventualy results in a factory reset)
-- no backup (this also results in a factory reset)
-- go to recovery mode (to debug)
-- erase config file (to get back to the old options)
- the screen glitch in the first screen is now gone (because the kernel got smaller)
- jfsutils are ported to bionic (takes less space)
- there is a new option that will do the same restore permissions run, as the init script does
- I also added a few fixes to the CWM fix_permissions script, although I don't tested them yet (so it might brick the phone)
- Added two more rooting option:
-- the old one simply copyes busybox, superuser and su to the phone and adds symlinks to busybox
-- the new ones will also remove some old toolbox commands, so if you use the shell a lot, they won't interfere. The first mode only removes the base utils, like ls,mkdir,rm or ln
-- the second mode removes every toolbox command that has an equivalent busybox command (like mount, lsmod, rmmod, etc.)
- Adeed an option to get back to 2e recovery from CWM

Remarks
It seems that formatting dbdata as rfs only works, if you use the 512 PIT file (more exacty it only works if you have used the 512 PIT file the last time you've ticked re-partition in odin). This is probably due to the fact thet the 512 and 803 pit files reserve different space for the dbdata and for the system partition (the 803 pit file reserves 40 units less for the dbdata than the 512 pit file)

Version 0.2
- efs is not backed up automatically during lagfixing (but it's still backed up during ordinary backups)
- added jfs support and some more lagfix schemes using jfs
- added backlightnotification support, with the option to turn it on and off
- added startup script tweaks support, with options to turn them on and off
- removed ext2 support for the base mounts (might be put back into later)
- bind now only binds /data/data (should use less space)
- some minor bugfixes relating

Remarks
- If Updating from 0.1 to 0.2: If binds were turned on you have to turn them off before updating. After the update has finished you can turn them back on if desired.

Known bugs
After the lagfix conversion is done the phone reboots and the lagfix conversion starts over again
This means that the conversion took place, but the result is not the same as was desired. You should reboot into recovery mode and remove the config file.

After rebooting I have a lot of FC's - After switching lagfix schemes I have a lot of FC's
This is probably because of a database corruption. Try loading an earllier backup.

Can't download anything from market
Some configurations might have this problem, I'm still trying to find out why this happens.

Can't download some apps, like angry birds from the market
Retry, it should work after a while. If it still fails remove the external sd.

Shutdown fails on some configurations
Until I find a way to hook onto the shutdown script this might happen on more complex configurations (like the NO-RFS overkill)

Can't get back to rfs on /dbdata
Reverting the lagfix on /dbdata only works if you used the 512 pit file the last time you checked re-partition in odin.
The Following 2 Users Say Thank You to sztupy For This Useful Post: [ Click to Expand ]
 
dwillMUFC
Old
#4  
dwillMUFC's Avatar
Senior Member
Thanks Meter 39
Posts: 224
Join Date: Apr 2010

 
DONATE TO ME
I for one am excited


Dan
 
RyanZA
Old
#5  
Senior Member
Thanks Meter 730
Posts: 2,021
Join Date: Jan 2006
Location: JHB
Can't wait to see this.
 
halabibk
Old
#6  
Senior Member
Thanks Meter 59
Posts: 130
Join Date: Jan 2009
I am waiting too ++++
 
supercurio
Old
#7  
supercurio's Avatar
Senior Recognized Developer
Thanks Meter 5070
Posts: 3,529
Join Date: May 2010
Location: Chambéry

 
DONATE TO ME
Lol 100% teasing ^^
 
shahadat
Old
#8  
shahadat's Avatar
Senior Member
Thanks Meter 19
Posts: 128
Join Date: Sep 2010
gingerbread?
 
sztupy
Old
#9  
sztupy's Avatar
Recognized Developer - OP
Thanks Meter 854
Posts: 1,054
Join Date: Dec 2008
Location: London

 
DONATE TO ME
Quote:
Originally Posted by shahadat View Post
gingerbread?
would be a bit early :P
 
DocRambone
Old
#10  
Recognized Developer
Thanks Meter 2613
Posts: 6,349
Join Date: Jan 2010
Location: Stockholm

 
DONATE TO ME
Fantastic
Testing now on a very stripped JP6...

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes


TRENDING IN THEMER...