Hi,
I've built some kernels that can be applied to the MiRaGe CM7 build. Below are the changes of each kernel build.
The 16 BPP frame buffer uses 16 bits per pixel instead of 32 bits per pixel. This reduces the amount of memory used for the screen frame buffer. It also means that when Android updates the screen, it has to move half the amount of data. This has the potential to increase performance. The potential downside is color banding. Using fewer bits for each pixel reduces the number of colors that can be displayed. I haven't noticed a difference in how the screen looks.
Compiling the kernel for speed versus size tells the compiler to use more memory if it will make the code run faster. This tradeoff uses less than 256k more memory (the Nook has 524288k) for the kernel.
By default, the backlight is turned on and off at a base frequency of 128 times per second. If you are at 50% brightness it will be turned on and off 128 times in one second. The 256Hz kernel doubles the rate at which the backlight is turned on and off as some people can see the backlight flashing at 128Hz. Since the switching is done in an interrupt to the processor, there is more overhead at the higher frequency so it's not a free change. Only use if the default screen seems to flicker.
encore_kernel_07302012.zip:
- 16 BPP frame buffer
- Compiled with -O2 instead of -Os (speed instead of size)
encore_kernel_256Hz_07302012.zip:
- same as above and 256Hz backlight instead of 128Hz
encore_kernel_07122012.zip:
- 16 BPP frame buffer
- Compiled with -O2 instead of -Os (speed instead of size)
encore_kernel_256Hz_07122012.zip:
- same as above and 256Hz backlight instead of 128Hz
Attached are CWM zips you can apply to probably any recent MiRaGe build.
Frank
For the uninitiated, what does this do? (layman's terms)
And how do you apply it?
Sent from my NookColor using xda premium
The kernel is the engine that drives your rom. It is the core of the system, responsible for drivers, modules and managing the communication between hardware and software, among other responsibilities. You already have one, you just don't have this one made just for you.
Looks like frankusb has put it into a flashable zip, so just flash it over your Mirage rom.
Alternatively, for emmc installs, you could just take out the uImage file from the zip, rename it to kernel and put it in any rom you want.
If you have an sd install, just replace the uImage in your boot partition with his.
------------------------------------------------------------------------------------------
off-topic
I've been following the 3.x kernel thread over at the Nook Tablet forum, as well as building and configuring my own from keyodi's source.
I'm not very good at it yet, though, and that's kind. My kernel builds tend to boot and I was able to enable the NAT stuff on my own (before the new .config was pushed) but that's as far as I have gone with it.
I wouldn't mind having a thread where kernel development was discussed, although frankusb, maybe you would rather keep the discussion on your kernel.
Here is fattire's post at the acclaim forum, urging people to try and build their own kernel. (with links and guides)
slack04 said:
For the uninitiated, what does this do? (layman's terms)
Click to expand...
Click to collapse
- The LEDs that bring light to the screen flash twice faster, so it should be less noticeable, especially at lower brightness levels and a darker room. You might have noticed that cameras (see Youtube) also see the Nook Color flickering.
- The screen is now updated at 60Hz instead of 44 frames per second. Most laptop/desktop LCDs are run at 60Hz. Can make it possible to have smoother graphics. Does give the programs a harder time to keep up if they try to do this, since they need to push 40% more image data per second.
- With half the bits (32 vs 16) to push to the display, graphics get slightly faster. I believe this is optional in Cyanogenmod settings.
---------- Post added at 07:47 AM ---------- Previous post was at 07:31 AM ----------
Over from the Mirage main topic:
Henk Poley said:
I'm talking about the backlight. On a static image I can distinctly see the corners of the display in a stroboscopic effect when I move the Nook Color by hand. As if the image quickly disappears and then time travels to another spot . It's quite annoying and possibly tiring.
(Probably spaced ~78mm)
Click to expand...
Click to collapse
With this kernel build I now see the flickering at a reduced distance when I move the nook color by hand. It does look like half the distance, like it should
Still noticeable though.
There is a bug now, that ever so often 100% brightness in RootDim puts the backlight brightness all the way down. I wonder if the unmodified driver has a similar race condition in writing the value to the PWM divider register.
mateorod said:
The kernel is the engine that drives your rom. It is the core of the system, responsible for drivers, modules and managing the communication between hardware and software, among other responsibilities. You already have one, you just don't have this one made just for you.
Looks like frankusb has put it into a flashable zip, so just flash it over your Mirage rom.
Alternatively, for emmc installs, you could just take out the uImage file from the zip, rename it to kernel and put it in any rom you want.
If you have an sd install, just replace the uImage in your boot partition with his.
------------------------------------------------------------------------------------------
off-topic
I've been following the 3.x kernel thread over at the Nook Tablet forum, as well as building and configuring my own from keyodi's source.
I'm not very good at it yet, though, and that's kind. My kernel builds tend to boot and I was able to enable the NAT stuff on my own (before the new .config was pushed) but that's as far as I have gone with it.
I wouldn't mind having a thread where kernel development was discussed, although frankusb, maybe you would rather keep the discussion on your kernel.
Here is fattire's post at the acclaim forum, urging people to try and build their own kernel. (with links and guides)
Click to expand...
Click to collapse
Are you building for Nook Color or Tablet?
Sent from my NookColor using xda premium
This kernel works for Nook Color.
Henk Poley said:
There is a bug now, that ever so often 100% brightness in RootDim puts the backlight brightness all the way down. I wonder if the unmodified driver has a similar race condition in writing the value to the PWM divider register.
Click to expand...
Click to collapse
You are very observant. This driver has an interesting detail.
There are cases where there is a 1/8 second delay before the brightness level is set.
I've noticed even before my change of frequency that sometimes when it dimmed the screen due to inactivity, it would flash full brightness.
Side note: This driver was originally written by Nokia, probably for either the 770 or N800. The 770 was my first internet tablet.
Frank
mateorod said:
I wouldn't mind having a thread where kernel development was discussed, although frankusb, maybe you would rather keep the discussion on your kernel.
Click to expand...
Click to collapse
I'm certainly OK with this thread discussing kernel development. I've been enjoying building the Nook kernel lately.
I doubt there's much to discuss about my particular kernel, at least so far, the changes are very minimal and mostly well known. The LED PWM frequency is the only new change.
Frank
Ur kernel makes the reading easier on eyes. Especially white background isn't too bright on webpages.
I think CPU adds 5% performance gains too.
However, can I apply this kernel on top of future upcoming mirage releases?
manic77 said:
However, can I apply this kernel on top of future upcoming mirage releases?
Click to expand...
Click to collapse
It depends on what mrg666 ends up doing but since I enjoy his rom, I'll probably keep this kernel current.
Frank
So...have you done any experimenting with different toolchains? I was originally using the one that I built making cm9, but then switched to the prebuilt linaro tool chain. I just recently installed the new 12.04 with 4.7 in it. I have seen the claim, (mrg666 makes it, for instance) that using certain toolchains gives performance advantages. I can't tell personally, but it's not like I put 'em through benchmarking or stress tests.
Anyway, the point is that I am debating building and configuring the 12.04 toolchain myself. What do you know, do you think it's worth it? I may just do it for the learning experience, regardless.
mateorod said:
So...have you done any experimenting with different toolchains? I was originally using the one that I built making cm9, but then switched to the prebuilt linaro tool chain. I just recently installed the new 12.04 with 4.7 in it. I have seen the claim, (mrg666 makes it, for instance) that using certain toolchains gives performance advantages. I can't tell personally, but it's not like I put 'em through benchmarking or stress tests.
Anyway, the point is that I am debating building and configuring the 12.04 toolchain myself. What do you know, do you think it's worth it? I may just do it for the learning experience, regardless.
Click to expand...
Click to collapse
I started with gcc 4.4 and then moved to Linaro 4.5. The kernel size got smaller but that's about all I can say. I have not come up with a good way to benchmark just the kernel (since that's all I'm recompiling). Android benchmarks don't seem repeatable to me. Way too much variance between runs. Also Android benchmarks aren't really testing just the kernel.
Then a source code change was required to move to Linaro 4.6. That's what I'm currently compiling with.
I did make one build with Linaro 4.7 from the 12.04 release but the kernel did not boot for me.
Frank
I didn't think the screen could get any better. I would use this but every time the screen times out it doesn't want to turn back on or when it does it gets really dim and touch is non responsive.
Sent from my NookColor using Tapatalk 2
I'm having trouble downloading the 7-1 kernel from my desktop (404 not found). Mirror or link fix, please?
foxalot said:
I'm having trouble downloading the 7-1 kernel from my desktop (404 not found). Mirror or link fix, please?
Click to expand...
Click to collapse
Weird - uploaded to a file host as well.
Frank
Great update and great work on the kernal once again. keep it up . can't wait to see everyone's work on 3.xx
Just installed Mirage 070512 and now confused as to which kernel to go with. Do I stick with the kernel from Mirage or do I flash one of the kernels in the OP? If OP, what are differences of the 3 kernels? I like the idea of 256, but not sure if 7/1 kernel also has 256? Appreciate any advice on this.
Sent from my NookColor using xda premium
360Razir said:
Just installed Mirage 070512 and now confused as to which kernel to go with. Do I stick with the kernel from Mirage or do I flash one of the kernels in the OP?
Click to expand...
Click to collapse
Your choice, the stock mrg666 kernel will work. Probably any of the 3 I built will work as well with the 070512 Mirage build.
360Razir said:
If OP, what are differences of the 3 kernels? I like the idea of 256, but not sure if 7/1 kernel also has 256? Appreciate any advice on this.
Click to expand...
Click to collapse
The 3 kernels are snapshots in time of 3 mrg666 stock kernels with my changes listed. The 7/1 kernel does not have a 256Hz refresh rate. I'd be glad to make one for you if you or others are interested. The increased refresh rate didn't do anything for me, but a 16 bit frame buffer and a different optimization did.
Frank
frankusb said:
Your choice, the stock mrg666 kernel will work. Probably any of the 3 I built will work as well with the 070512 Mirage build.
The 3 kernels are snapshots in time of 3 mrg666 stock kernels with my changes listed. The 7/1 kernel does not have a 256Hz refresh rate. I'd be glad to make one for you if you or others are interested. The increased refresh rate didn't do anything for me, but a 16 bit frame buffer and a different optimization did.
Frank
Click to expand...
Click to collapse
Thanks for the feedback, Frank. I will start with your 7/1 kernel and go from there. If you can make 256 with 7/1 then great...I will gladly put it through its paces. Thanks for all your efforts thus far.
Sent from my NookColor using xda premium
Related
TEAM n0ob FIRST RELEASE!
Ok after my OverClock How-To, I decided to play with overclocking and see what exactly can be gained from stock Max regulator Voltage (1.3v). I have found that at stock you can get up to around 1.13ghz. It is slightly faster than what pershoots kernel runs (38400khz).
As persiansown says, the standard stock voltage is set to 1275, and the regulator is maxed at 1.3v.
What Kind of gains will you see?
You will notice a difference in games like Asphalt, that use a lot processor. You will notice a decrease in battery life as well. Your linpack scores will vary from about 8.5-9.5 depending on your chip.
I have included pershoots undervolting, 21MB ramhack, and audio hack as well. Several optimizations, following in the footsteps of the Ivan/intersectRaven Kernels. (You could say we KANGED pershoot and just added two frequencies above his)
The frequencies in the kernel from 1113300-1152000 are at stock voltage(1.3v), and I have included the relevant source files. As such they "should" be safe. You never know though! The frequencies below this are Undervolted down to .925v!
This is using SLUB allocator and Deadline IO scheduler.
The recommendation of Team n0ob, is to use set CPU to set your phone to a frequency below 1.11ghz unless you need the extra power for something. Otherwise your battery life will suck and you will stress your processor for no reason.
This is confirmed working on CM-5.0.6-N1.
WARNING!!! THE LONG TERM EFFECTS OF OVERCLOCKING YOUR PROCESSOR CAN INCLUDE:
1. SHORTENED PROCESSOR LIFE
2. OVERHEATING
3. REDUCED BATTERY LIFE
4. BRICKED (IE DEAD DEVICES)
Mod edit: removed link, till source is link to kernel.
I ask that if you notice anything funny that you flash to a more tested kernel and notify this board immediately. This kernel is at stock voltage, but the increased speeds could have adverse effects. Please let us know if you notice any.
Team n0ob takes no responsibility for any damage that may occur to your device.
Credits: pershoot( thanks for the hard work), Kmobs (same), intersectRaven, Ivan (for beginning optimization trend), Rotohammer(experimental random/music/start fix), Cyanogen for awesome roms (whose source this is pulled from), chris soyars, and coolbho3000, Koush for the anykernel updater.
Team n0ob Testers: jlevey, DAMNiaTX Hell! (Thanks)
Following pershoot, I recompiled the Kernel with VFPv3 Optimizations.
resync to 2.6.33.3, old wifi drivers as everyone has problems with the new ones.
Lowered minV to 925. maxV is still 1.3. Voltages are increased to 1.3 only on the 2 frequencies above pershoots 1.113ghz. The other frequencies are undervolted similar to the Kmobs and or the Pershoot values.
Well, by "lowering processor life", how exactly long will my processor last? Does it depend on my phone? My uses? Im all in it for overclocking, and im very aware of said risk.. But processor life I'm not educated in..
Eclair~ said:
Well, by "lowering processor life", how exactly long will my processor last? Does it depend on my phone? My uses? Im all in it for overclocking, and im very aware of said risk.. But processor life I'm not educated in..
Click to expand...
Click to collapse
Not drastic. Not concrete figures but I've heard figures like instead of something like maybe 6 years, you may get 4-5 years. The processors are designed to last so long that even things that harm them typically still leave them outlasting the upgrade cycle of the user. It depends on the silicon in your phone as well.
Also, Gr8Gorrilla, does this include CM's latest commits from a day or two ago that fixes the pink cam tint issue?
No telling really. It shouldn't be much different than stock. However, as soon as I say that someone will install this brick the phone and blame me. So I am using it and I have a two year contract with T-mobile, I figure it should make it that far.
This is basically pershoots kernel plus 38400 khz. (pershoot in no way endorses this kernel). Take that for what it is worth. The top three voltages 1113, 1132, & 1152, are at stock voltage (1.3v).
I resynced my repo last night before compiling this.
Damn nice kernel is all I have to say
Gr8gorilla said:
I resynced my repo last night before compiling this.
Click to expand...
Click to collapse
Ok thanks! Definitely flashing this now!
Stock voltage is actually 1.275v. The processor is, however, rated to handle 1.3v (it was originally going to ship at 1.3v, but qualcomm decided to have it ship at 1.275v instead)
Gr8gorilla said:
No telling really. It shouldn't be much different than stock. However, as soon as I say that someone will install this brick the phone and blame me. So I am using it and I have a two year contract with T-mobile, I figure it should make it that far.
This is basically pershoots kernel plus 38400 khz. (pershoot in no way endorses this kernel). Take that for what it is worth. The top three voltages 1113, 1132, & 1152, are at stock voltage (1.3v).
Click to expand...
Click to collapse
I also am on a 2 year contract with TMobile, hopefully mine last that long also. Might as well flash this, blah..
persiansown said:
Stock voltage is actually 1.275v. The processor is, however, rated to handle 1.3v (it was originally going to ship at 1.3v, but qualcomm decided to have it ship at 1.275v instead)
Click to expand...
Click to collapse
I stand corrected. I should have said stock max regulator voltage. I will update the OP.
thanks Gr8gorilla
I'm definitely gonna try this out. I've been using intersect's and ivan's, just jumping back and forth. Good to see that there's another kernel out there to play with. Thanks Team n0ob!
Gr8gorilla said:
I have included pershoots undervolting, 8mb ramhack, and audio hack as well. The experimental Rotohammer fix for the headphone jack is compiled in as well, along with several optimizations, following in the footsteps of the Ivan/intersectRaven Kernels. (You could say we KANGED pershoot and just added two frequencies above his)
Click to expand...
Click to collapse
Does this have everything else that the default cyanogenmod's kernal has? (i just want to know if I am going to loose anything from cyan to this kernal)
INeedYourHelp said:
Does this have everything else that the default cyanogenmod's kernal has? (i just want to know if I am going to loose anything from cyan to this kernal)
Click to expand...
Click to collapse
Yes that is correct.
Nexus FireBall 1.15GHz.
I will be also flashing this kernel update to 1.15 GHz tonight. I want to try and optimize my nexus one to its fully potential capabilities. : )
Updated, Changed Kernel optimizations. Since this kernel follows pershoot, he recommends if you are on 5.0.6 to flash the VFPv3 optimized version.
VFP works great
Hi guys when i unzip their 4 files i know the ko and zimage but the other 2 files do i need to install them too?? and how? thanx in advance.
The other two files are the source files. They there so you can research what changes I have made in the voltage and frequencies and also you could compile this on your own if you want.
Over at PROJ: Overclocking the Adreno GPU on Snapdragon Devices they were trying to achieve to overclock the GPU to improve performance.
I've decided to open this thread for dedication for software porting/improving for adreno GPU on all Snapdragon chips.
1st thing we require/need to start work is:
Any source for the adreno/gpu drivers that are currently being run on our devices.
Its been mentioned that Acer liquid has same gpu running on lower cpu clock and achieving greater results.
Open source 3D driver for Snapdragon @ CodeAurora | Site Source
Acer liquid GPU drivers and source
Require Acer Liquid dump of adreno libegl files
Acer Liquid Kernel Source | Source site
AdamG working on this repo
http://github.com/xdabravoteam/cm-kernel
(May or may not be helpful)
glbenchmark: Acer liquid | Nexus One = Desire | EVO4G | Incredible
From there we should be able to improve our drivers from other devices but i think its a good start to look at the Acer Liquid since the source is available iirc.
That should be what we need for a start.
If i'm missing anything please let me know and i'll add it.
For reference to the other threads i posted.
Desire Porting thread | EVO4G porting thread | Incredible porting Thread
Hopefully we can get this project going and improve our GPU performance.
reserved for changelog
reserved for downloads/links
Alright, I'm going to write out everything I know so far in the best of my knowledge to help with others who are looking at this project. Conjecture will be separated off as thoroughly as possible. Let me know if any of this is wrong or needs updating, it's to be informative as possible.
Acer Liquid E:
There is a kernel framework that activates the GPU and provides clock and power control. Changing these states seems to be interrupt driven, upon the right signal the clock will be shuffled through a few states depending on load. The clock is always set through the minimum clock rate and the maximum clock rate is inflexible.
Outside of this, there is a non kernel-level driver binary that controls all other GPU operations. We do not yet know where it is or how it operates in the boot process.
Known points of interest:
Liquid E roms, to find the GPU binary driver portion.
Kernel source/drivers/char/msm_kgsl for the kernel portion of the driver.*
kernel source/arch/arm/msm/
Nexus One:
There too is also a kernel framework. It does not appear to initialize the driver at any point. In fact, I cannot find any external calls to the kgsl code whatsoever. They are most likely called from the binary portion of the driver, whose whereabouts are also a mystery.
Known points of interest:
kernel source/drivers/video/msm/ and msm/kgsl
kernel source/arch/arm/msm/
Conjecture:
My personal belief is that the radio plays a role in the Nexus One's GPU control system. It is the only part I know of initialized early enough to get us a framebuffer that isn't the kernel. The GPU may still be initialized in some part of the kernel I have not charted, but I have yet to see anything. Those whom I've contacted on this issue have not responded.
On a related note, there could also be a security system in the radio (or even the GPU firmware itself) that prevents kernel access to specific functions and further prevents user access to specific functions. If it exists and if it's a problem, we may have to find a way to maneuver around it.
The Acer E's binary driver really should be in the main part of any packaged rom. Upgrading it would be too useful to lock off somewhere.
Questions to answer so far:
How does the GPU get initialized in both devices?
Where in the process does this happen?
What is done during this time? (control handed off, some lockdown event, clocks set, etc...)
Is there a security mechanism that is set differently on the Liquid E?
If so, can it be defeated?
Where is the binary part of the driver for both devices?
Expected gains
The Acer Liquid E benches ~50% better (in nenamark at least) than the Nexus One. If we can get their driver implemented on our devices, we should get similar gains in OpenGL ES 2.0. OGL 1.1 (and 2D if implemented differently) performance gains may differ.
Anyways, I'll try as best as I can to help out anyone who is trying this undertaking while at the same time trying to avoid riling up everyone as bad on the radio subject as I did in the other thread. Also, I'm running this all from memory, so everything may not be spot on.
* If needed, I can chart out the functions to create a pleasant flow chart for people new to this area to follow.
EDIT: Oi, there's something really wacky about my formatting, only certain parts actually look really bolded. It's like my fonts shrink slightly after the Acer Liquid E list. Hope no one has bad OCD like I do.
EDIT 2: Updated with Jack_R1's correction below.
nothing to add here but my support
best of luck gentlemen, I believe this is definitely needed.
About time such a thread got started!I was tracking the thread about overclocking closely,but things got a little too intense there...
So,because I was in the UK for vacation this past week(call me an idiot,I'll accept it) and just got back in Greece I have some questions.First,wasn't intersectraven working on a kernel with the E's driver built in?How is that going?And second,would it be of any benefit trying to port the driver bit by bit?I mean,we could port one "piece" of it at a time and see where in the process things get nasty.
Thanks!
storm99999 said:
The Acer Liquid E benches ~50% better (in nenamark at least) than the Nexus One. The CPU on the E is clocked at 75% or so of the N1. There is a known relationship between the CPU and GPU clocks, so assuming it's perfectly linear, it is possible that the new GPU code would be 75% faster in OpenGL ES 2.0 code. Gains may be different in other OGL versions.
Click to expand...
Click to collapse
Have to correct this. The relationship of GPU clock to CPU isn't a given number, relationship to other places is. The GPU frequency is the same in Liquid E and in Nexus, so the gain will be 50%. Still, a lot to gain, if possible.
It's only semantics, but in case the porting succeeds - it's good to know the ballpark for the expected gains.
Best of luck with this effort, I hope it'll succeed.
tolis626 said:
And second,would it be of any benefit trying to port the driver bit by bit?I mean,we could port one "piece" of it at a time and see where in the process things get nasty.
Thanks!
Click to expand...
Click to collapse
We couldn't do it bit by bit, as it's an all or nothing deal, everything must be in place before the code works, but that did give me an interesting thought...
You see, iR did port the driver over, but it crashed on boot. There's two reasons for this, either it couldn't find a userspace driver and we're much closer than we think, or it went about the wrong way. We know that the driver can be ported without compilation errors based on this, so... I wonder if we can port both drivers at the same time? Give the framework for the current GPU driver to work so that it doesn't crash, but have the new driver reporting errors? It would at least show us a bit more about the boot process.
Say we had all of the new driver and all of the old. Only the new driver is "active" but the old driver has all of its symbols as they were. Any external program calling these symbols would get them, but they'd never be activated by the kernel. Even better, we could redirect the symbols to the CodeAurora equivalents. Then we could map what is actually called early on and possibly by whom.
It's a bit absurd, but it's a possibility going forward. Now if only we had some way of getting kernel panic dumps off of iR's kernel, then we could make some real progress.
Anyways, my big post updated to reflect Jack_R1's correction.
storm99999 said:
We couldn't do it bit by bit, as it's an all or nothing deal, everything must be in place before the code works, but that did give me an interesting thought...
You see, iR did port the driver over, but it crashed on boot. There's two reasons for this, either it couldn't find a userspace driver and we're much closer than we think, or it went about the wrong way. We know that the driver can be ported without compilation errors based on this, so... I wonder if we can port both drivers at the same time? Give the framework for the current GPU driver to work so that it doesn't crash, but have the new driver reporting errors? It would at least show us a bit more about the boot process.
Say we had all of the new driver and all of the old. Only the new driver is "active" but the old driver has all of its symbols as they were. Any external program calling these symbols would get them, but they'd never be activated by the kernel. Even better, we could redirect the symbols to the CodeAurora equivalents. Then we could map what is actually called early on and possibly by whom.
It's a bit absurd, but it's a possibility going forward. Now if only we had some way of getting kernel panic dumps off of iR's kernel, then we could make some real progress.
Anyways, my big post updated to reflect Jack_R1's correction.
Click to expand...
Click to collapse
This idea seems plausible, i'll pm iR if hes able to do that
If anyone reading this is also able to do this please let us know. I'm sure theres many people who are willing to test this.
i think that you should share this tread to desire and evo, and maybe get some more help from theirs devs. its basically what we all want
madman_cro said:
i think that you should share this tread to desire and evo, and maybe get some more help from theirs devs. its basically what we all want
Click to expand...
Click to collapse
That's right.Evo,Desire,Incredible,they all use the same GPU.I too believe we could cooperate with devs from these forums.
This brings back memories...
I'll keep an eye on this. Good job babijoee.
NeoS2007 said:
This brings back memories...
I'll keep an eye on this. Good job babijoee.
Click to expand...
Click to collapse
good memmories from wm))
tolis626 said:
That's right.Evo,Desire,Incredible,they all use the same GPU.I too believe we could cooperate with devs from these forums.
Click to expand...
Click to collapse
Will do lets all work together
NeoS2007 said:
This brings back memories...
I'll keep an eye on this. Good job babijoee.
Click to expand...
Click to collapse
like you i want to improve graphics on our beloved devices.
Edit:
I've setup a duplicate thread in Desire,Incredible and Evo threads all linking back to this main one. Alot of people are thinking the way to improve GPU is only to OC it and NeoS2007 and myself know better. We both were involved in winmo msm7k gpu software/driver improvement and achieved great results with the help of other xda members/developers.
Not for one second did i believe that our devices were running optimised graphic drivers and other devices such as Acer liquid E for example proves that.
Posted in the Evo section as well. Told some idiots to stay back
I think one thing that we had an issue with before was the fact that it wasn't integrated in the full Qualcomm kernel. There could have been other code in there it depended on that we didn't pull. We need to clone the whole CodeAurora kernel repo (.32) and build it and see if it boots.
Then there's the Liquid E stuff. And the new FroYo Sense kernel is a .32, so once we get HTC's source it may be able to be implemented there too. I don't think any of the Nexus kernels that are around are .32 so that could be why it wouldn't build.
Just my $.02
<Postedit> I hope you guys don't mind me detailing out all of what I've done with hopes that someone will find it helpful, it's very... verbose. Plus, if I have to share the source, I can remember exactly what files were tweaked to send a smaller than 700Mb file.
Alright, here's my current plan once I get my build environment stable again (oh hey, Ubuntu 10.10? Do it!):
The N1 code has two layers, a wrapper layer and the interface layer. The Liquid E code has only an interface layer which appears compatible to (but different than) the wrapper layer on the N1. I'm going to replace the N1's interface layer to see if it still runs. If it does, we now will have a current kernel build that would allow both drivers to operate, barring complications.
The current driver would have all the wrapper layer code it needs, but the new driver will have the correct interface layer code it needs.
Then, I'll bust open a Liquid E rom (Aren't the Liquid and Liquid E roms interchangeable? That worries me.), hunt down the driver, find out how it starts up in the system, add it to a current rom, test it for differences, and then break the interface layer by putting no-op asm.
This is all simplified (and possibly horribly wrong) of course, but anyone looking at this project may be interested in trying something similar.
Edit: Alright, I found out that both of them have an on-boot frame buffer, but the new Qualcomm one is much larger and more capable. I'll start my porting project there, as that quite literally could be the difference.
Edit2: Oh god the Kconfig errors! They've overtaken the ramparts!
Edit3: It looks like I'm missing a large series of .h files, but other than that, there have been no compilation errors. Also, if you end up where I am, you want MDP31 instead of MDP40, kinda caught me off guard.
Edit4: I like keeping things written down for everyone. Anyways, here's the list of file movements I've done so far for anyone interested, as I need to make sure that if I get a result, it must be duplicatable.
Acer Kernel linux/include/msm_mdp.h must be moved to the same place in a Cyan kernel.
All of Acer Kernel's drivers/video/msm/ must be copied over but the kgsl folder must stay intact.
A blank Kconfig must be made in the same folder.
The Acer Kernel's drivers/video/Kconfig must be copied over. The options you want:
We have a MDP31 chip
Not sure yet, but autodetecting the panel is what I've chosen
MDDP 2.0 doesn't seem to matter, so best left disabled.
After all of this, there seems to be missing a single .h file, which has the function dma_cache_pre_ops() and related in it.
Edit5: I really hope that putting this much detail out doesn't bother anyone... Anyways, the next step fixed most of this, I modified msm_fb.c to have this in the definitions:
Code:
#define pgprot_noncached(prot) \
__pgprot_modify(prot, L_PTE_MT_MASK, L_PTE_MT_UNCACHED)
#define pgprot_writecombine(prot) \
__pgprot_modify(prot, L_PTE_MT_MASK, L_PTE_MT_BUFFERABLE)
#define pgprot_device(prot) \
__pgprot_modify(prot, L_PTE_MT_MASK|L_PTE_EXEC, L_PTE_MT_DEV_NONSHARED)
#define pgprot_writethroughcache(prot) \
__pgprot((pgprot_val(prot) & ~L_PTE_MT_MASK) | L_PTE_MT_WRITETHROUGH)
#define pgprot_writebackcache(prot) \
__pgprot((pgprot_val(prot) & ~L_PTE_MT_MASK) | L_PTE_MT_WRITEBACK)
#define pgprot_writebackwacache(prot) \
__pgprot((pgprot_val(prot) & ~L_PTE_MT_MASK) | L_PTE_MT_WRITEALLOC)
This does throw some errors cause this isn't supposed to be there, but this is just a temporary hack.
The dma problem disappeared after that (don't know why...) and now I just have to find out why "info" is undefined at line 840 now.
Edit6: It looks like disabling the boot logo (as dumb as that is) gets rid of that error, but it throws a warning that the system needs the logo to be enabled. It's just a temporary measure, plus, I'd love to see a logo-less boot screen.
Edit7: Added a NULL to line 104 in drivers/video/msm/msm_fb_bl.c before
Geniusdog254 said:
Posted in the Evo section as well. Told some idiots to stay back
I think one thing that we had an issue with before was the fact that it wasn't integrated in the full Qualcomm kernel. There could have been other code in there it depended on that we didn't pull. We need to clone the whole CodeAurora kernel repo (.32) and build it and see if it boots.
Then there's the Liquid E stuff. And the new FroYo Sense kernel is a .32, so once we get HTC's source it may be able to be implemented there too. I don't think any of the Nexus kernels that are around are .32 so that could be why it wouldn't build.
Just my $.02
Click to expand...
Click to collapse
I have been using http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/drivers/staging/msm/mdp.c as a base reference for my work and for bugfixes, as the staging area has the driver implemented as a .35. I'm going to try something, maybe downloading the whole source from this one repo and using the config I got, maybe it will spare me the issue. It's so clean, so error free, I'm liking it.
Edit9: Alright, downloaded 2.6.35 kernel, copy-pasted staging driver, got rid of all the errors prior.
Wow great start storm it sound like you achieved quite alot in write short time frame. Keep it up. Need any testing? Let any of us know
babijoee said:
Wow great start storm it sound like you achieved quite alot in write short time frame. Keep it up. Need any testing? Let any of us know
Click to expand...
Click to collapse
Oi... I'm far away from testing here, my current goal is just to switch framebuffers... I realized where I'm going wrong, so I'm rebasing to iR's kernel source. It's a .35 source and that's been where all of my problems have been.
Quite literally, here's my procedure as of now: Get the Kconfig for drivers/video from the Acer Liquid E driver, copy and paste the framebuffer code from drivers/staging/msm to drivers/video/msm, try to compile.
I'll keep this post updated once I get the iR source downloaded.
Edit1: Alright, got my compiling to work, so far the only tweak I need to do is add "#include <linux/android_pmem.h>" to msm_fb.c (edit3: instead, put in msm_fb.h) , still having errors in GPIO...
Edit2: Added definition list from mach/proc_comm.h to staging-devices.c and mdp_vsync.c, repeated adding NULL as above in edit7.
Edit4: Changed line 23 in mdp_ppp.c to #include "msm_mdp.h"
Edit5: Commented out line 71 and 72 in mddi.c
Edit6: replaced dma_coherent_pre_ops and post_ops with dmb, as the functions prior don't exist and a commit says dmb replaces them. Really not sure about this. Compiling is smooth sailing from hereon out, except a duplicated function. Let's see if it kills my phone.
I have read through this and can say I honestly have no idea what half of the mumbo jumbo means but ill give it a bump and good luck to all you devs.
Sent from my Nexus One using XDA App
storm99999 said:
Oi... I'm far away from testing here, my current goal is just to switch framebuffers... I realized where I'm going wrong, so I'm rebasing to iR's kernel source. It's a .35 source and that's been where all of my problems have been.
Quite literally, here's my procedure as of now: Get the Kconfig for drivers/video from the Acer Liquid E driver, copy and paste the framebuffer code from drivers/staging/msm to drivers/video/msm, try to compile.
I'll keep this post updated once I get the iR source downloaded.
Edit1: Alright, got my compiling to work, so far the only tweak I need to do is add "#include <linux/android_pmem.h>" to msm_fb.c (edit3: instead, put in msm_fb.h) , still having errors in GPIO...
Edit2: Added definition list from mach/proc_comm.h to staging-devices.c and mdp_vsync.c, repeated adding NULL as above in edit7.
Edit4: Changed line 23 in mdp_ppp.c to #include "msm_mdp.h"
Edit5: Commented out line 71 and 72 in mddi.c
Click to expand...
Click to collapse
Ah k thanks for the update.
Title says a helluva lot ;-)
READ THIS WHOLE POST AND THE WHOLE POST AFTER IT!
Features:
All steps undervolted about 25%. Should be stable still
The table is currently 300, 600, 950mhz until I can make it scale more than 3 steps.
The voltage for 950Mhz is less than at stock for 800Mhz, so you should see better battery life even though we're overclocked.
Display flicker fixed (or at least toned down, it can't be completely eliminated with the LED backlighting)
Scheduler tweaks backported from later kernel versions
Some governor tweaks of my own for responsiveness
To install this, just flash the zip in ClockworkMod. This shouldn't harm your device, but I make no promises. I trust it enough to run it on my device, if that means anything to y'all. I also attached a zip to flash back to the stock kernel (..but why would you break my heart by doing so..? ;P).
Next Up:
I REALLY want to get 1Ghz+ working, and my code is sound (I'm sure of that) but it won't boot on my device. I think I just need to find the right voltage, or I could have a bad die for OC'ing. This is the first thing I will work on.
Maybe the interactive CPU governor
Look into the 2-point touch limitation
Source:
Source is available on my GitHub at https://github.com/geniusdog254/Quickie
I will not flat out ask for donations, however I do appreciate them. So if you're feeling generous or appreciate my work then it would help me out a lot if you could donate. I have my game Reflex-A-Tron on the Market for $1 if you'd like to donate like that, or there is a link under my name on the left side to donate, and one in my signature. The one on the left and in my signature is to donate via PayPal. Any amount is appreciated, but please don't feel obligated.
You can contact me here via PM, on Twitter @geniusdog254, or email me at [email protected]. Email or Twitter is the preferred method, because I really despise the XDA PM system.
Disclaimer:
If this breaks your Nook, kills your family/pets, or starts global thermonuclear war, do not blame me. You have been warned. If you break your device and blame me, I will point at you and laugh.
Changelog:
1-11-11 - Screamer:
Overclock to 950Mhz. Still chokes at 1Ghz, which tells me it's probably my device. 950 is stable.
Temp sensor drivers. Thanks to the Nookie FroYo guys!
Updated to 2.6.29.6.
Scheduling tweaks from 2.6.31.
Code idle time from 2.6.34.
Scaling fixed. Now scales properly between all 3 CPU levels. Adding more than 3 makes it choke for some reason. I'll look into it.
Test version set at 1Ghz added. Just because it doesn't work for me doesn't mean it won't work for you. Don't get your hopes up though, I've tried making it work every way from Sunday
Notes:
Screen WILL be unresponsive immediately after a boot. Just lock the device for several seconds, unlock it, and all will be fine until another reboot. I blame B&N, it happens with all custom kernels.
Yes, I know there are more versions of this kernel than there are Windows Vista. The middle one is the recommended one. If your Nook can't run at 950Mhz (crashing often, or just won't boot) try the one with the 900mhz tag. If you wanna try and push it higher, try the 1Ghz one. Be warned: very little success is reported with the 1Ghz kernel. The top level of these chips seems to be right around ~925-975Mhz. Very few devices will be able to hit 1Ghz.
You should probably wipe your cache partition after flashing this. You won't lose anything, and many people are reporting that it makes things more stable at the higher freqs for them.
MD5 Sums:
stock-1.0.1-kernel.zip — 78ccf8ab0cd35b988cc9a81bd8bbc310
quickie-1ghz-test.zip — 7076a88cae2229910478e698c0e19435
quickie-screamer.zip — 22e8c2cc21e42cca1d18377a92b49540
quickie-900mhz.zip — 40362515da86cb4baea37b0bc6358feb
Wow thanks so much for this. Gotta try it out!
wow very nice! going to have to give this a shot!
Awesome! But is it compatible with nookie froyo (2.2) or the stock BN (2.1)?
Update: It boots Nookie Froyo but powers off immediately after booting. I am looking forward to the release of the 2.6.32 version of your work. Keep up the good work!
Sent from Nook Color (Nookie Froyo microSd optional)
runhopskipjump said:
Awesome! But is it compatible with nookie froyo (2.2) or the stock BN (2.1)?
Sent from Nook Color (Nookie Froyo on emmc)
Click to expand...
Click to collapse
Just stock 2.1.
With the Nookie FroYo, it wouldn't flash the kernel to the SD for boot, plus (at least on th Epic) a 2.6.29 kernel won't boot on FroYo, it needs 2.6.32 or higher
Glad to have you part of the nook color family. You did awesome work on the Epic4G.
Looking forward to more great stuff from you.
Thanks
Sent from my LogicPD Zoom2 using Tapatalk
Loss of touch sensitivity
I loaded up the new kernel via Clockwork and all went smoothly with the install. I noticed immediately that my touch sensitivity has decreased. I now have to press and hold just about as long as you would press and hold to bring up a context menu or something. If I don't do that, my touch is ignored and not registered.
Interestingly enough, when I type an email on the keyboard, it recognizes my typing very quickly. No apparent loss of sensitivity when I'm using the keyboard. I wonder why and how that is???
I guess I need to recalibrate the screen again to regain sensitivity.
I did notice that Castle Crashers frame-rate has improved a good bit with the overclock. It's a noticeable and welcome difference.
Angry birds was a bit annoying to play with the loss of screen sensitivity.
Edit: I alleviated the loss of touch sensitivity by installing the LCDDensity app from the Android Marketplace and selecting a density of 200.
Tried to install via clockwork and I keep getting errors unable to install. an I missing something?
sent from my nookcolor using the xda app
Got it working with clockwork update... thanks!
Flashed. Am loving it, seems much snappier, and the keyboard response at 900mhzz is much improved. Keep up the good work!
NC overcklock
Hi,
Last month I made some tests with overcloking /undervolting. I was able to push the NC at 1.15GHz, with a little voltage tweaking. 1Ghz was achieved without voltage tuning. The smartreflex technology adjusts automaticaly the OPP voltages to minimize the power consumption. Maybe the L3 speed can be increased to 200 Mhz by setting DPLL at 400MHz (in u-boot).
Occip (working for 2.6.32 NC kernel)
deitiphobia said:
I loaded up the new kernel via Clockwork and all went smoothly with the install. I noticed immediately that my touch sensitivity has decreased. I now have to press and hold just about as long as you would press and hold to bring up a context menu or something. If I don't do that, my touch is ignored and not registered.
Interestingly enough, when I type an email on the keyboard, it recognizes my typing very quickly. No apparent loss of sensitivity when I'm using the keyboard. I wonder why and how that is???
I guess I need to recalibrate the screen again to regain sensitivity.
I did notice that Castle Crashers frame-rate has improved a good bit with the overclock. It's a noticeable and welcome difference.
Angry birds was a bit annoying to play with the loss of screen sensitivity.
Edit: I alleviated the loss of touch sensitivity by installing the LCDDensity app from the Android Marketplace and selecting a density of 200.
Click to expand...
Click to collapse
me too, seems touch for a while(XXms) take effect, less then that screen acts like nothing touch it. this drived me mad when using Gellery, switch pictures give terrible feeling.
i think this relay to the clock scaling, i will check this out using SetCPU.
thanks for your work!
Amazing work with the kernal. I flashed and changed density to 200 in Root Explorer /system/build.prop and it works great.
Also in Spare parts I change both animations to Fast instead of defaults.
occip said:
Hi,
Last month I made some tests with overcloking /undervolting. I was able to push the NC at 1.15GHz, with a little voltage tweaking. 1Ghz was achieved without voltage tuning. The smartreflex technology adjusts automaticaly the OPP voltages to minimize the power consumption. Maybe the L3 speed can be increased to 200 Mhz by setting DPLL at 400MHz (in u-boot).
Occip (working for 2.6.32 NC kernel)
Click to expand...
Click to collapse
Can you add me in GTalk? [email protected]
I have some stuff I'd like to ask about. How did you do the OC? Did you change the actual clock in u-boot so everything scales up? Or did you add more VDD_OPP* steps. I used some of the code I saw before for the Droid's 3430 chipset, using the OPP steps. The stock kernel has steps built in for up to 1.2Ghz, but if I enable them I can't make it boot, at least on my device.
I can't figure out the voltages either, probably because I fail at hex. If I understood that, it would help me a lot.
sugwacee said:
me too, seems touch for a while(XXms) take effect, less then that screen acts like nothing touch it. this drived me mad when using Gellery, switch pictures give terrible feeling.
i think this relay to the clock scaling, i will check this out using SetCPU.
thanks for your work!
Click to expand...
Click to collapse
Hrrm. It sounds like the CPU scaling is staying low, because I see absolutely no change in the touch sensitivity, and I didn't touch any of the code related to it. Try setting the CPU Governor to OnDemand or Performance in SetCPU if it isn't set there already.
Geniusdog254 said:
Can you add me in GTalk? [email protected]
I have some stuff I'd like to ask about. How did you do the OC? Did you change the actual clock in u-boot so everything scales up? Or did you add more VDD_OPP* steps. I used some of the code I saw before for the Droid's 3430 chipset, using the OPP steps. The stock kernel has steps built in for up to 1.2Ghz, but if I enable them I can't make it boot, at least on my device.
I can't figure out the voltages either, probably because I fail at hex. If I understood that, it would help me a lot.
Click to expand...
Click to collapse
diff is available http://nookdevs.com/NookColor:_Nookie_Froyo_Tips#Overclock_.5B100.25_untested_on_this_system.5D
occip said:
diff is available http://nookdevs.com/NookColor:_Nookie_Froyo_Tips#Overclock_.5B100.25_untested_on_this_system.5D
Click to expand...
Click to collapse
Odd. That's exactly what I've done (with a couple diff voltages) but it won't boot on my Nook. I guess I just got a bad die. Can you explain the voltage values? I know how to increase/decrease the hex number, but how does it correlate to the actual voltage? Like how is 0x38 = 1.35V in a stock kernel?
Definitely going to try this out. Thanks for the work. I'll report back with comments/questions/concerns.
nrune said:
Tried to install via clockwork and I keep getting errors unable to install. an I missing something?
sent from my nookcolor using the xda app
Click to expand...
Click to collapse
+1 I am getting the same. It installs half way then stops with a big exclamation mark, asks me to shut down and restart. I would love to try this. Any ideas?
EDIT: OK got it. CWM updated to 3005 and now it can go into recovery was on 3002 which did not.
This is very much appreciated.
Be expecting some monies so you can buy some candy in the near future.
keep up the good work.
Thanks!
[KERNEL][CM7][Froyo] Dalingrin's OC kernel w/fixed IO perf (quadrant) & 1.2Ghz test
Disclaimer: As always, flash at your own risk.
Background
So, recently there has been alot of debate over why quadrant (and to some extent, system performance) was lower with the OC kernel, as compared to the stock CM7 kernel. (http://forum.xda-developers.com/showthread.php?t=1002504) As part of my examining the problem, i went looking for a solution. Starting from the first OC CM7 kernel, i would run quadrant and see how the performance fared. I finally found the issue appeared in the 3-08a kernel; using that, i rolled back changes until i found the commit remove to fix the issue. Specifically, it seems to be somewhere in the 2.6.29.6 update: https://github.com/dalingrin/nook_kernel/commits/gingerbread-exp
In short, using his source, i have compiled a kernel with fixed I/O performance, and all his other tweaks (interactive gov, etc).
So, I want to make this clear; this is still dalingrin's kernel; in no way do i wish to take credit for his work. But, while he is out, work must go on, right?
Information
Who is this kernel for?
eMMC Froyo and CM7 users
Will this work on SD cards?
It may if you manually replace you uImage, but i cannot guarantee it (since i cannot test it)
Is everything working in this release?
everything like bluetooth and dsp should still be just fine (you may have to do a few hard shutdowns/reboots to kick on BT, like normal).
Kernel Links -3/25/10
OC kernels (up to 1100Mhz, Interactive gov, BT and DSP):
Regular
http://www.mediafire.com/?k00ruvyulf01y64
Extra network features (PPP, etc)
http://www.mediafire.com/?i9h76wn483tk16v
OC kernel (up to 1190Mhz, Interactive gov, BT and DSP):
http://www.mediafire.com/?v6d2jpzaynvchde
For those having problems setting this speed in the CM7 performance settings, give setCPU a try, but don't use profiles. Using set CPU, i am able to get my system stable at 1190, where the CM7 manager instantly locks up.
Feedback
After flashing, please make note of OVERALL system response. The dip in quadrant scores prompted the fix, but i feel that the system is overall better; I would like some more input if others are seeing this as well.
Any and all feedback is welcome, and I will do what i can for support...
Great job man, you and dalingrin both!
Ran 3 quadrant tests on newest nightly (#30)
1. 1856
2. 1700 even
3. Whopping 2030!
Can you be more specific about which network features are in the second choice ?
Thanks !!
ADude said:
Can you be more specific about which network features are in the second choice ?
Thanks !!
Click to expand...
Click to collapse
Um....truth is, i am really not too familiar with it, but looking a the diff between the two configs:
# Core Netfilter Configuration
# IP: Netfilter Configuration
# CONFIG_TUN
# CONFIG_PPP
I am trying out the net kernel again, to see if it is better than the last time i tried it..
Edit: Its looking better than the last time i tried it. Launcher pro hangs for a but on startup, but so far so good after that.
Just started using CM7 last night (w/bottom keys mod, so the nightly is from a few revisions back), but just installed this kernel (the regular version, w/out the Net adds, which I don't need), wiped cache & Dalvik, rebooted, set OC to 1100 and "performance" in CyangenMod Settings and now getting 1918 Quad score...vs. 1372 on the stock kernel with no OC.
I can definitely live with that score...great work to you and dalingrin!!
Thanks for taking care of this while I am gone. Much appreciated.
The update to *.6 is not necessary anyway.
When I get back I will revert the *.6 update and compile some of the netfilter/iptables and tun as modules as this seems to be more compatible than compiling them directly into the kernel.
Madcat, kudos to you. This is perceptibly faster.
great work!
so is this a 2.6.29.5 kernel then?
WOW, scrolling through XDA forum is much smoother than it used to be.
Tried on SDcard, installed by copying uImage to Boot. Reboots to EMMC when trying to load desktop. Back to CM7 stock. I guess I'll wait. Thanks though!
Homer
Can I have the config file for the first? I'm going to play with the kernel a bit.
EDIT: I'm just going to keep my big mouth shut for a while. I hoped it was just a bug with quadrant, but I flashed your kernel just now. There is a huge difference in interactivity. I was playing with the app drawer yesterday and couldn't get it to be smooth with "labels fade in" turned on and a 1000ms or so time on the animation for the app drawer. Now it's perfect every time.
GOOD JOB!
I love Open Source.
Will try this in some minutes. (Nook charging)
Ok, tested it. My scores below.
** QUADRANT SCORES **
Before update, 1100mhz: ~700
After update, 800mhz: ~1500
Now, 1100mhz: 1920
**********************
Awesome!
Just flashed it on mine and seems silky smooth to me. Not real sure there is a big difference, but it is not worse at least. Seems better to me.. Good job Madcat!!
Waiting anxiously for Dalingrin to return to his lab and see what else he can whip up for us..
nice!
i'm getting the same numbers as others (~1800) now. haven't really tested for overall smoothness yet.
will this kernel ever get a nookie version?
cowballz69 said:
will this kernel ever get a nookie version?
Click to expand...
Click to collapse
I have to admit - i said CM7 only, since that is all i have to test it on. If you do want to try it, you don't really risk anything; if it doesn't work, simply reboot to recovery and flash your last working kernel again.
As it is, i haven't really given a good look at what might be different between versions, so i can't give much advice on why it would/wouldn't work on Froyo.
Homer_S_xda said:
Tried on SDcard, installed by copying uImage to Boot. Reboots to EMMC when trying to load desktop. Back to CM7 stock. I guess I'll wait. Thanks though!
Homer
Click to expand...
Click to collapse
Got the same issue with the Net feature kernel. However the other one works fine. Got 1918 Quadrant on SD Card with OC 1100 GHz + interactive gov.
So I guess CM7 performance on SD is not too bad compared to eMMC
@Divine_Madcat : Could you look into the problem of the Net features kernel with SD Card booting? It run into eMMC after the bootanimation.
Thanks much for your work, an action is much better than thousand words !!
I tried both of these from SD card. The non-net features version boots but posted some terrible #s for me (<700 Quadrant and ~6-7 Linpack); the net features version doesn't boot. Is there something special I need to do with the first kernel to see the benefits? I checked and was clocked to 1.1GHz in CM settings.
victle said:
@Divine_Madcat : Could you look into the problem of the Net features kernel with SD Card booting? It run into eMMC after the bootanimation.
Thanks much for your work, an action is much better than thousand words !!
Click to expand...
Click to collapse
Ill be happy to take a look, but can't promise anything right away.
SCWells72 said:
I tried both of these from SD card. The non-net features version boots but posted some terrible #s for me (<700 Quadrant and ~6-7 Linpack); the net features version doesn't boot. Is there something special I need to do with the first kernel to see the benefits? I checked and was clocked to 1.1GHz in CM settings.
Click to expand...
Click to collapse
hmmmm.. that doesn't sound right at all. May i ask which nightly you are using? Right now, i am on nightly 27, and haven't seen anything like that (in my case, it either works, or just boot loops, if i set the clock too high).
Development Goals:
- stability
- energy savings due to more efficient algorithms (whether theoretical or not is unimportant)
- strictly no overclocking unless approved by the manufacturer or my source base integrates it (also, even if my source base integrates it, expect no support for it)
- no undervolting as well unless the manufacturer approves it since it's relatively pointless IMHO...
- all improvements should require MINIMAL user interaction (e.g. you don't need to do anything except flash the kernel or at the very least use SetCPU or the like to set fixed options)
- stability
Latest Kernel Here
20130625_10XX:
- updated with fix for more recent 4.1.2 Sense ROMs (should fix camera issue)
*unsure if this becomes incompatible with older 4.1.2 Sense ROMs though
20130602_07XX:
- NTFS support
- compiled using 4.8 linaro compiler
- improved workqueue queueing
- sleeper improvements
- responsiveness patches to the frequency controllers
20130531_09XX:
- fixed earpiece volume during calls
20130528_17XX:
- more optimizations (see GitHub)
20130527_18XX:
- more ARM implementations (see GitHub)
20130527_10XX:
- ARM implementations of kernel algorithms (see GitHub)
20130527_09XX:
- compiler optimization flags
20130526_22XX:
- initial version
- uses Linaro compiler
You can find my kernels at:
intersectRaven's Kernels
GitHub is at:
intersectRaven's GitHub
FAQ or something like that:
1.) Camera doesn't work!
- Try this fix from Golv here. This usually occurs on older ROMs.
*Latest 20130625_10XX version should solve this without flashing older camera libs.
Reserved 2
Reserved 3
Nice to see ir taking interest in the One. Truly a great dev
Sent from my Nexus 4 using Tapatalk 4 Beta
Uhhh nice to see you here
intersectRaven said:
Development Goals:
- stability
- energy savings due to more efficient algorithms (whether theoretical or not is unimportant)
- strictly no overclocking unless approved by the manufacturer or my source base integrates it (also, even if my source base integrates it, expect no support for it)
- no undervolting as well unless the manufacturer approves it since it's relatively pointless IMHO...
Click to expand...
Click to collapse
Could you please expound on your statement that undervolting is relatively pointless?
From my experience, undervolting
1. Improves battery life because of lower wattage (Voltage * Amperage = Wattage). Even with a really bad binned CPU, it can still make a difference.
2. Cooler operation. This means longer component life - especially important as this phone is very difficult to repair. Battery is sandwiched so the cooler we can keep the device, the longer the battery will last. (Battery longevity practices could be a topic of it's own)
3. It's Fun! Haha. But seriously. I love to tinker. How low can you go??? It's fun seeing a 25% decrease in voltage and it still run stable
I really like your approach with the rest of your points though. We should have a stable kernel that doesn't have to be tuned or tweaked at all. This however, only suites the majority. The minority may want more. I'm currently in the process of making a kernel with as few restrictions as possible. Except that I will put a ceiling on the maximum voltage (1.25v for the cpu)) because I discourage overvolting beyond spec.
Anyway, thanks for the work. The One is Awesome!
m0nz said:
Could you please expound on your statement that undervolting is relatively pointless?
From my experience, undervolting
1. Improves battery life because of lower wattage (Voltage * Amperage = Wattage). Even with a really bad binned CPU, it can still make a difference.
2. Cooler operation. This means longer component life - especially important as this phone is very difficult to repair. Battery is sandwiched so the cooler we can keep the device, the longer the battery will last. (Battery longevity practices could be a topic of it's own)
3. It's Fun! Haha. But seriously. I love to tinker. How low can you go??? It's fun seeing a 25% decrease in voltage and it still run stable
I really like your approach with the rest of your points though. We should have a stable kernel that doesn't have to be tuned or tweaked at all. This however, only suites the majority. The minority may want more. I'm currently in the process of making a kernel with as few restrictions as possible. Except that I will put a ceiling on the maximum voltage (1.25v for the cpu)) because I discourage overvolting beyond spec.
Anyway, thanks for the work. The One is Awesome!
Click to expand...
Click to collapse
Should have put a qualifier there huh? Anyways, it's pointless from a no tweaking perspective since undervolting may not work for some chips and could cause more trouble (random restarts and the like) than it's worth. It's fun for a tweaker (like when I did something like that for the N1) but not for someone who's the flash and forget type. :fingers-crossed:
Thanks
P.S you missing the ":" on the http link
Really glad to have you here iR. Missed your kernels from my nexus one days with those hybrid AVS kernels.
Camera is buggy
Sent from my HTC One using xda app-developers app
chourmovs said:
Camera is buggy
Sent from my HTC One using xda app-developers app
Click to expand...
Click to collapse
The camera will problably need som librarys, like most other kernels, I think. There is a zip for this in other threads (couldn't find it right away)
chourmovs said:
Camera is buggy
Sent from my HTC One using xda app-developers app
Click to expand...
Click to collapse
What is the problem exactly? Also, is this a custom Sense ROM or stock Sense? Just mentioning that it is buggy doesn't actually help me solve it since there are no bugs in my phone.
Sorry
I m on last ardh by mike86 and when I launch camera, it stuck on black canvas then I ve to hard exit
Sent from my HTC One using xda app-developers app
Intersect my man. Nice to see u in the HTC one forums!
Sent from my HTC One using xda app-developers app
Camera troubles
If somebody have problems with the camera, use the camera Fix from here:
http://forum.xda-developers.com/showthread.php?p=41712563
The bug is due to the old source code, released by HTC
If you are using a ROM based in 1.29.xxx.16 like the most of the new custom Roms flash just after the kernel.
Are the old camera libraries, that works with the Custom kernels.
chourmovs said:
Sorry
I m on last ardh by mike86 and when I launch camera, it stuck on black canvas then I ve to hard exit
Sent from my HTC One using xda app-developers app
Click to expand...
Click to collapse
Can you try the link posted below by Maikeu and get back to us whether it fixes the issue?
Maikeu Locatelli said:
If somebody have problems with the camera, use the camera Fix from here:
http://forum.xda-developers.com/showthread.php?p=41712563
The bug is due to the old source code, released by HTC
If you are using a ROM based in 1.29.xxx.16 like the most of the new custom Roms flash just after the kernel.
Are the old camera libraries, that works with the Custom kernels.
Click to expand...
Click to collapse
Posted this in the second post here for future reference.
HI, after fashing this kernel , i cannot hear any sound from call dial ,
008325 said:
HI, after fashing this kernel , i cannot hear any sound from call dial ,
Click to expand...
Click to collapse
Thanks for the heads up! Missed that in my testing. :silly:
*Uploading a fix now.
intersectRaven said:
Thanks for the heads up! Missed that in my testing. :silly:
*Uploading a fix now.
Click to expand...
Click to collapse
Thank you very much i really like this kernel , smooth , cold , save battery