Root [KERNEL] TheOC v1.7.20 kernel for MT Isaac & TG based CM7

[TheBritton]

..... anxiously awaiting the update to TheOC v1.6

 

[Whyzor]

I just tried to build theOC kernel from source with lowered regulator & UV limits, and the new updates to interactive governor. I couldn't get the cpufreq_interactive.c to compile, it's got some new dependencies. Also Koush's anykernel installer apparently doesn't work. Do I have to unpack & repack the boot.img as a whole? What's the simplest way to do this?

 

[mantera]

I just tried to build theOC kernel from source with lowered regulator & UV limits, and the new updates to interactive governor. I couldn't get the cpufreq_interactive.c to compile, it's got some new dependencies. Also Koush's anykernel installer apparently doesn't work. Do I have to unpack & repack the boot.img as a whole? What's the simplest way to do this?

I'm not sure what you mean by "unpack and repack the boot.img as a whole".

You should unpack the ramdisk from theOC and use that when you rebuild the new boot.img using the new zimage file that you compiled.

I just leave the ramdisk unpacked in my build folder (since it doesn't change much between different kernel builds) and then in my script, I copy over the newly built zimage into there and package it up into a boot.img file.

 

[mantera]

..... anxiously awaiting the update to TheOC v1.6

Unfortunately, the HAVS stuff has run into a snag. Everything was working except for 1 major bug that I haven't found a fix yet... everytime the phone tries to ramp down into deep sleep, the phone reboots. And unfortunately, it's hard to track down because if I have any debugging turned on or plugged into the computer for a logcat or doing anything, the bug doesn't occur. GRRR!! It's really annoying.

However, I figure for an interim release, I was going to start looking into lowering the voltage table like Whyzor was looking into to see if it made any different along with possibly one more thing.

 

[Whyzor]

I'm not sure what you mean by "unpack and repack the boot.img as a whole".

You should unpack the ramdisk from theOC and use that when you rebuild the new boot.img using the new zimage file that you compiled.

I just leave the ramdisk unpacked in my build folder (since it doesn't change much between different kernel builds) and then in my script, I copy over the newly built zimage into there and package it up into a boot.img file.

I thought I could take Koush's AnyKernel flasher .zip file, just place my zImage in there and then it would flash, but apparently the script in there doesn't work on the MT. On the OV I've also replaced kernels that way.

So on the MT, I was googling for ways to split up the boot.img into kernel & ramdisk part. But it sounds like I could just do it from my source path. What exact commands are you using and from what paths? (that'll help me figure it out).

 

[mantera]

I thought I could take Koush's AnyKernel flasher .zip file, just place my zImage in there and then it would flash, but apparently the script in there doesn't work on the MT. On the OV I've also replaced kernels that way.

So on the MT, I was googling for ways to split up the boot.img into kernel & ramdisk part. But it sounds like I could just do it from my source path. What exact commands are you using and from what paths? (that'll help me figure it out).

Here's a guide that will help. Obviously, you'll need to update for the MT but I'm sure you can figure that part out.

[HOW-TO] Build your own kernel package from source - Android Forums at AndroidCentral.com

The only difference is that the final command to make the boot.img with the correct parameters and base memory is

mkbootimg --kernel zImage --ramdisk ramdisk-boot --cmdline "console=ttyMSM1 androidboot.hardware=qcom" -o boot.img --base 0x00200000

 

[Whyzor]

Here's a guide that will help. Obviously, you'll need to update for the MT but I'm sure you can figure that part out.

[HOW-TO] Build your own kernel package from source - Android Forums at AndroidCentral.com

The only difference is that the final command to make the boot.img with the correct parameters and base memory is

mkbootimg --kernel zImage --ramdisk ramdisk-boot --cmdline "console=ttyMSM1 androidboot.hardware=qcom" -o boot.img --base 0x00200000

Ah, thanks, I was so close last night, just missed the last part with the --base 0x00200000 (the guide I was following said it was needed for Nexus S, so I left it out), flashed & booted, went straight into download mode (panicked for a second), then just pulled battery & booted into recovery & nandroid restored. Will try this again when I when I get some time to play with things.

The other thing I was trying to figure out was compiling the new cpufreq_interactive.c (my favorite governor) from the CM kernel tree. I added the extra headers in linux/include/cpu.h,

#define IDLE_START 1
#define IDLE_END 2


void idle_notifier_register(struct notifier_block *n);
void idle_notifier_unregister(struct notifier_block *n);
void idle_notifier_call_chain(unsigned long val);

which supposedly defines the needed functions, but it still complains on this line in the .c file:

idle_notifier_register(&cpufreq_interactive_idle_nb);

 

[TheBritton]

Unfortunately, the HAVS stuff has run into a snag. Everything was working except for 1 major bug that I haven't found a fix yet... everytime the phone tries to ramp down into deep sleep, the phone reboots. And unfortunately, it's hard to track down because if I have any debugging turned on or plugged into the computer for a logcat or doing anything, the bug doesn't occur. GRRR!! It's really annoying.

However, I figure for an interim release, I was going to start looking into lowering the voltage table like Whyzor was looking into to see if it made any different along with possibly one more thing.

Awesome! The current version of this kernel is working excellent for my device. Current idle time battery usage is 3% per hour.
I don't have the lower frequency voltages set under 800 yet, so I'm curious to see what 650 would do.. if the phone could be stable that is.

But.. it's kinda hard for something that works so good to get any better. I just am addicted to customizations and hacks and am always eager for the next "best" thing

Thanks again!!

 

[RainGater]

Is there a way to set haptic feedback when I click on any of the apps? Right now, I can only select haptic feedback on keypress for softkeys and certain UI interactions under CM settings. For instance, if I click on one of the icons on the dock bar or going thru various actions on the Settings, I want to set the haptic feedback. Is it even possible? Thanks in advance.

 

[mantera]

Is there a way to set haptic feedback when I click on any of the apps? Right now, I can only select haptic feedback on keypress for softkeys and certain UI interactions under CM settings. For instance, if I click on one of the icons on the dock bar or going thru various actions on the Settings, I want to set the haptic feedback. Is it even possible? Thanks in advance.

That I don't know. However, I don't think it would be a kernel setting. If you could do it, it would be a rom setting or an app. You might get a better response if you ask in the cm7 thread.

 

[RainGater]

That I don't know. However, I don't think it would be a kernel setting. If you could do it, it would be a rom setting or an app. You might get a better response if you ask in the cm7 thread.

Thank you. For the Governor, I set it to InteractiveX in CM Settings.

What is the default I/O Scheduler in TheOC v1.5 kernel?

For I/O Scheduler, I couldn't find it in CM Settings. Does the Governor control the I/O settings too or do I have to use "No Frills CPU Control" or some other app?

Thanks again.

 

[mantera]

Thank you. For the Governor, I set it to InteractiveX in CM Settings.

What is the default I/O Scheduler in TheOC v1.5 kernel?

For I/O Scheduler, I couldn't find it in CM Settings. Does the Governor control the I/O settings too or do I have to use "No Frills CPU Control" or some other app?

Thanks again.

The default scheduler currently is deadline. And yes, you'll need to use No Frills CPU Control to change it.

 

[Whyzor]

I don't think the github cloned kernel works properly (it compiles though). I basically wiped my previous dir, did a fresh:

cd ~/android/kernel
git clone git://github.com/mantera/triumph-kernel-msm7x30.git
cd triumph-kernel-msm7x30/
cp config .config
KERNEL_DIR=~/android/kernel/triumph-kernel-msm7x30/ CROSS_COMPILE=$CCOMPILER ARCH=arm make -j2

I'm using the the prebuilt eabi-4.4.3 toolchain, after compile is done, copied zImage to: ~/android/system/out/target/product/triumph/kernel, then did a recompile of CM7 (which works with default kernel from Isaac BTW). Flashed it, and it hangs at the motorola boot logo. I avoided the whole packaging boot.img step since I wasn't sure if that was working for me yet. BTW, if I pack boot.img & flash just that, during the motorola boot logo, it's superimposed by a half-full battery icon, and hangs the same way.

 

[mantera]

I don't think the github cloned kernel works properly (it compiles though). I basically wiped my previous dir, did a fresh:

cd ~/android/kernel
git clone git://github.com/mantera/triumph-kernel-msm7x30.git
cd triumph-kernel-msm7x30/
cp config .config
KERNEL_DIR=~/android/kernel/triumph-kernel-msm7x30/ CROSS_COMPILE=$CCOMPILER ARCH=arm make -j2

I'm using the the prebuilt eabi-4.4.3 toolchain, after compile is done, copied zImage to: ~/android/system/out/target/product/triumph/kernel, then did a recompile of CM7 (which works with default kernel from Isaac BTW). Flashed it, and it hangs at the motorola boot logo. I avoided the whole packaging boot.img step since I wasn't sure if that was working for me yet.

That's not the repo you want to clone for the cm7 kernel (at least for theOC anyways). do this one:

https://github.com/mantera/WX_435_Kernel-CM7

 

[mantera]

Updated to v1.6.11. Just a very minor release.

Changelog:

TheOCv1.6.11.zip
- added 2way calling patch. Thanks to avs333 for the patch and DoomLord for the port of the patch.

Need to use CallRecorder app from skvalex or rVoix.apk from avs333. More info can be found on this thread on xda:
[DEV] Two-way call recording on Desire [ALMOST SOLVED][Sept. 7 update] - xda-developers

Here's the post by skvalex listing his latest trial version of CallRecorder:
xda-developers - View Single Post - [DEV] Two-way call recording on Desire [ALMOST SOLVED][Sept. 7 update]

Here's the market link for CallRecorder:
https://market.android.com/details?id=com.skvalex.callrecorder

I tested the CallRecorder app and the sound quality was excellent for a recording--if you're into that sort of thing. I did not test the rVoix.apk yet at this time.

- enabled 61 MHz and 184 MHz clock frequencies.
- updated Interactive governor with all of the latest updates from CM.
- Added lower voltage regulator settings down to 600. It looks like 600 is the min that our boards can go from what the specs look like.
- changed default IO scheduler to NOOP.
- reverted memcopy update.

 

[TheBritton]

Mantera, do you believe this is okay to flash over Whyzor's "CM7 TG Reloaded" ROM?

I LOVE the changes you have incorporated in this. Especially noop as the default scheduler.

 

[mantera]

Mantera, do you believe this is okay to flash over Whyzor's "CM7 TG Reloaded" ROM?

I LOVE the changes you have incorporated in this. Especially noop as the default scheduler.

Yes, it should be. He was using my v1.5 so this is just upgraded from that. That's why I changed the title of this post to "...for MT Isaac & TG based CM7". In fact, I actually test this on my own phone running my own build of cm7 from the same repo.

 

[TheBritton]

Yes, it should be. He was using my v1.5 so this is just upgraded from that. That's why I changed the title of this post to "...for MT Isaac & TG based CM7". In fact, I actually test this on my own phone running my own build of cm7 from the same repo.

Okay, thanks!

 

[Prey521]

I'm running VR as my current scheduler. Is noop better?

 

[mantera]

I'm running VR as my current scheduler. Is noop better?

Well, according to the descriptions by knzo for VR:

"It's probably the one who can score the most in benchmarks but it's also one of the most... unstable. Its performance fluctuates, it can peak above average or it can go below it. But when it peaks... it's the best."

I like using noop because of the stability. I tried simple io (sio) but it gave me a lot more inaccurate results in linpack and sometimes caused reboots in linpack --although I think it's probably a linpack issue since I have no other issues in any other program. But that's why I stuck with noop.

 

[Chairshot215]

Really itching on trying the 61mhz frequency as my new min, has anyone had any issues going this low? Remember reports that some phones had issues at 122mhz in that they would not wake. Never had any issues with my phone at this frequency though.

 

[Whyzor]

Ah, I see how you got cpufreq_interactive.c compiled, thanks I'm going to include this with my next ROM build, along w/ my experimental fix for the "occasional can't go into deep sleep" bug, basically moving line 2490 in /drivers/mmc/host/msm_sdcc.c to outside of the if(mmc) check. It looks like the whole subroutine doesn't do anything otherwise. I haven't seen the bug in about 2 days so far.

[/FONT]
}
wake_unlock(&host->sdio_suspend_wlock);

Also as an update, I had to use the line:

mkbootimg --kernel zImage --ramdisk ~/android/system/out/target/product/triumph/ramdisk.img --cmdline "console=ttyMSM1 androidboot.hardware=triumph" -o boot.img --base 0x00200000 --pagesize 4096

To get the flashable zip working. I noticed the --pagesize 4096 and hardware=triumph part from the ROM building msgs is specific to the MT.

 

[mantera]

Really itching on trying the 61mhz frequency as my new min, has anyone had any issues going this low? Remember reports that some phones had issues at 122mhz in that they would not wake. Never had any issues with my phone at this frequency though.

I didn't have any problems with the 61 MHz while I was testing. But it was for only the 1 or 2 days. However, I don't normally play music or have my phone doing stuff while the screen is off so I'm sure if you do that, then your performance will probably suffer. But you'll need to check it out to see how it behaves on your particular phone. Some phones are picky.

Edit: I did run Stability Test for many hours while testing the undervolting and lower frequencies so it all seems to run stably--just really slowly at the 61 MHz.

 

[mantera]

Ah, I see how you got cpufreq_interactive.c compiled, thanks I'm going to include this with my next ROM build, along w/ my experimental fix for the "occasional can't go into deep sleep" bug, basically moving line 2490 in /drivers/mmc/host/msm_sdcc.c to outside of the if(mmc) check. It looks like the whole subroutine doesn't do anything otherwise. I haven't seen the bug in about 2 days so far.

}
wake_unlock(&host->sdio_suspend_wlock);

Also as an update, I had to use the line:

mkbootimg --kernel zImage --ramdisk ~/android/system/out/target/product/triumph/ramdisk.img --cmdline "console=ttyMSM1 androidboot.hardware=triumph" -o boot.img --base 0x00200000 --pagesize 4096

To get the flashable zip working. I noticed the --pagesize 4096 and hardware=triumph part from the ROM building msgs is specific to the MT.

I'll take a look at that experimental fix. What drew you to that part of the code?

As for the mkbootimg line, I've never used that pagesize option in any of the flashable zips that I've posted and it seems to be working fine. It's weird that you would need it. It's probably your system that you're using to build it needs it.

 

[Prey521]

Really itching on trying the 61mhz frequency as my new min, has anyone had any issues going this low? Remember reports that some phones had issues at 122mhz in that they would not wake. Never had any issues with my phone at this frequency though.

No problems running at 61Mhz either myself.