• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

Root [DEV] Kernel 3.4.0 pathfinding

Now that I'm compiling from git, WiFi will be broken due to version numbering until I integrate the WiFi driver.
 
Are you using cyanogenmod sources? Why not just use the ZTE sources to produce the OC kernel?

When jimsmith80 made his OC ICS kernel, it was also limited to 1.6 something. Someone else posted a code change that allowed 1.8Ghz, but it was a higher voltage. It never got integrated into his kernel though.

Have you tried downloading the drivers from the zte site and forcing them in the device manager in Windows through update drivers and then manually selecting the drivers to get fastboot working with the JB ROM?

There is precedent for it on this and other ZTE devices. I put some links about it in my thread, but I really haven't tried it out.

I don't remember having any problem using it to downgrade to ICS, but I haven't done that since December and have a terrible memory.

Is anything else overclocked in your kernel? I was planning to do this as well, but with L2 overclock and also RAM and GPU (remove lock on adreno @ 300Mhz and allow 400Mhz). Haven't had time to mess with it.

The JB ROM already dramatically boosted speed in antutu, I think it could sky rocket with new kernels, especially when you compare it to ICS.

I'm gonna check out that thread about API updates now.

Thanks!
-SB
 
Yes, I am working from the zte source. You can see my changes in the git I linked to earlier. The cyanogen source I was talking about is only where I got some of the information to make changes.

If you look at the vital forum you'll see they have the same boot loader issue. Zte disabled the fastboot app in the latest bootloader. Will either have to reassemble it somehow or compile a new one to get fastboot, neither of which I'm comfortable with yet.
 
spock1104 said:
Yes, I am working from the zte source. You can see my changes in the git I linked to earlier. The cyanogen source I was talking about is only where I got some of the information to make changes.

If you look at the vital forum you'll see they have the same boot loader issue. Zte disabled the fastboot app in the latest bootloader. Will either have to reassemble it somehow or compile a new one to get fastboot, neither of which I'm comfortable with yet.
Click to expand...

That sucks about the bootloader. I wonder if any similar ZTE phones with JB have fastboot working.

I noticed that the Avid (n9120, source of jimsmith80's original overclock kernel for the force) has a 4.1.2 and a 4.2.2 now. I wonder if the loader has fastboot removed, and how different it is from the n9100.

Do we have the loader source in your hub? I've never worked with the bootloader code before so I'm not sure where to look.

Is this an example https://github.com/spock1104/androi...arm/mach-msm/include/mach/peripheral-loader.h

Of the include?

It looks correct. There are arguments to shutdown, boot, and put, which could be write an image..I'm just guessing.

If we have the code maybe we can fix it by flipping a debug switch somewhere, or uncommenting some code?

Cheers,
-SB
 
The bootloader source isn't generally given out by manufacturers. It's based on qualcomm's LK bootloader and that's available on codeaurora (it's a general version, doesn't have the phone specifics), so some enterprising soul *could* create a new bootloader if they so dared. Unfortunately if you screw up the bootloader you risk a hard brick that will require a serial cable to recover from.
 
I got wifi to build, but ran into another voltage issue...

edit: apparent bug in the overclock code. disabled OC and I can boot with the new wifi module. At least it's progress...
 
Last edited:
I might be willing to test, but I have only had my phone for a day so I wouldn't be the best to determine how this affects the normal phone behavior.
 
I'm willing to test this. I've never installed kernel before so I have a few noobish questions.
1. Is it the same process as flashing a ROM?
2. Is it possible to revert back to stock?
3. Can I choose the Clock Speed? (to avoid over heating)
4. Is it flashable on JB? (thanks sawbones)
 
Those are exactly the questions you should be asking, and shame on me for not saying anything sooner.
  1. Not exactly. You don't have to do any wiping, just flash the zip and reboot.
  2. I recommend backing up boot and system. A restore of these will undo my changes. That being said, here's a handy zip for the sawbones users to undo my changes.
  3. That and more! I've since added cpu governors, i/o schedulers, and kernel mpdecision. I recommend using Kernel Tuner 2014 for learning purposes, and 3C Toolbox for the power users. Trickster Mod will also work, but I'm not a fan.
  4. In fact I've only tested this out on JB so far. I'd love to get an ICS user to let me know what this does.
At this point the phone should be a bit faster and still save you battery if you're not overclocking. Here's the latest version: http://www.mediafire.com/download/y7mek9ljuirl9h2/force_govs2.zip

I should also note that there is a bug in 3C Toolbox that can make it look like the phone is booting at 2GHz. If you check the CPU times or go to one of the other two apps I mentioned you can verify that the phone boots at 1.5GHz.
 
Last edited:
Ok, I installed your kernel patch. I actually think the phone is plenty fast for my purposes; is there a way to determine the best settings for battery life instead of performance?

Edit-----

Well, it will let me OC, but even at the base clock AnTuTu and Linpack crash 100%.

I did run AnTuTu previously, and it didn't crash.
 
Last edited:
Could you post /proc/last_kmsg? I think I got the same thing, Antutu crashed at the havok engine, just want to compare logs. Quadrant has been running OK at least...
 
[03-22 23:57:36.743] [0][12815: rk:antutu3dtest]kgsl: _kgsl_sharedmem_page_alloc: kmalloc (36868) failed
[03-22 23:57:36.743] [0][12815: rk:antutu3dtest]rk:antutu3dtest (12815): undefined instruction: pc=c01baaa4
 
Antutu ran after the reboot, could be a memory leak or faulty driver. I know where to start at least, update coming soon.

RllNCx6.png
 
spock1104 said:
Antutu ran after the reboot, could be a memory leak or faulty driver. I know where to start at least, update coming soon.

RllNCx6.png
Click to expand...

What speed did you have max CPU set to for your score? That's about what I've been getting with the stock ZTE kernel. Maybe throttled?

Have you made any changes to voltage tables? Maybe undervolting would allow more overclock with less heat.

Also, I've been working a lot with Rockchip RK3288 devices over on the freaktab scene and some petty dramatic jumps in antutu scores have come from overclocking DDR and GPU, and leaving CPU relatively close to stock values.

Over there the oc has been applied a bit differently...since all of the Chinese manufacturers tend to keep their actual defconf and proprietary changes to themselves, despite GPL constraints, for the most part voltage and clock mods have been done through patching the actual hex values in binaries.

The Rockchip SDK is open source, it's the individual manufacturer's changes which they won't open up. PITA!

Also, for some reason Rockchip is making strange choices with sources. I don't know where I was going with that. Sleepy, lol. Anyway, they're focusing on chromium a lot. I don't foresee big market share there. I've been in contact with some people from the manufacturers requesting that arm/KVM host be added to the source and that seems to be happening, but without true defconfs for each platform a lot gets lost if you build generic kernels.

RK3288 has been integrated into mainline and current, but it doesn't do a lot of good when the GPU and VPU blobs are only at 3.10.

I'm rambling, gotta get some sleep. Way off topic, lol.

G'night. Cheers!
-SB
 
I'm not a big fan of overclocking, I incorporate it because it's the most asked for feature. I ran this at 1.5ghz. That said, I'm still seeing throttling in quadrant when I test oc, and antutu is acting up in the multi-core tests by not hitting the second core fully. For that reason I think quadrant will be the best gauge of progress for now.

My personal interests are battery life and efficiency, driven in part by kernel patches, updated drivers, newer toolchains, and optimized compiler flags.

We're okay staying at 3.4, there's plenty of examples to get upgrades from. We should be able to use the blobs from the warp 4g KitKat eventually.
 
I'm happy with the progress so far. I couldn't get my phone to stay on for so much as 24 hours before. Now...

z0iMhEl.png
 
Well, I tried to update the memory allocation but that went downhill real fast. Every bench I've run since the one above has completed, so for now I want to call it a fluke. If more information becomes available I'll look into it again.
 
You must log in or register to reply here.
Back
Top Bottom