[KERNEL] marmite v10.6 final

Search This thread
B

bedalus

Guest
Download latest marmite: this post

Download marmite for old versions e.g. Jellybean: version matrix

7459727480_0f7e5ec3f5.jpg

Marmite once made me more sick than I'd ever been before or since.
But I still love it. #truefact


This kernel is based on the stock jb kernel. I have kept, added or tweaked the features I approve of:
- CFQ I/O scheduler (best performing)
- Ondemand, tweaked values
- BLN (no blinking), BLD and Fast-Charge
- more free RAM
- Bluetooth fixed and PM_FAST (keeps fast wifi even with screen off)
- Voodoo sound and colours with my settings for a stable whitepoint at all brightnesses.
- Zcache: compressed cache stored in ram, improves performance by retrieving cached pages from ram rather than flash
- MTP (explanation below the links)
- custom OC available

Voltage and OC quoted from a chip designer with 14 years industry experience: here.

What is ORD?: here.

Facebook by leap_ahead: here

What you need to know about Custom OverClocking [OC]: here.

Interesting discussion of gamma and RGB setting (voodoo): here.

My kernel doesn't wipe your cache or dalvic, so you can flash and reboot in less than a minute. Read this.

What is MTP?
Firstly, huge props to krfoy for making this work with the any-kernel script. Great work!

Microsoft's Media Transfer Protocol. It allows for dramatically faster transfers too the phone, so it is really good when you are copying over films or mp3 folders. What's really good is that you can continue to use your apps while these transfers happen. Faster? More functional? You bet! The limitations are that it is relatively unsupported on non-Windows platforms. However, you can investigate these possibilities: Ubuntu: here. --- --- Mac: here.

How to Select MTP/PTP
Go to Settings>Storage>(Hit capacitive menu button)>USB Computer Connection to select.

If your ROM doesn't have the switch there then check this tip from pigsan! or use the command line.

* * *

Big thanks: ...to the community! So many people supported my research that it's impossible to thank them all individually. Particular thanks to tchaari and Harbb. Credit goes to: _thalamus for getting me started with git, correcting my misconceptions about merging; KalimochoAz for CM; ezekeel for the incredible variety of mods; mathkid95 for ondemand tweaks; steve.garon for help with scripting; morfic for his advice and permission to use his colour settings; and supercurio for voodoo. Big thanks to krarvind for MTP, legend! Congrats to krfoy for enabling MTP via the any-kernel script. Nice work! Thanks to caliban2 for his consistent and unbiased feedback. Thanks to brainmaster, when I originally joined the forums for being so helpful. Hopefully I treat newcomers just as kindly.

Old versions: http://goo.gl/B0p8Z
TOOLCHAIN: Linaro a8 optimised by @Christopher83 here
SOURCE: http://github.com/bedalus/marmite
 
Last edited:
B

bedalus

Guest
Download ICS version: v1.5b (For ICS 4.0.4)
NOTE: Opening AnTuTu breaks Deep Idle! If you have to use this app, disable DI until you can reboot.
Flashable Patch for BiggerMem: http://d-h.st/NSx

This kernel is based on the work of the cyanogenmod team:
Cyanogenmod base features:
- Merged to 3.0.39 from mainline.
- Voodoo sound v10
- "Biggermem" 404MB (morfic's idea if I remember right)
- BLN
- SLUB memory allocator*
- Deep Idle:- Kalim included code that limits the maximum frequency to 800MHz when DI is active. Great innovation Kalim! I have modified this code to fix the screen off frequency to 400MHz for efficiency.
I have enabled the things I like:
- CFQ scheduler. It's a tiny notch down from deadline in performance, but very consistent. Kalim disabled it in the nightlies where I got my base configuration, so I've brought it back.
- Deadline I/O scheduler adjusted for flash for lowest I/O latencies (thanks thalamus)
- BLX
- BLD
- Voodoo colour
- Gamma settings by morfic, thank him for giving permission :)
>>> Try these settings in Voodoo: raise all gamma to 20, then set RGB to 189-185-214
- SmartassV2 governor*
- Deep Idle locks to 400MHz regardless of your governor settings. This is an adaptation of kalim's code. Why? Because I proved that 400MHz is the most power saving state for Deep Idle. Excerpt from research: here.
- Removed pointless governors
- Removed noop scheduler
- Removed OC and custom voltage
- PM_FAST (fast wifi with screen off: power saving for downloading files, but slightly higher power use when idle compared to PM_MAX)
- 1.2 GHz step
- v0.6 onward have MTP working for ROMs that support it. Krarvind is the one who made this work (donate to him here), with the help of another dev, so kudos to them.

Version History
v1.5b: http://d-h.st/BhK
-Morfic's colours fixed!
-Merged to 3.0.39
-DI fixed at 400 MHz, the most power saving state, using thalamus' code, which is stable!
-ICS ONLY!!

v1.4d http://d-h.st/66r (ICS ONLY)
-stable
-probably last version I'll do for ICS
-DI fixed at 800MHz
-reorganised fixed DI code a little
-If you have no video on MIUI, check out this tip!

v1.4b http://d-h.st/l7X
-Made some code reorganisation based on thalamus suggestion
-Created a patch!

v1.4 http://d-h.st/MoU
-Made DI fix at 800 MHz using the performance governor which saves CPU cycles

v1.4_test http://d-h.st/UOt
-Possibly unstable, please try to collect last_kmsg
-Includes new 'performance DI': When Deep Idle state is called the governor switches to performance to save CPU cycles
-DI fixed at 800MHz for stability
-thalamus' DI spinlock patch
-Mathematically sensible smartassV2 tunable settings to save CPU cycles (working well)

v1.3c: http://d-h.st/HJY
-Stable
-Minor bugfix release (bugs in freq stepping that were my own faulty code merges)
-_thalmus' DI patch
-If you have no issues with 1.3b skip this, and wait for v1.4

v1.3b http://d-h.st/n55
-Frequency stepping bugfix
-Stable (I really mean it this time :p) ...so I deleted the other download links, apart from the early _thalamus based one.
-Shrank the download to a normal size: I'd forgotten to remove the redundant zImage from the any-kernel script. (I don't use that since I flash a boot image).

v1.3
-thalamus' mutex to spinlock patch has been integrated. I've tested this, as I'm sure thalamus has, and DI of course still works fine, but because this is the first time anyone has touched the DI code in a few months, I think it's safer to call this a TEST release.
-I fixed the minimum fq getting stuck 200MHz issue, which was an issue actually caused by myself: when I was altering the available OC I failed to adjust all the levels correctly.
-Having trouble with 200MHz? >Read this<

All previous releases have been pulled. Use the current stable please! Remember: enjoy marmite!

Big thanks: ...to the community! So many people supported my research that it's impossible to thank them all individually. And big thanks to the developers who have selflessly helped a total noob get his kernel off the ground. Credit goes to: KalimochoAz for representing cyanogenmod in this forum and his tweaks; _thalamus for his patience and getting me started with git and modules, correcting my misconceptions about merging; ezekeel for the mods; mathkid95 for ondemand tweaks; steve.garon for help with scripting; morfic for his advice and permission to use his colour settings; and supercurio for voodoo. Big thanks to krarvind for MTP, legend!

SOURCE: http://github.com/bedalus
 
Last edited:
B

bedalus

Guest
Note: If you want to repost this guide, feel free to download it here (text file, includes all XDA formatting.) Please give credit.

Why would you want to build a kernel yourself?
Have you read this: http://xdaforums.com/showpost.php?p=21006133&postcount=1144

In that spirit, I'm going to attempt to write a plain-English tutorial on what to do to build this kernel. In fact, change one or two URLs, and you could build practically any kernel!

Note: I'm assuming you're on a PC here. I'm also assuming this isn't your first trip to linux-land, and you've at least used the terminal a few times before now. I'm also going to assume that even if you are a noob, you're not mentally sub-normal. :p

Note2: If this is your first time building a kernel, you may want to print this out, and go slowly, and if you get stuck, post about it in the thread! It will help me improve the guide. :)

What makes this different to other tutorials?
I'm a noob at building, but a professional at teaching. It's literally my job! In my noobishness, I made good records of pretty much every step, and I've got lots of time for explaining what each step actually does.

THE STEPS
You'll need one to compile stuff. "For Gingerbread (2.3.x) and newer versions, including the master branch, a 64-bit environment is required." (source)

OK. You're probably thinking of compiling a kernel for ICS or higher right? Is your computer only 32 bit? Pull the processor off the motherboard and count the pins. Just kidding. It won't matter if it is AMD or Intel, but it needs to be a 64 bit processor. I can compile a kernel with just 2GB of RAM and my processor is approaching its 9 year. Even with this lousy set-up, compiling a whole kernel from scratch takes only five minutes.

Install Ubuntu 10.04 64-bit. (Click on this link to download the install CD.)

If you've got a spare hard drive, use the whole thing. If you're good at partitioning, you might consider putting the linux swap partition on a separate disk. You'll want it to be at least 8GB. Putting it on a separate disk will speed things up.

If you don't have a spare disk, you're going to have to resize a partition of an existing OS, to make some new space for Ubuntu. Lets say a minimum of 12GB for the OS plus 8GB for the swap. The more space you can give to the OS, the easier your life will be if you're serious about building stuff.

At the end of the installation it will ask to install a boot-loader. This should be on sda (not sda1!) but you may need to adjust your BIOS to point at the right hard-drive if you later find it doesn't boot into Ubuntu when you restart. Don't worry about Windows, Ubuntu provides a boot menu, so you have the option of booting to Windows instead.

Once Ubuntu is installed, reboot then open a terminal and sort out your credentials:
Code:
sudo passwd root
Type in the password you set during the install, then decide on a password for the root user, and enter it once, then again for confirmation. It can be the same as your user password if you like.

Do some updates (this could take a while):
Code:
sudo apt-get update && sudo apt-get dist-upgrade
When it's finally finished, you'll have to reboot, then repeat until there's no updates left.

You're ready to set up a build environment!
First, you need a whole bunch of packages. You could copy and paste this into your terminal:
Code:
sudo add-apt-repository "deb http://archive.canonical.com/ lucid partner" && sudo apt-get update && sudo apt-get install sun-java6-jdk
That's java sorted.

Next up is the dependencies for compiling stuff:
Code:
sudo apt-get install git-core gnupg flex bison gperf build-essential zip curl zlib1g-dev libc6-dev lib32ncurses5-dev ia32-libs x11proto-core-dev libx11-dev lib32ncurses5-dev lib32z-dev libgl1-mesa-dev g++-multilib mingw32 tofrodos python-markdown libxml2-utils xsltproc libsdl-dev libesd0-dev libwxgtk2.6-dev libncurses5-dev lib32z1-dev gcc-multilib git-core && sudo ln -s /usr/lib32/mesa/libGL.so.1 /usr/lib32/mesa/libGL.so

Make sure ADB is initialised:
Code:
gedit /etc/udev/rules.d/51-android.rules
and copy the below into a blank text file, then edit both instances of <username> to your Ubuntu username (lower-case!) and no chevrons: ="<bedalus>" is wrong. You want ="bedalus"
Code:
# adb protocol on crespo/crespo4g (Nexus S)
SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="4e22", MODE="0600", OWNER="<username>"
# fastboot protocol on crespo/crespo4g (Nexus S)
SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="4e20", MODE="0600", OWNER="<username>"

Now save the file!

Get hold of a Cross-Compiler
Follow this link to Mentor Graphics Sourcery CodeBench LITE and do a free signup to get the download link. You can get hold of other ones, like Linaro or Google's own, but I'm using this as an example, because it's the one I use, and Ezekeel published some R&D here that showed there was no measurable benefit to one toolchain over another.

When you've downloaded it, you need to copy it to /opt:
Code:
cd /home/<username>/Downloads
cp arm-some-date-some-version-some-arch.tar.bz2 /opt

Note- Obviously that's not the actual name of the file! But you can see what it's really called when you download it.

Now go to /opt and unpack it:
Code:
cd /opt
tar xjf arm-some-date-some-version-some-arch.tar.bz2

So I've got all the tools. Now what?
So now you need to get some source code. You can use 'git clone' if you don't plan on publishing your kernel. But if you've made some modifications and want to share your end result, you need to obey the GPL terms for the linux kernel, which is Open Source, meaning that you are required to make your source available publicly.

Go to github: https://github.com/
...and sign up. It's just a free registration provided you are non-commercial. Github has some useful getting started tutorials, which I suggest you follow:
https://help.github.com/articles/set-up-git
(just follow that first page for now. I will walk you through git in a bit...)

Next, fork a repo:
Go to whichever kernel you like: https://github.com/bedalus/bedalusKERNEL
I'm using mine as an example. Look for the big 'Fork' button.
You've now got your own copy on github, and you can do whatever you like with it, without affecting the original.

However, it's no use if it exists only in the cloud. You need to get a local copy. You'll also want something called a 'remote tracking branch', which will enable you to keep up-to-date with the changes going on in the original repository that you have forked-off from.

Shout 'fork-off!' at the top of your voice.

Uh... okay. Now, to get a local copy, and set up your remote-tracking branches, execute:
Code:
cd /home/<username>/
mkdir mykernel
...you can name your new directory whatever you want. It doesn't have to be 'mykernel', then:
Code:
git clone https://github.com/<your github username>/bedalusKERNEL.git
In the above, put your git username, and substitute bedalusKERNEL.git for whatever your fork is called. You can actually copy and paste the URL from the top of your new github repo's page if you want.

It's going to download about 800MB if I remember correctly. This will take a while, so go have some marmite on toast.

When that's done, you're ready for the remote-tracking branch:
Code:
cd bedalusKERNEL (or whatever your fork is called)
git remote add upstream https://github.com/bedalus/bedalusKERNEL.git
git fetch upstream
The 'git remote add upstream' creates a new branch called upstream, and any changes that the original developer uploads to github can be fetched to your machine with the 'git fetch upstream' command. Notice how this time, the download time is much shorter? That's because of 'delta downloads' which only downloads the differences between what you have, and what they have. (There's some technical detail here.)

Git Tip No. 1: What branches do I have?
You can now enter:
Code:
git branch
...to see all your branches. At this point there should be 'origin' and 'upstream'.

Git Tip No. 2: How do I change branches?
Changing branches (you might as well do this now just to have a little go):
Code:
git checkout upstream
That will move you onto the upstream branch, as long as you haven't made any 'uncommited' changes in origin. (More on that later.) Change back to origin with:
Code:
git checkout origin

Git Tip No. 3: How do I rename a branch?
You might want to rename your branches to help personalise them, just to make remembering which is which a little bit easier. To change origin to 'my_version' do this:
Code:
git branch -m origin my_version
You can change upstream to 'their_version' or something else if you want to. It won't stop anything from working.

More Git Tips later. Let's sort out a build script. If you tinker with any code, you'll inevitably break stuff, and need to fix it, and then need to try building again... So, having a build script is going to save you a lot of time, because there are several steps that can be automated.

Here's how the start of my script looks:
Code:
#!/bin/sh
    cd /home/dave/mykernel
    git branch
    read -p "Correct branch? [Y/N]: " -n 1
    if [[ ! $REPLY =~ ^[Yy]$ ]]
    then
	echo -e "\n"
        exit 1
    fi
This is just a little precaution that I put in to give myself the chance to abort the build before it starts if I'm on the wrong branch. If I don't hit y then the script aborts, and I can checkout the right branch, then restart the script.

Code:
    echo -e "\nSTARTING...\n"
The \n prints a new line, then on that new line the message 'STARTING...' and then begins another new line. If you put \n\n you can print a blank line. The echo command is a good way of putting notices in a script so you know what stage it is at.

Code:
    export PATH=$PATH:/opt/toolchain/bin/
    export ARCH=arm
    export SUBARCH=arm
    export CROSS_COMPILE=arm-none-eabi-
If you put these lines in your script, it sets 'environment variables' that tells the make program where to find the compiler, and what processor it's compiling for (ARM).

If you now save your script in the /mykernel directory you created earlier, git can keep track of it as well as the files integral to the kernel. Save it as whatever you like, e.g. "myscript.sh"
...It's important to have the .sh extension so the system knows it is a script.

To make your script executable, run:
Code:
chmod a+x myscript.sh

Before you execute the script, you need a .config file in the mykernel directory. If you've cloned my repo, you can get a working one by executing:
Code:
cp arch/arm/configs/crespo_release_defconfig ./.config
...this command will only work properly if you are in the mykernel directory when you execute it.

You can mess with this config file if you like! But it's very easy to break the kernel. However, you can always just copy the crespo_release_defconfig again.

Now, to execute the build script run:
Code:
./myscript

If you execute your script, your compiler will now build the kernel. It will take time, but even on my ten-years-old PC it takes less than ten minutes from scratch.

The compiler will spit out a lot of messages. Most of the time it's telling you that it has compiled an object (i.e. a .o file, which will all be linked up later to form the kernel) and sometimes you'll see warnings, which is the compiler telling you it thinks something might be wrong. Don't worry, most of the time the compiler is just being over-cautious.

If the compiler hits a real problem with the code, it will print an error, and tell you what file, and what line, and how far along that line it managed to get to before it didn't know what to do. I'll get back to this later. For now, let's assume everything compiled.

You'll see a message about the zImage being created. That's the kernel. You can't use it as it is, you need to put it into a boot.img so you can flash it.

I find it useful to add this command in my build-script:
Code:
ls -l /home/dave/mykernel/arch/arm/boot/zImage

ls -l means list with long format. It'll print out the entire contents of a directory with size, time, permissions, etc. if you execute it in a directory, or point it to a directory. However, in the command above, I've pointed it specifically at the zImage file, so it only prints out the details for that. This is so I can check the time. If the time is from yesterday, I can see quickly that there has been an error in the build, and the zImage is still the same one I built yesterday, or an hour ago... etc. depending on the time-stamp printed out.

If you get a 'No such file' error, it's because there is no old zImage, because you haven't ever successfully built one yet.

If you sat and watched the entire thing build, then the timestamp should show the current time, minus a few seconds.

How do I make this zImage into a CWM flashable .zip file?

Yay! You've built a kernel. Now you need to make everybody else flash it to their phones too :p

To do this you need to put it into a boot.img, and then into a .zip file.


Download this: http://d-h.st/wVZ (make-boot necessary files)

It's a small download. It's some very simple tools that can split an existing boot image into a ramdisk and zImage, and can also stitch them back up.

Move mkboot.zip into your mykernel folder, right click on it, and select 'Extract Here'. You can now delete mkboot.zip. There is a tool called unbootimg, that can take apart existing boot.img files, I've made things simple by including my own ramdisk, which is compatible with AOSP and CM ROMs. That file is called cyan2disk_new.cpio.gz

We now need to add some new stuff to the script to stitch our zImage and ramdisk together.

If you've not already added the ls -l command I mentioned above, also add this now. Then:
Code:
cp /home/dave/mykernel/arch/arm/boot/zImage /home/dave/mykernel/mkboot/

cd /home/dave/mykernel/mkboot

./mkbootimg --kernel zImage --ramdisk cyan2disk_new.cpio.gz --cmdline 'no_console_suspend=1 console=bull's --base 0x30000000 --pagesize 4096 -o boot.img

Remember, your username is not dave! Unless it is. :p Make the appropriate changes to the path.

How do I make the CWM flashable .zip file?

We're nearly there! This bit is relatively painless. At this point you could save and run the script to check that mkboot is working. If it has worked you can use the same ls -l trick from before, but this time target the boot.img file you just created. If the time-stamp is fresh, it means your boot.img is correct.

TIP: If you haven't switched branches, or run 'make clean', all your .o files are unchanged. The make program keeps track of changes, and only recompiles .o files when the corresponding .c file has been altered. If nothing has changed, your build script will execute very quickly!

To make a flashable .zip file, the easiest thing to do is modify an existing .zip file. You can download my kernel for simplicity, since it already has the necessary script for flashing the entire boot partition. (Most kernels here use koush's any-kernel script, which updates only the zImage and keeps the boot partition's existing ramdisk, so if you try to use another kernel .zip as a template, make sure you correct their updater-script. Using my ramdisk and kernel script will also ensure you keep MTP!)

Once you've downloaded my kernel you should extract it in your home folder, then rename the directory to something like 'myzip'

Now add these lines to your build-script:
Code:
cp /home/dave/mykernel/mkboot/boot.img /home/dave/myzip/boot.img

cp /home/dave/mykernel/drivers/scsi/scsi_wait_scan.ko /home/dave/myzip/system/modules/

"What's that second line? With the .ko file?" I hear you say. Depending on what modules you build, you'll need to copy all of them to the folder specified above. Fortunately, when the kernel finishes building, it tells you what modules have also been built. If you don't want modules in your kernel, you can remove the second line above. However, you must edit your .config file: Open it in gedit, use CTRL+F to open the find dialogue, then type "=m" Now, change every one you find into a "=y" ...so now instead of building modules, the kernel will now incorporate all that code into the zImage instead.

Finally, add this line to your build-script:
Code:
7z a -r -tzip /home/dave/mykernel.zip /home/dave/myzip/*

Run the script again. if everything has gone smoothly, then you now have a flashable .zip in your home directory!

Congratulations! :D

* * * * * * * * *


I've compiled a list of commands you may find handy when getting to know git.

Add a remote branch and track it
git remote add ezekeel git://github.com/Ezekeel/GLaDOS-nexus-s-ics.git
git fetch ezekeel
git checkout --track -b bln ezekeel/bln

Merge in the changes
git merge bln

Resolve conflicts
git mergetool

List local branches
git branch

List remote branches
git branch -r

Switch branch
git checkout branch_name

Rename a branch
git branch -m old_branch_name new_branch_name

View log with short sha1 hash
git log -10 --pretty=format:"%h - %ar: %s"

Restore to a particular point
(IMPORTANT! Don't do this if you've already pushed your commits to github!)
git reset --hard <sha1 hash>

Restore to your last commit
git reset --hard HEAD

Restore to one commit before your last commit:
git reset --hard HEAD^

Restore to two commits before your last commit:
git reset --hard HEAD^^ (etc.)

As long as you haven't pushed to github,
squash all your recent commits into one:
git rebase -i <sha1> ...then change push to squash (or fixup) for all except the first one
git rebase -i --abort (to abort!)

Add .file (i.e. hidden file)
git add .file (simple!)

Add all new and modified files
git add .

Deleting files
(i.e. after doing rm <files>)
git add -u (git will note which files have been deleted)

Bring files from a directory in another branch
git checkout cyanogenmod drivers/cpufreq/

Tells you what changes you've made so far
git status

Commit your changes
git commit (type in your notes about what you did, then CTRL+X then Y to save)

Sync your commits to your github repo
git push <repo_name> <branch_name>

Delete a remote branch
(WARNING: This will delete the entire branch from github
Note: You cannot do this to the default github branch, but you can change the default branch in the admin tab on the website)
git push <repo_name> :<branch to be deleted>

General tips! File management, searching... etc.

Find a file (useful for troubleshooting in some situations)
find /home/dave/ -name 'buildlean.sh'
(searches the home folder and subdirectories for 'buildlean.sh')

Find within any *.c file, the text "s5pv210_driver" (good for finding bits of code)
find ./ -type f -name *.c | xargs grep s5pv210_driver

Find within any file, the text "s5pv210_driver" (good for finding bits of code)
find ./ -type f | xargs grep s5pv210_driver
 
Last edited:
S

stempox

Guest
Thalamus recently changed the way he compiles his kernel. This was his previous stable release, based on Samsung source code.

The cyann.mobi adds bln, touchwake. Features that thalamus has said are unnecessary.

bedalus Hello, I can add this kernel to the list I made on the kernel and rom?
 
B

bedalus

Guest
Yes, but be sure to give credit to the right people.

I've decided to attempt to build my own version of thalamus' kernel with some mods.

If I'm not too retarded, hopefully i can achieve this in the next few days.

As a result of learning to manage git and c, I'll have less time for forum posts.
 

jjhrrsn

Senior Member
Aug 3, 2011
784
210
Portland
Yes, but be sure to give credit to the right people.

I've decided to attempt to build my own version of thalamus' kernel with some mods.

If I'm not too retarded, hopefully i can achieve this in the next few days.

As a result of learning to manage git and c, I'll have less time for forum posts.

Looking forward to this

Sent from my Nexus S 4G using xda premium
 

apatal

Senior Member
Feb 27, 2012
3,576
2,066
Manila
Yes, but be sure to give credit to the right people.

I've decided to attempt to build my own version of thalamus' kernel with some mods.

If I'm not too retarded, hopefully i can achieve this in the next few days.

As a result of learning to manage git and c, I'll have less time for forum posts.
This is good news, Dave. I've been hearing a lot of good things about the new stable release of thalamus in the thread for his kernel that I've been moderating. However, a lot of people including me will be missing BLD and BLN so it's nice to see how it would perform with these mods. With those two plus Voodoo sound that's already cooked in the last release, this may be a kernel to be reckoned with. Cheers! :)

Sent from my Nexus S
 
  • Like
Reactions: wmdunn

apatal

Senior Member
Feb 27, 2012
3,576
2,066
Manila
Off-Topic: I've been discussing with thalamus about the need for a dalvik wipe before flashing a kernel, and he had some pretty convincing arguments against it. You can read his statement here.

Just wanted to get your opinion on this, if you have time. Thanks, Dave.

Sent from my Nexus S
 
  • Like
Reactions: g33kt
B

bedalus

Guest
waiting for bedalus thalamus base plus addons

an interesting benchmark would be bedalus vs thalamus

Thalamus wins,

REMATCH!

Thalamus wins again.


Good news, BLN added. I now know what I'm doing with the code merges, so more features to come soon.

Later on I may start trying to make some original mods, but for now we'll focus on existing ones.

Thanks to thalamus for his help with some extremely noobish questions,


...thalamus' latest but with added BLN and marmite.

To Do
Get organised
Push back to github so changes can be observed
Get some sleep
 
Last edited:

mixtapes08

Senior Member
Sep 23, 2011
3,755
1,743
Quezon City
OnePlus 6
Google Pixel 4 XL
Thalamus wins,

REMATCH!

Thalamus wins again.


Good news, BLN added. I now know what I'm doing with the code merges, so more features to come soon.

Later on I may start trying to make some original mods, but for now we'll focus on existing ones.

Thanks to thalamus for his help with some extremely noobish questions,

Here: http://d-h.st/Df6

...thalamus' latest but with added BLN and marmite.

To Do
Get organised
Push back to github so changes can be observed
Get some sleep

Lol at marmite. :)

Sent from my Nexus S®
 
B

bedalus

Guest
Off-Topic: I've been discussing with thalamus about the need for a dalvik wipe before flashing a kernel, and he had some pretty convincing arguments against it. You can read his statement here.

Just wanted to get your opinion on this, if you have time. Thanks, Dave.

Sent from my Nexus S

Yeah, i agree with thalamus. I only wipe when switching ROMs.

I modified the script so it doesn't bother wiping cache or dalvic-cache

This makes flashing much more painless.

If anyone has trouble, reboot into recovery and wipe cache.

apatal provides some handy scripts for wiping: http://xdaforums.com/showthread.php?p=19746141
 
Last edited:
T

_thalamus

Guest
To be completely honest, I wouldn't have been so helpful had I known you intended to release this, specially without saying anything to me about it.

I fully accept that the GPL doesn't require permission but to ask is both the polite and respectful thing to do.

The majority of others have always when they have wanted to release my work with superficial alterations...all it takes is 'I plan on doing this, what do you think?'

I have never had any objection, but to be asked first is just common courtesy, specially when you are asking me for help! You had plenty of chance to mention it whilst I was assisting you with your queries via email.

But hey...
 

DaXmax

Senior Member
Sep 16, 2008
10,846
9,928
Singapore
To be completely honest, I wouldn't have been so helpful had I known you intended to release this, specially without saying anything to me about it.

I fully accept that the GPL doesn't require permission but to ask is both the polite and respectful thing to do.

The majority of others have always when they have wanted to release my work with superficial alterations...all it takes is 'I plan on doing this, what do you think?'

I have never had any objection, but to be asked first is just common courtesy, specially when you are asking me for help! You had plenty of chance to mention it whilst I was assisting you with your queries via email.

But hey...

From what i see here... Give him the big daddy credits as you used his sources... ;)
 
B

bedalus

Guest
To be completely honest, I wouldn't have been so helpful had I known you intended to release this, specially without saying anything to me about it.

I fully accept that the GPL doesn't require permission but to ask is both the polite and respectful thing to do.

The majority of others have always when they have wanted to release my work with superficial alterations...all it takes is 'I plan on doing this, what do you think?'

I have never had any objection, but to be asked first is just common courtesy, specially when you are asking me for help! You had plenty of chance to mention it whilst I was assisting you with your queries via email.

But hey...

Sorry, links pulled.
 
B

bedalus

Guest
I feel quite bad now. I don't know what possessed me to release without getting the okay first. Eager to show off i think. :eek:

I'll get this thread locked as a lesson to myself!
 
Last edited:
B

bedalus

Guest
Actually thalamus is fine for me to release this! Yay. Thanks thalamus.

Links will reappear when the OP is properly organised and credited.
 

Top Liked Posts

  • There are no posts matching your filters.
  • 53
    Hi Erythnul, thank you for your info. Like many others here, I'm very interested in prolonging my Nexus S batt life. I'm on Marmite 4.83 now and running BetterBatteryStats on latest MIUI US JB rom. I couldn't find the advanced root functions you're referring to. Is this in the BetterBatteryStats app?

    If you don't mind, maybe write a short tutorial on how to use the BetterBatteryStats tool to troubleshoot our battery woes. That'll help us out a lot. Thanks kindly. ;)
    Sorry it took me a while to respond, we were having festivities as my sister gave birth almost 2 weeks early. A new nephew! :D

    Bedalus, if you feel this post should be in its own thread instead of in here, let me know and I'll move it asap.

    Anyway, I wrote up a tutorial with pictures for everyone on BetterBatteryStats and analysing battery drain. And also just a little bit to show off my battery life after what I feel is a day's normal use. It's a full cycle, usually I'd charge the battery somewhere in the middle of this, to keep it from degrading sooner than it should. The tutorial will basically be a description of how I'd go about analysing any problems I'd have with battery life, from basic to advanced.

    Before I begin, a quick disclaimer: I'm running ParanoidAndroid 2.13 on Marmite 4.5, I haven't had time to update either lately, and it's not the most battery-friendly combination I've ever used. I'm still getting great battery life, but it could probably be a little bit better. Won't matter that much though. Also, your mileage may vary depending on many factors, mostly your usage pattern, but also screen type. I have an i9023 Nexus S. It's an LCD screen, not super AMOLED, so I don't know how much/little battery they drain compared to the LCD. Using a black or mostly dark background will help for those screens. On LCD screens, this doesn't matter, only brightness level matters.
    I will be keeping it simple, as I am not a programmer and started out knowing as much as anyone else about all this. All this information I slowly gathered from these forums, personal experience and some Google searches. I may be wrong on some things (though I got most of it right) and take no responsibility for any problems, though none should occur.

    So, you're having battery trouble?

    First off, lets get the basics out of the way. My setup at the moment is this:
    As mentioned, PA 2.13 and Marmite 4.5 on an i9023. I never charge my battery above 90% (using BLX). I run no battery saving apps such as Juice Defender or similar things. Never overclock, never undervolt. BLD at 1.5 seconds. I keep my brightness at the lowest unless I don't have any other choice, wifi and data always on (disregarding exceptions). GPS and location services are on, but location reporting (Latitude inside Google Maps) and Google Now are usually on, but for the purposes of this tutorial, they were off (Battery drain impact: ~30-45 minutes of awake time spread over 24 hours.). Turning GPS and Location Services off will save you some more battery and awake time, for this cycle I forgot to turn them off.

    High drain problems.

    I feel that any Nexus S user should be able to get at least 3 hours of screen on time and still have battery left to sleep for ~17 hours, on a full cycle. This means 20 hours of effective use, or 4-4.5 hours of constant use off the charger. If a phone is idling well, it should use barely any battery at all, and only wake up when absolutely necessary. For me, the best way to analyse what processes are keeping my phone awake has been BetterBatteryStats. I will be assuming that it's installed and set up. Easy enough to get, it's on the Play Store (support the dev! :)) or free here on XDA, just a search away.

    To start analysing, first install and set up BBS (if you haven't done so already). BBS is not a very intuitive app, as it assumes that you know more than most people do about the internal processes and workings of the phone. Setting it up is easy enough though, and I won't be going into the details too much. Some of it I know, some of it I'm not too familiar with and I prefer to keep this outside of the realm of speculation. After installing BBS, start it up and hit the menu button to get to the Settings. Scroll down and tap on Advanced, then turn on the Root Features. This will allow BBS to read network usage from apps (not very critical, but nifty) and dump the Alarms sent by the system and apps (useful, but complex). After this, you'll be prompted by SuperUser or SuperSU to grant it access, and you're good to go. Fully charge your phone and start a new cycle. Use your phone as little as possible and do not reboot it or charge it in between. When the battery gets to ~50%, you'll be (more than) ready to find out where the problem is. You can also use your phone as usual, but this will cause the stats to be less easily interpreted, as your usage will also keep the device awake.

    Why shouldn't I reboot or charge?

    BBS will automatically create a reference point when your phone is unplugged from the charger, and will be ready to read the records on a moments notice. This valuable information is lost when the phone is rebooted, and recharging will reset the reference point. For an accurate analysis, please try to avoid this :)

    On to business.

    Now, the real task is going to begin, analysing the stats. Here's a link to an imgur album, with screenshots of my stats and battery life. I'm trying to use all of the pictures and make this tutorial look nice, but this is one of the longest posts I've ever written here, so for reference, this is all of them.

    First off, check your normal battery stats screen, and the deeper stats (tap the graph).

    WIpGm.png
    ObM2X.png

    gH55i.png
    SGplM.png


    These are my stats. Almost 20 hours on the clock, 14% remaining. ~3,5 hours screen on time and ~40 minutes of music. Not too bad (especially considering I started on 90% :)). You can see there's some awake time. Part of that is music, part of it is Google Services (Location Services, Syncing) being annoying. The drain from Services is pretty minimal though, as you can see from the graph. The straight parts would probably have been somewhat straighter if it hadn't been syncing.

    If your Nexus doesn't get these kind of times, something may be wrong. If it's a hardware problem, unfortunately I can't help you, but if it's software related (faulty kernel, troublesome app, buggy ROM), it's easy to track and fix. Let's fire up BBS.

    5rSzh.png


    You'll be greeted by this screen. Compare Deep Sleep times and Awake times to your screen on time from the previous pictures. (My total awake time was ~4.5 hours, 3.5 hours screen on time, ~30-35 mins music while screen was off, ~20-30 mins Google services.) If your device isn't sleeping properly, your Awake time should be significantly higher than your Screen On Time+Time media played (or +whatever other things you consciously keep the device awake for). Deep Sleep will be significantly lower, if present at all.

    Switch to kernel wakelocks.
    If something is seriously messing up, this is where you'll see it first:

    EEHTR.png


    In my picture, all is well with the world. No unseemly wakelocks here. PowerManagerService is basically a name for all the userspace processes keeping a Wakelock, these are shown in the next part of BBS, Partial wakelocks.
    If you see any large wakelock spikes in Kernel Wakelocks, either tap the (?) next to it (if it's there, not all problems have been indexed by the dev of BBS) or Google it. Or ask me, and I'll either know or Google it and speculate for you ;)

    Reading these stats may seem complicated, but it's not all that hard. Most important are the total time and the count (cnt). This shows how many times the device is awakened by the specified service and how long it's kept the device awake.

    Some of the problems that occur here are truly complex, and may be caused by too many things to go into here. Two quick examples from personal experience:
    • My internal SD had a corrupted block, Android kept trying to read it (I didn't know this, but noticed high drain). mmc_detect1 wakelock kept showing up. I didn't know what to do with it, Googled around, found it had to do with mounting, had Windows check the filesystem (and repair it) and remounted the SD. Problem solved, no more wakelocks next cycle.
    • After upgrading to JellyBean, one of my usual apps was causing a buffer overflow in the audio interface whenever it tried to gather environmental noise from the microphone. High drain occurred with no identifiable source, the app didn't show the drain because the overflow happened inside the kernel. I can't remember the name of the wakelock, and I had to do to some deeper digging to get to the root of it, but it was here and if I'd Googled sooner I would've known without resorting to more drastic measures to test my device's idling (Using DDMS from the SDK, a tutorial for some other time, if this doesn't help).

    On to Partial Wakelocks:

    oUViY.png


    These are all the user processes asking for time. In my case, obviously, music is the lead contender here.
    Again, Google Services kept it awake quite some time, but spread very thinly. 1160 wakeups spread over 19 mins and 1550 wakeups spread over 9 mins. All of this amounts to negligible amounts of constant awake time, and can usually be disregarded.
    Once again, if there are any unusual spikes, investigate further.

    I seem to have forgotten to take pictures of the other screens of BBS, but these 3 are the most important anyway.
    Alarms can tell you which app is sending most of the wakeup messages, which is really useful and I wish I had that screenshot, but I don't. :/
    Network Stats is kind of self-explanatory, as is CPU states.
    Process is a screen I know practically nothing about, but if I remember correctly it shows how much CPU time some processes requested. I recently charged so my stats are kind of empty now, so I can't check :/

    Concluding

    Okay, so this tutorial wasn't as good as I wanted it to be because I have no battery problems at the moment. I will be happy to interpret anyone's battery graphs/BBS stats, however, so hopefully that makes up for it a bit.
    Also, hopefully I've at least shown how to work BBS and interpret the basics. Any questions/screenshots can be sent to me by PM. (Or if you reply, please don't quote this entire post :p)

    Thanks to Articudos, here is a link to the thread where I learned a lot of what I know about wakelocks back when it was first posted, this knowledge is invaluable if you really want to delve deeply into the system. It's much more detailed and accurate than my attempt at a tutorial here, so I fully recommend reading it, it's practically guaranteed to solve your wakelock problems.

    [GUIDE] The Total Newb's Guide to Wakelocks

    Also, please let me know what you think about the tutorial and if I can improve it somehow, it probably needs work. Thanks for reading and good luck!
    17
    I know I said I was taking a break from building, but...

    v6.6 is here: http://goo.gl/HvUrp

    -Merged to Linux mainline v3.0.50
    -Fixed the GPU code.

    In the PLL check that I created for v6.5 I somehow accidentally changed a different check. Sorting out this GPU OC at 1.1GHz has been a real chore, so again, I'm taking some time off building, but I couldn't leave the version matrix with an error dangling at the top. Enjoy! :D

    So now I think the time has come to thank you bedalus:

    For your energy you always take in this development.
    For your unbelievable patience.
    For your sleepless nights that you spend with and for us.
    For your will to give your best... and correct any little mistake soon as possible.
    For your friendly answering of stupid questions.
    This is what make our community make what it is.
    Maybe it sounds gay but its the truth.
    And I hope the most agree with me...
    Thanks a lot man.
    S.R.
    15
    Overclock! Undervolt! OC UV OC UV...

    Shut up!!

    Hello ex-colleagues, please have a good read here. I quote this from DorimanX from SGSII Kernel Dev. (Yes for those who know, I was a Nexus S user) Basically he had a talk with a chip developer whom has watched his thread and decided to say something that, most if not all of us, are confused and very deficient in knowledge - OverClocking/Undervolting. Visit his post here and please thank him for sharing.

    I bring here of what you can expect. Dear Bedalus, you might want to add this to OP for educating adamant humans on OC, UV...
    Gist of it? What may be true for one may not be true for all!


    Quoted from DorimanX

    This is long INFO post from real chip designer that help to create CPU/GPU and other chips for the living for 14 years now, so respect

    He sent me PM, for now he cant post that by him self.

    Vikas is monitoring our thread and want to say his professional stand about UV/OV and why it's works for some and why not for others.

    ==================
    I am calling Vikas(vikas.mishra) to the speech stand


    Hello people.

    Let me introduce myself - my name is Vikas Mishra and I am a chip designer by profession. .
    I have worked on critical parts of design of TI OMAP4, OMAP5, Nvidia Tegra 3 etc and have been doing this for the last 14 years.
    Of late - I have seen a lot of folks posting BUGS about undervolting of the GPU/CPU.
    I think I can explain what are the possible issues with undervolting/overclocking in a laymans language.

    It is a little long winded but I think the length is needed for providing the appropriate context.

    * What is inside your Cellphone

    Your cellphone is an amazing device. It is a full fledged computer
    that fits into your pocket. They have all the standard components
    that a computer has - except that they are all usually soldered on
    the motherboard directly and are not meant to be user-servicable.

    The chief components inside your cellphone are
    1. Application Processor (AP)- this is the heart of a modern
    cellphone. These are manufactured by many companies - the main
    ones are Qualcomm, Nvidia, Samsung and Apple. The other not so
    well known ones are made by Texas Instruments, ST Ericsson,
    Marvell and Broadcom.

    A modern AP has logic to control the camera and process the image
    that it generates, to do video encoding (video recording) and
    video decoding (movie watching), Audio processor etc. in addition
    to the well known CPU and GPU.

    2. Power Management Controller - This is the chip that is
    responsible for generating and regulating the voltages that are
    used by all the components on the board.

    3. DRAM - not very different from the DRAM found on a PC (except
    that it is lower voltage)

    4. Flash - for storage

    5. Touchscreen controller

    6. Logic for microphone, speaker

    7. Battery

    One of the most complex piece of circuitry on the phone is the AP
    and the power management controller.


    * Circuit Basics

    A modern AP has millions of circuit units called (Flip
    Flops). These flip flops have two parameters associated with them
    called Setup time and Hold time. More details on what a flip flop
    can be found on the wikipedia at
    http://en.wikipedia.org/wiki/Flip-flop_(electronics) . This is a
    nice bit of bedside reading if you are interested.

    A setup time roughly indicates what frequency you can run a design
    or an AP at before it becomes unstable.

    A hold time roughly indicates the maximum voltage till which a
    design is stable.

    A fully technical analysis of what is involved in these timing
    parameters requires a degree in electrical engineering but in broad
    terms the problem is described below.

    Chip designers diligently ensure that all of the millions of the
    flip flops in a chip meet the setup and hold time across a broad
    range of voltages and silicon parameters. They do a pessimistic
    analysis to ensure that a chip will run reliably across a wide
    range of voltage/frequency combinations.

    However, contrary to the popular belief, chips vary widely in their
    silicon parameters. Even chips on a the same wafer and different
    flip-flops within the same chip can have widely different silicon
    parameters. This is why what works on one particular chip will not
    work on the other chip.

    Your silicon manufacturer provides a range of voltages and
    frequencies across which the device can work reliably. The phone
    manufacturer will further narrow down the range depending on the
    other components they choose within the phone board.

    * How does voltage affect the design

    Reducing voltage makes the design slower and increasing voltage
    makes the design faster.

    So can I keep on increasing the voltage for ever and make the
    circuit faster and faster. The answer is no - a point will come when
    the circuit will become unreliable. This becomes unreliable because
    the "hold time" of one or more of the flops will start
    violating.

    As you reduce the voltage of the design, the circuit will start
    becoming slower. However typically it will continue to work till at
    apoint it starts failing - this failure occurs due to violation of
    "setup time" of one or more flops in the design.

    So what happens when the setup time or the hold time of a design
    fails - the answer is that it is unpredictable. Meaning suddenly if
    you ask the processor what is the value of 2+2, the answer it will
    provide could be unreliable - in some cases it could be 3, in some
    cases it could be 4 in some cases it could be -2349783297 (a random number).

    I am of course oversimplifying but I hope you get the picture.

    * How does undervolting affect your phone processor

    The reason undervolting is so appealing to people because they
    thing that undervolting will save power and improve battery
    life. While this is true in theory, in practice there is a caveat.

    It will reduce the power of the chip, but the power consumed by the
    phone as a whole will not improve. In some cases in fact it can
    deteriorate. Let me explain.

    The most power hungry part in the phone is not the AP - it is the
    LCD screen. All of these screens consume a ton of power. So even
    though your AP is now consuming lesser power, the overall impact to
    the phone as a whole is not that much.

    If you accompany undervolting with a frequency reduction (which you
    should), the total time taken for doing a web page rendering (for
    example) would increase. During this time the screen is on and it
    has more than compensated for the power that you saved in the
    AP.

    You could of course come up with examples where this wouldn't
    happen - but on a whole, IMHO, you should leave the voltage of the
    AP/GPU/CPU to the guys who know the system best - the guys who
    designed the chip and people who manufactured it.

    * How does overvolting/overclocking affect your phone processor

    If you want that last drop of performance from your phone and you
    over clock it, at a point some of the design flops will start
    violating the hold time and the design will stop working reliably.

    Again, in some anecdotal cases this would work - but this is not a
    reliable means/mode of working. Just because your friend's or your
    first cousin's girlfriend's phone works - doesn't mean yours will
    work as well.

    * What are the user observable impacts of undervolting/overclocking?

    It is hard to say - simply because there are so many of flops in
    the design.

    In some cases - you wouldn't see anything wrong with the phone
    until one day you do. In some cases it will result in a SOD
    immediately. In some cases it will result in your phone not waking
    up reliably.

    IMHO the risks of issues with undervolting/overclocking far
    outweighthe potential gains you may get out of it. Usually there
    is no lasting damage to the phone/AP if you overlock/undervolt but
    it is possible to do it. For example, You run the phone at such a
    high frequency that the chip temperature becomes more than what it
    was designed for and the Silicon just fails.

    So "Just say No" . Don't overclock or undervolt your phone -
    leave it to the guys who really understand what they are doing.

    Thanks,
    Vikas
    13
    Merry Christmas to Bedalus, guys and girls on this thread, and whole xda community. Enjoy with familly and in gifts. ;) :beer:

    Sent from SpeedMachine i9100
    13
    MTP also work with MIUI

    bedalus, the great
    I have tried you V1 kernel on MIUIandroid ver 2.7.13 and gladly report that MTP work on Windows XP!!!

    As MIUI don't have option in Setting>Storage>xxxxx ; here's my trial:

    1.from Play store search and download "USB mode switch for SGS1 on CM" (need root)
    2.Open and select "change to MTP" pop up will ask for reboot then reboot
    3.after reboot plugin USB cable and MTP would be found but driver won't install
    4.Disable "USB debugging" then MTP driver automaticly installed