Kernel Source for Crescent

[Guest t0mm13b]

What about CONFIG_MODVERSIONS being switched off? :(

[Guest kallt_kaffe]

The wifi lib dhd.ko expects the kernel to be version 2.6.35.7-perf+ (with the +).

The dhd.ko that is built with the kernel should work but needs some firmware files in etc renaming for some bloody reason.

Damn you ZTE!

I used the configuration supplied with the source as I do not not have a phone. Perhaps you loose the "+" when using an extracted config.

But if everything else fails, just hexedit the module.

[Guest Simon O]

I used the configuration supplied with the source as I do not not have a phone. Perhaps you loose the "+" when using an extracted config.

But if everything else fails, just hexedit the module.

hex editing didn't work for me, but adding the + to the end of -perf in the config helped. Kernel source works fine and I've also used Tom G's kernel code without any issues too thanks to your blade2 additions.

Now we just need BCM4330 adding to the code so we can build our own wifi libs! For some reason the current source builds for an older chipset.

[Guest kallt_kaffe]

Now that you are overclocking... Very likely the GPU will overclock with the CPU overclocking so you will be limited either by the GPU or the CPU. This is the same for the Skate but not true for the Blade and the V9.

From what I've seen the GPU is tied to PLL2 which is what is used to overclock the Skate and the Blade2 (for some, yet unknown reason, using PLL0 did not work). On the Blade/v9 PLL2 is almost at it's maximum setting allready when running at 600MHz so therefor PLL0 is used. Using PLL2 to overclock the Blade/V9 actually underclocks the GPU.

For the Skate and the Blade2 this is mostly good as you also get a 3D performance boost, but the drawback is that you may be limited by the GPU but still have more overclocking potential in the CPU.

If I ever get a Blade2 or a Skate I might try again to use a different PLL because that would make it possible to invidually control CPU and GPU clock.

[Guest Adam Cable]

kallt_kaffe - overclock kernel works well, thanks once again :)

Adam

[Guest admanirv]

Any quadrant before and after values, I know quadrant isnt the best but it gives an idea.

What speed have you tried?

Cheers

[Guest Sebastian404]

Now that you are overclocking... Very likely the GPU will overclock with the CPU overclocking so you will be limited either by the GPU or the CPU. This is the same for the Skate but not true for the Blade and the V9.

From what I've seen the GPU is tied to PLL2 which is what is used to overclock the Skate and the Blade2 (for some, yet unknown reason, using PLL0 did not work). On the Blade/v9 PLL2 is almost at it's maximum setting allready when running at 600MHz so therefor PLL0 is used. Using PLL2 to overclock the Blade/V9 actually underclocks the GPU.

For the Skate and the Blade2 this is mostly good as you also get a 3D performance boost, but the drawback is that you may be limited by the GPU but still have more overclocking potential in the CPU.

If I ever get a Blade2 or a Skate I might try again to use a different PLL because that would make it possible to invidually control CPU and GPU clock.

I'd like your view on something...

as I mentioned I got sick of messing about with the patches and built a kernel from the original source, but added in the extra speeds into acpuclock.c and that worked fine for me.. I had it maxed out at 1036MHz for a good hour or so..

however when I tried your build to get the Wifi working, it would not last more than 5 minutes before rebooting...

wondering if something was up with the device, I reverted to my built kernel and its been up for about an hour now, without any issues......

I know every device is different and all... but I was wondering if you have any ideas...

[Guest kallt_kaffe]

I'd like your view on something...

as I mentioned I got sick of messing about with the patches and built a kernel from the original source, but added in the extra speeds into acpuclock.c and that worked fine for me.. I had it maxed out at 1036MHz for a good hour or so..

however when I tried your build to get the Wifi working, it would not last more than 5 minutes before rebooting...

wondering if something was up with the device, I reverted to my built kernel and its been up for about an hour now, without any issues......

I know every device is different and all... but I was wondering if you have any ideas...

If you just added extra lines to the frequency table without the other code present then you did a classic "cosmetic overclocking". If so, then you are not the first and likely not the last. You can put 2GHz in there if you want. It will happily show you are running at 2GHz and it will be rock solid.

Here's how it works.

There are three PLLs running at different speeds, 245, 960 and 800 unless I remember it wrong. In the frequency table you tell it what PLL it should use and what divider it should use. For example PLL0 (960MHz) with divider 2 makes the 480MHz speed. For the Skate and the Blade2 PLL2 is 800MHz and uses divider 1 (dividers are always set as (divider - 1) in the table.

Actually you should be able to overclock the skate and the Blade2 with just changing the frequency table by using PLL0 and divider 1 (0 in the table). That would create a 960MHz frequency and leaving the GPU clock (and all other clocks intact).

However, we want options, so what we can do is to change the speed of PLL2. The PLLs are configured by using multipliers and it can be configured up to 63*19200kHz. So what the code (that you are propably missing) does is that for speeds above 787200kHz it modifies the multiplier of PLL2 and when it comes down to 787200 or lower it restores it's original value again. This is also why this way of overclocking affects the GPU. On the Blade and the V9 I know that the GPU is tied to the PLL2 as 3D speeds went down when CPU speed went up when I used PLL2 for overclocking. That is why the Blade and the V9 uses PLL0 instead. PLL0 on the other hand is connected to the camera so overclocking does underclock the camera and can cause some (acceptable) issues. Most likely the GPU is tied to PLL2 on the Skate and the Blade2 aswell but using a different divider and on the Skate and the Blade2 PLL2 starts on 800MHz so we have 50% to go. On the Blade and the V9 it starts at 1190MHz and we can only increase it from multiplier 62 to multplier 63 (which I also do) to get a tiny bit extra out of the GPU.

[Guest Sebastian404]

If you just added extra lines to the frequency table without the other code present then you did a classic "cosmetic overclocking". If so, then you are not the first and likely not the last. You can put 2GHz in there if you want. It will happily show you are running at 2GHz and it will be rock solid.

Here's how it works.

There are three PLLs running at different speeds, 245, 960 and 800 unless I remember it wrong. In the frequency table you tell it what PLL it should use and what divider it should use. For example PLL0 (960MHz) with divider 2 makes the 480MHz speed. For the Skate and the Blade2 PLL2 is 800MHz and uses divider 1 (dividers are always set as (divider - 1) in the table.

Actually you should be able to overclock the skate and the Blade2 with just changing the frequency table by using PLL0 and divider 1 (0 in the table). That would create a 960MHz frequency and leaving the GPU clock (and all other clocks intact).

However, we want options, so what we can do is to change the speed of PLL2. The PLLs are configured by using multipliers and it can be configured up to 63*19200kHz. So what the code (that you are propably missing) does is that for speeds above 787200kHz it modifies the multiplier of PLL2 and when it comes down to 787200 or lower it restores it's original value again. This is also why this way of overclocking affects the GPU. On the Blade and the V9 I know that the GPU is tied to the PLL2 as 3D speeds went down when CPU speed went up when I used PLL2 for overclocking. That is why the Blade and the V9 uses PLL0 instead. PLL0 on the other hand is connected to the camera so overclocking does underclock the camera and can cause some (acceptable) issues. Most likely the GPU is tied to PLL2 on the Skate and the Blade2 aswell but using a different divider and on the Skate and the Blade2 PLL2 starts on 800MHz so we have 50% to go. On the Blade and the V9 it starts at 1190MHz and we can only increase it from multiplier 62 to multplier 63 (which I also do) to get a tiny bit extra out of the GPU.

ahh, that would explain a lot :) I'm not really a fan of overclocking something that most people carry around with them.. for some reason.. but I'm always keen to learn... thanks for the explanation :)

Does the extra code you refer to live in drivers/cpufreq/freq_table.c?

I found some posts and some documents from you back in the old Blade days about over clocking and that was the two files that you messed with.

[Guest kallt_kaffe]

Does the extra code you refer to live in drivers/cpufreq/freq_table.c?

No, that was set det default to 600MHz before I knew of the MIN MAX settings. No, it's in another part of acpuclock.c.

All needed changes is in acpuclock.c. CM7 also need some changes in cpufreq.c but for SetCPU that is not needed.

EDIT:

Look at the code starting at line 542 and 571 here: https://github.com/TomGiordano/kernel_zte_blade/blob/2.6.35/arch/arm/mach-msm/acpuclock.c

That's the code that reprograms PLL2.

[Guest Adam Cable]

Looks as though the kernel has caused touchscreen issues and loss of using the front camera on my SF2.

What's the easiest way for me to put the stock kernel back on - is there a link around?

Adam

[Guest Simon O]

Looks as though the kernel has caused touchscreen issues and loss of using the front camera on my SF2.

What's the easiest way for me to put the stock kernel back on - is there a link around?

Adam

Confirmed. My kernel I built from Tom_G's repo has missing front camera and touchscreen is slightly off. I'll rebuild using the blade2 source and see if that works ok.

Update: Still the same with the blade2 kernel code. I think ZTE haven't shared the correct code again!

Adam: Link to stock kernel on my custom ROM thread. It'll work for both OSF2 and Vivacity

[Guest Simon O]

Update on this. To enable the front camera we need to add support for the OVM7690 sensor. This is the VGA front camera sensor, the rear being the OV5640 5MP unit that apparently supports 720P recording...

The stock kernel config has both of these enabled:

CONFIG_OV5640=y

CONFIG_OV5640_GLOBALOPTICS=y

CONFIG_OVM7690=y

CONFIG_OVM7690_GLOBALOPTICS=y

I try to build a kernel using the same config but I find that, for some reason, the OVM7690 is being removed.. it's likely that the code we have doesn't even have any support for this. I need to keep looking.

[Guest Adam Cable]

Confirmed. My kernel I built from Tom_G's repo has missing front camera and touchscreen is slightly off. I'll rebuild using the blade2 source and see if that works ok.

Update: Still the same with the blade2 kernel code. I think ZTE haven't shared the correct code again!

Adam: Link to stock kernel on my custom ROM thread. It'll work for both OSF2 and Vivacity

Cheers - will d/l the kernel now #legend

[Guest Adam Cable]

Seems as though stock kernel still gives me a slight issue with the touchscreen, although less pronounced than without the o/c kernel. Could the screen widths of the SF2 and Vivacity be slightly different?

Front camera back in action though! :)

[Guest Simon O]

Are you having the issue where the far right of the screen seems a little unresponsive?

[Guest Adam Cable]

It's the right side of the screen where I see issues - so I have to press slightly to the left of the letters on the keyboard to get the one I need.

The far right side (last few mm) doesn't respond at all to presses.

[Guest Simon O]

It's the right side of the screen where I see issues - so I have to press slightly to the left of the letters on the keyboard to get the one I need.

The far right side (last few mm) doesn't respond at all to presses.

Same issue I have then. I have uploaded both the SanFran2 and Vivacity kernels to my ROM page. The SanFran2 kernel should work better for you.. fingers crossed.

[Guest Adam Cable]

Yes, all resolved \o/

[Guest Bouncer5]

How were you able to get the kernal? The first zip of 8 seems corroupt for me!

[Guest PsYcHoKiLLa]

Yes, all resolved \o/

I had the same problem as you with the keyboard, the ouk-stock.zip fixed it for me but then I lost wireless, you sure you don't have the same problem?

[Guest Adam Cable]

Wifi working a treat. You may need to lose stored wifi details, and connect again...

[Guest Simon O]

Removed the split files since most of the links removed for some reason. The big file is still online.

HOWEVER, the code is exactly the same as a previous source release which is being hosted and modified by some people at https://github.com/TomGiordano/kernel_zte_blade

I would personally use this!

[Guest PsYcHoKiLLa]

Wifi working a treat. You may need to lose stored wifi details, and connect again...

Yeah I tried tapping "Forget" for both my wireless networks and re-entering the passwords, still no joy. Think I'll just wait for the CM releases coming soon :)

The orange rom really is disastrous though, install more than 2 apps and the thing just crawls...slower than the original Blade :(

Also when I look at the internal memory there's very little available, on my original Blade I used to be able to keep the free space around 200MB by pushing suitable apps to the SD. Is this just due to crap partitioning by Orange?

Edited December 8, 2011 by PsYcHoKiLLa

[Guest Adam Cable]

Has anyone had any lucking building an OC kernel that supports Wifi?

Thanks,

Adam