Jump to content

Kernel Source for Crescent


Guest Simon O

Recommended Posts

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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! :)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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 by PsYcHoKiLLa
Link to comment
Share on other sites

  • 2 weeks later...

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.