88 replies to this topic

[Sebastian404]

kallt_kaffe, on 29 November 2011 - 05:46 PM, said:

Here's one I compiled using Toms repo with overclocking enabled.

Completely untested as I don't have a Blade2 myself.

I tried this one, and it seemed to work, and wifi is working, I'll have to have a look through you commit history to work that out...

[flibblesan]

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!

[Sebastian404]

flibblesan, on 29 November 2011 - 07:35 PM, said:

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!

ah yes, I was just looking at dmesg..

<3>[11-29 11:40:57.360000] [204: WifiService]dhd: version magic '2.6.35.7-perf+ preempt mod_unload ARMv6 ' should be '2.6.35.7-perf preempt mod_unload ARMv6 '

and then

E/WifiHW  (  154): insmod failed! module path: /system/lib/dhd.ko, arg: firmware_path=/etc/fw_4330.bin nvram_path=/etc/nv_4330.txt iface_name=wlan0
E/WifiHW  (  154): wifi_load_driver() -

ZTE do have some VERY strange ideas about things

[flibblesan]

Yes. Also the dhd.ko that is built from source wants fw_4319 and fw_4329 firmware, not fw_4330 that the Blade2 uses.

I'm getting a bit of a headache already.

[flibblesan]

hm.. doesn't help that the kernel source doesn't even have the BCM4330 code in it..

[t0mm13b]

What about CONFIG_MODVERSIONS being switched off?

[kallt_kaffe]

flibblesan, on 29 November 2011 - 07:35 PM, said:

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.

[flibblesan]

kallt_kaffe, on 30 November 2011 - 05:30 AM, said:

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.

[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.

[Adam Cable]

kallt_kaffe - overclock kernel works well, thanks once again

Adam

[admanirv]

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

What speed have you tried?

Cheers

[Sebastian404]

kallt_kaffe, on 30 November 2011 - 12:42 PM, said:

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...

[kallt_kaffe]

Sebastian404, on 30 November 2011 - 03:06 PM, said:

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.

[Sebastian404]

kallt_kaffe, on 30 November 2011 - 03:24 PM, said:

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.

[kallt_kaffe]

Sebastian404, on 30 November 2011 - 03:34 PM, said:

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/T...msm/acpuclock.c
That's the code that reprograms PLL2.

[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

[flibblesan]

Adam Cable, on 30 November 2011 - 11:32 PM, said:

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

[flibblesan]

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:

Quote

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.

[Adam Cable]

flibblesan, on 01 December 2011 - 10:35 AM, said:

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

[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!