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.
02/12/11: Froyo boots, stability issues resolved, all used modules from source except graphics. Problems: radio does not work, camcorder crashes the camera app, likely more issues. Big thanks to TheBirdman, SuperCurio and all the other devs working like myself out there to make this dream a reality. Gingerbread will come after Froyo is stabilized. As promised progress is being made.
This is not a Blazed kernel but will share in code fixes and versatility.
Thanks to TheBirdman, SuperCurio and others who's patches are pulled from TheBirdmans git to improve Fascinate compatibility.
The Eclair source appeared to be coded by multiple seperate teams simultaniously whilst Froyo source appears to be developed by one team and the sammy sources for the devices with Froyo are incrementally getting more updates as they move from one device to another.
Source will be posted soon, i am traveling right now and wanted to share this breakthrough from earlier today. Hint for those who can not wait the I9000 Samsung source contains almost everything you need except a graphics driver and a proper config, compare fascinate_defconfig, aries_eur_defconfig and the eclair defconfig or pull config from this kernel ;-)
The link below is for an alpha quality non-voodoo test kernel with ext4, ipv6, and full netfilter built in plus alot of extra modules stored in /system/kmodules:
02/16/11: Froyo Source Now Online!
03/10/11: Source pulled from laststufo's ULTIMATE SUPER OPTIMIZED Kernel for Galaxy S I9000
Wifi is working as client, Sound is working again, 3G radio that sometimes worked has stopped working again. This maybe a good thing though as it has indicated we may have been side stepping too much and avoiding drivers that may be more compatible than what we were actually using. The cpu is spot on, the sound is now using wm8994 aries and not wm8994 universal master. I suspect many incompatibilities in the platform still, but progress is being made. I think we were all just seeing too little with tunnel vision because of stress and perhaps a lack of sleep.
There are a number of goodies from laststufo in this tree (ramzswap, compcache, what appear to be usb host otg support just to name a few) non of which I have tested on fascinate but all of which compiled without error. I have tested overclock up to 1200Mhz, it supports up to 1.6Ghz (I would be very careful about anything past 1.2Ghz). VSF (Variable Screen Frequency) sync is broken ( a new feature from laststufo ) until replacement for the accel_xyz function of the smb380 is found, as the smb380 is not supported on the Fascinate, just as the yamaha compass driver is not supported. VSF's purpose is to save battery by reducing screen refresh rate when the device is being used in a minimal activity type situation.
I have not posted working binaries or full source to git yet, but I plan to have a new binary voodoo and non-voodoo up with source hopefully by sometime monday (but please don't hold me to it if I'm a little late)
Source:
GITHUB: http://www.github.com/sirgatez Last Updated 02/12/11
Binaries:
Non-Voodoo: http://db.tt/Y66iNVu - Proof Of Concept Alpha 02/12/11
Sent from my SCH-I500 using XDA App
I think I'm in love with you.
Sad news: it would only be bromance.
Anyhow, thank you so much for your hard work, and please keep it up!
It's incredible what you guys can do.
yay.. its just a matter of time till u make some magical work in froyo kernel.
i think punkkaos mentioned in one of his tweets that he was working on kernel, and got hardware acceleration on UI working but had graphical glitches, but he said that it was awesome fast.
Would that be possible here too ?
I will be looking forward to seeing this beast run on my phone once it hits the beta stage.
Maybe I'm mislead, but doesn't the i9000 froyo kernel use an rfs filesystem?
Sent from my SCH-I500 using XDA App
papstar said:
Maybe I'm mislead, but doesn't the i9000 froyo kernel use an rfs filesystem?
Sent from my SCH-I500 using XDA App
Click to expand...
Click to collapse
I think the nexus s is the only recent Samsung phone not using rfs. The rfs drivers in this kernel are in the stock i9000 source.
Sent from my SCH-I500 using XDA App
I should have source up by the end of the day heading home from hospital now.
I did some googling, correct me if I am mistaken but I can not seem to find the kernel module source for s3c_bc, s3c_lcd, or pwrsrv outside of Eclair. The eclair module for pwrsrv fails to boot, and the sizes of all 3 compiled binaries do not come close to the froyo ones from samsung. Both s3c modulea are less that or about 100k in froyo, eclair and eclair compiled against froyo are closer to 300k each. PowerVR driver is like 350k on froyo, and eclair and eclair compiled against froyo are 1.8/1.9MB. I did find a newer powervr driver from imagination last night but have to rework some code make it compile, and ti has the most recent driver from imagination but will not share unless you purchased a 1,600 evaluation board.
Sent from my SCH-I500 using XDA App
SirGatez said:
ti has the most recent driver from imagination but will not share unless you purchased a 1,600 evaluation board.
Click to expand...
Click to collapse
I can send a lot curse words TI's way atm.
Btw, how much performance do these drivers improve ?
3d accel nor graphics work without them. Sammies binary works as shown in the alpha posted but ti isnt to blame, imagination (imageon) makes and releases/licenses the driver and its code.
Just read an article saying they may opensource it in 3rd quarter this year I dont see that hindering us much right now with froyo, we can always dissassemble and recompile the binaries if we are left no other options to ensure gingerbread compatibility. Nexus S binary modules should work for gb testers at the moment, not sure how different froyo and gb powervr sgx drivers are right now but their are seemingly major internal changes from eclair to froyo. Every google result says both use the same gpu.
But Samsung is to blame for the lack of opensource froyo s3c_bc and s3c_lcd modules. But they look portable to froyo at the moment, will delve deeper into rabbit hole soon...
Edit: I have not tried to boot without loading these modules but when I compile and use the eclair powervr driver for froyo it driver load loops then boot loops then shuts down. The phone may work in 2d without them but I am doubtful. The kernel does have enough internal code (s3c_fb, s3c_cfb, etc) to display the i9000 startup image but the rest of the drivers are supposed to load before the bootanimation plays.
Sent from my SCH-I500 using XDA App
SirGatez said:
Just read an article saying they may opensource it in 3rd quarter this year I dont see that hindering us much right now with froyo, we can always dissassemble and recompile the binaries if we are left no other options to ensure gingerbread compatibility. Nexus S binary modules should work for gb testers at the moment, not sure how different froyo and gb powervr sgx drivers are right now but their are seemingly major internal changes from eclair to froyo. Every google result says both use the same gpu.
But Samsung is to blame for the lack of opensource froyo s3c_bc and s3c_lcd modules. But they look portable to froyo at the moment, will delve deeper into rabbit hole soon...
Edit: I have not tried to boot without loading these modules but when I compile and use the eclair powervr driver for froyo it driver load loops then boot loops then shuts down. The phone may work in 2d without them but I am doubtful. The kernel does have enough internal code (s3c_fb, s3c_cfb, etc) to display the i9000 startup image but the rest of the drivers are supposed to load before the bootanimation plays.
Sent from my SCH-I500 using XDA App
Click to expand...
Click to collapse
Damn, that's neat info. Where does one go to learn all this neat stuff about kernel, decompiling binaries and then compiling them again for another OS ?
StDevious said:
Damn, that's neat info. Where does one go to learn all this neat stuff about kernel, decompiling binaries and then compiling them again for another OS ?
Click to expand...
Click to collapse
Kernel hacking is very similar to any other reverse engineering effort, an under standing of asm is needed, as well as the file layout of thr target binaries.
Although technically reverse engineering by way of of binary decompilation is copyright infringement and a breach of most software usage licenses, but so is sharing binaries from one platform to another dispite the purpose.
Either way that isn't something I will be working on just yet unless an opensource driver for this surfaces we will use sammies for now and concentrate on making what we have stable. Fixing the radio and testing the other hardware are priority since the current binary froyo graphics driver does work atm. We will get an opensource version working later, if not then we worry about the the black box problem.
Sent from my SCH-I500 using XDA App
About 2 hours more research later I learned that a portion but not all of the PowerVR SGX/MDX drivers are open source, they are released like binary blobs with the open sourced portion of the driver enclosing the closed sourced blobs to function (much like how NVidia and ATI began their Linux Driver crusade), I will attempt to contact TI / Imagination for the open source portion of the drivers, they do not have them posted for public consumption but should have no problem providing access under the OSS/GPL. If anyone has these already they can send me a PM and it will save some time, likely the closest port that should work will likely be TI's OMAP34xx PowerVR SGX with modifications as it is already Linux compatible. There are about 3-4 versions of the driver, the external installer version does not match the internal library versions, v1/v2 is Pre-Samsung-Eclair/Samsung-Eclair, and I have downloaded v3 and attempting to get it to work with Froyo, I am not sure what version Froyo uses, v4 is avail for OMAP3xxx developers from TI linked to a development board that they sell. Not sure what version is available by request. I downloaded v3 but the problem I'm having with v3 is compiling has a data type conflict that I am attempting to resolve between the portions I pulled from v2 for Samsung compatibility.
Go SirGatez go
Good go, appreciate the effort for the greater good.
SirGatez said:
Kernel hacking is very similar to any other reverse engineering effort, an under standing of asm is needed, as well as the file layout of thr target binaries.
Although technically reverse engineering by way of of binary decompilation is copyright infringement and a breach of most software usage licenses, but so is sharing binaries from one platform to another dispite the purpose.
Either way that isn't something I will be working on just yet unless an opensource driver for this surfaces we will use sammies for now and concentrate on making what we have stable. Fixing the radio and testing the other hardware are priority since the current binary froyo graphics driver does work atm. We will get an opensource version working later, if not then we worry about the the black box problem.
Sent from my SCH-I500 using XDA App
Click to expand...
Click to collapse
is there like a link to guide or a book to learn ?
I know it's too early for feature requests... so I'm just going to leave this here... you know, for fun.
http://forum.xda-developers.com/showthread.php?t=709135
No pressure.
SirGatez said:
Although technically reverse engineering by way of of binary decompilation is copyright infringement and a breach of most software usage licenses, but so is sharing binaries from one platform to another dispite the purpose.
Click to expand...
Click to collapse
Nearly all of the innovators that make beautiful things happen with technology are in violation (or at least a gray area) of the law. It really is a shame.
I wonder how much bribe money it took to get the DMCA passed? I'm sorry, I meant "political funding".
Source is online now! Sorry for the delays, Enjoy!
http://www.github.com/sirgatez
I'm working on porting some features from Blazed into Froyo now, git will be updated once I verify everything works. To compile Froyo use the Fascinate_Blazed_defconfig. You will need need to use the stock modules pvrsrvkm.ko, s3c_lcd.ko, s3c_bc.ko for graphics to work. Use of hotspot_event_monitoring.ko, dhd.ko, dpram.ko, dpram_recovery.ko may also allow for operation radio and wifi although I have not tested this, so consider radio operations to still be broken, I am working on the issue.
I did manage to compile versions 2 (From Eclair, did not try Eclairs older EGL libraries with Froyo), 3 (Had android EGL libraries 1 subversion lower than stock Froyo) and 4 (no android egl libraries were included) of the PowerVR drivers and something is amiss and still results in a boot loop, something doesn't seem to be compatible, seems like I get missing library defines no matter how I try.
If someone has intimate knowledge about the PowerVR 3D and EGL on android and could PM me I would like to get some help on getting a fully working compile from source of the drivers that works. Any TI/OMAP3 experience with this driver should be applicable to this situation. I have not posted these drivers on git because there is a clickwrap license on the, you can get them from TI's website, some of them require a login to download, some of them are instant with no login.
I expect full source working drivers for all other devices except graphics within 7 to 14 days once the bugs and incompatible code is resolved, again the dhd wifi drivers are NOT compiling to the same size as the one provided by Samsung, so something seems fishy. If anyone from the internal Samsung Froyo dev team would like to help shed some light on why dhd.ko, pvrsrvkm.ko, s3c_lcd.ko, s3c_bc.ko all compile from the posted source to files 3-8 times the size of those included in Samsung's stock roms it would help progress greatly. Oh yes and I will not reveal any identifying information in exchange for your help unless you request it
Making progress with dpram/gpio control lines. Once I get this right the radio will be working like a charm. Dpram also controls operation of other major hardware such as camera, bluetooth, wifi, in addition to cellular. These devices all work independantly of each other but the dpram module handles the traffic and control i/o.
The galaxy phones while all sporting similar hardware have slightly different ways of controlling them.
Sent from my SCH-I500 using XDA App
Samsung released the source for froyo for the epic today.
http://www.androidcentral.com/samsung-releases-source-epic-4g-eb13-froyo-update
This is most likely of limited usefulness but hopefully a sign we wont have to wait long for the fascinate source.
Can someone port this kernek to ATT?
http://forum.xda-developers.com/showthread.php?t=1263838
tassadar898 said:
Can someone port this kernek to ATT?
http://forum.xda-developers.com/showthread.php?t=1263838
Click to expand...
Click to collapse
Its possible, but there are differences in the softkeys, charging hardware, and nfc at the minimum, so it will take a little work to port that over entirely. What would be better is for one of our current kernel modders to add some of the features of the SIYAH kernel over to their own.
I plan on pulling in 100 MHz support.
He doesn't have that much more, other than extremely experimental features that if you read the thread, tend to break.
Gokhan is quite talented, but he's also VERY aggressive - if you're more careful, you don't have to go through long beta periods with lots of broken releases like he does.
He also released source code for older kernels as megapatches, and now releases as straight full-source tarball drops. It makes separating the good from the bad EXTREMELY difficult.
As far as features he has that I don't currently:
1) 100 MHz support - I plan on this one, it's a fairly high priority as part of my current power management research
2) Crazy wacky alternative governors - these are a great way to somehow combine lag and poor battery life all in one
3) Charge current control - not possible on our devices, we have a different (very crippled) charger IC
4) Touchscreen stuff - I have seen no reports of people having touchscreen issues. If it ain't broke don't fix it.
5) BLN - I'm on the fence on this one. I think the I777 community may actually have the maturity to handle this one. (BLN's dirty little secret on the I9100/I777 - it holds a wakelock while the light is on. This means you lose 50% battery overnight instead of <10% if a notificiation comes in right after bed.)
Entropy512 said:
5) BLN - I'm on the fence on this one. I think the I777 community may actually have the maturity to handle this one. (BLN's dirty little secret on the I9100/I777 - it holds a wakelock while the light is on. This means you lose 50% battery overnight instead of <10% if a notificiation comes in right after bed.)
Click to expand...
Click to collapse
Would it be possible to get past the wakelock issue if you could program that the BLN shuts off after, say 30min, or user defined? That would work in my case but not sure if everyone universally would like it that way. Just a thought...
Hey Entropy nice to see you here! In siyah you can control the GPU voltage for undervolting. I currently do it using the Tegrak kernel module and I reduced the minimum step of 160 mhz to 750mv down from 950mv. I've noticed a nice bump in battery life. In his 2.1 beta version he also has this available feature
SiyahKernel v2.1 - not released yet -
Time to break some records... both performance-wise and battery-wise...
Overclocking part is optimized and bus frequency selection is modified.
User customizable frequency levels. you still have 8 steps, but you will be able to customize them. wanna change 100 to 150 as 100MHz is not stable on your device? wanna change 1400 to 1304 and 1600 to 1504? or increase 1600 to 1696?
User customizable bus frequency selection. no more overheating. if you are a battery freak, just set it to minimum and your device will last more than ever.
Based on Update3 sources...
Thanks for developing for us!!
I'll look into GPU voltage control once I finish my current power management adventures.
Custom frequency steps seems like asking for stability problems. There's no way this is getting ported until he releases 2.1 final, since he isn't very good about GPL compliance.
Thanks! I look forward to testing. If you need a guinea pig let me know.
Entropy512 said:
I'll look into GPU voltage control once I finish my current power management adventures.
Custom frequency steps seems like asking for stability problems. There's no way this is getting ported until he releases 2.1 final, since he isn't very good about GPL compliance.
Click to expand...
Click to collapse
GPU voltage doesn't bring that much other than stabilizing 400MHz, undervolting doesn't go that far down from stock voltages, unless you underclock heavily too.
Also get off his horse about GPL . The license states that you've got 90 days to release your code, until now he released it within the day for final versions, and betas are no longer released on XDA to get off that technicality of the 5 day rule.
There's enough kernels out there with the "stable" philosophy, some of which barely differentiate from stick sources, so people can go and use those if they want to. Siyah is more a Swiss army knife, but you'll have to be careful not to cut yourself, and it's more fun for some to tinker with the phone.
Edit: What you should port though, is update3 sources, those bring significant upgrades in battery life, speed and sound quality.
AndreiLux said:
GPU voltage doesn't bring that much other than stabilizing 400MHz, undervolting doesn't go that far down from stock voltages, unless you underclock heavily too.
Click to expand...
Click to collapse
Yeah, I figured as much, which is why it's pretty low on my priorities list
Also get off his horse about GPL . The license states that you've got 90 days to release your code, until now he released it within the day for final versions, and betas are no longer released on XDA to get off that technicality of the 5 day rule.
Click to expand...
Click to collapse
It says that nowhere. HTC claimed they had 90 days and that is a GPL violation. Easy enough to Google that one. It kind of bit them in the ass though - http://thread.gmane.org/gmane.linux.kernel/1048027 and https://freedom-to-tinker.com/blog/sjs/htc-willfully-violates-gpl-t-mobiles-new-g2-android-phone
After much media pressure they backed down and released sources in only 7 days.
GPLv3 gives an explicit 30-day grace period for resolving violations, but the kernel is not v3, it's GPLv2.
I really should stop pointing Gokhan towards fixes since he's a one-way street.
There's enough kernels out there with the "stable" philosophy, some of which barely differentiate from stick sources, so people can go and use those if they want to. Siyah is more a Swiss army knife, but you'll have to be careful not to cut yourself, and it's more fun for some to tinker with the phone.
Click to expand...
Click to collapse
Yup - If someone else wants to port his more aggressive features they can try - it's just not coming from me.
Edit: What you should port though, is update3 sources, those bring significant upgrades in battery life, speed and sound quality.
Click to expand...
Click to collapse
I'll have to look into that - As of a few weeks ago, the AT&T I777 sources were new enough that I9100 kernels (including Siyah) started to be based off of them. The question is - while Update2 to Update3 is a big improvement, is I777 to update3 such an improvement?
I'll have to check those out tonight and diff them.
update3 is a vastly bigger update than what the AT&T sources were to update2. Performance wise, it's a clear-cut, audio too. As for battery life check back in the AOS thread.
Looking forward to see the update being incorporated.
AndreiLux said:
update3 is a vastly bigger update than what the AT&T sources were to update2. Performance wise, it's a clear-cut, audio too. As for battery life check back in the AOS thread.
Click to expand...
Click to collapse
I'm going to start this over the next week - I've split update3 into what should be separate independent patchsets by component (touchkey, audio, wifi, etc.)
Last one is likely going to be the machine-specific ARM stuff - because that means rewriting the clock control patches completely.
I'm trying to get the standard kernel configuration (defconfig) for this device as the Xiaomi repo is a mess. If you have a rooted phone, you can copy the /proc/config.gz to your /sdcard/ then to a Windows PC and extract it with 7-zip file manager: https://www.7-zip.org/ and post it here. To root, go here: https://en.miui.com/unlock/download_en.html
I managed to find all (?) the required files to build the kernel under different repos on the Xiaomi site (I had to look under different devices, the Redmi K40 Pro+ device tree is missing Camera and Display which is under the star-r-oss device tree, updated a few days ago). My GitHub is definitely not as clean as it should be after merging everything, but the point here is to have 1 repo where all development can begin easily. I will try to rebase it when I have time to make the commits clearer.
https://github.com/mrslezak/hadyn-r-oss/commits/haydn-r-oss
Consolidated Xiaomi sourcecode with some minor fixes added - device tree imported, QCACLD 3.0 added (not sure it's used by this kernel, but it was in their repo, so I put it under drivers/staging), camera and display for vendor pulled from a different device tree on their repo (it's the correct one, however - https://github.com/MiCode/kernel_devicetree/tree/star-r-oss/qcom/camera and /display). The defconfig is definitely wrong right currently. Hence my request here.
If you want to fork it, here is what you want to get started building kernels / troubleshooting build errors (this moves WAY up the Linux chain to 5.4.61, so get ready for some strange things...)
My compiler toolchains can be git cloned from here: https://github.com/mrslezak/toolchains
I am currently using the BuildClang12.sh build script in the directory which only uses Proton-Clang 12, so you don't need all the toolchains. The latest is Clang-13 but I have not attempted using it: https://github.com/kdrag0n/proton-clang . I have built many stable kernels using the build of Clang-12 in my toolchains repo, so I trust it and use it to build kernels for the Op8T with no issues whatsoever with many people using the kernels I built. It's of course your choice which compiler to use. You also need to clone the Anykernel3 repo: https://github.com/osm0sis/AnyKernel3 if you want to use my build script.
BTW if you want to get this phone, and can understand some Chinese (suggestion: cheat and use Google Lens + Translate), the 12/256GB + 108mp camera is available from the largest retailer in China (jd.com). You need an international debit card (CapitalOne charges nothing to convert Yuan to USD), however, and if your country charges import fees YOU WILL HAVE TO PAY THEM. Edge and Google can translate the website for you but you probably will need to order using their app on your phone (in Chinese only). It's incredibly hard to setup but you will pay retail price. And this rebadged device will only be available at 8gb/256gb max as a Xiaomi Mi i Global (700 Euros or $825 USD), where the Chinese variant Redmi K40 Pro + comes with 12GB/256GB (< $600 shipped express), and has the correct bands to work on LTE and eventually N41 5G on T-mobile's network in the USA when they build it out. It won't support NSA 5G (which is terrible anyhow where I live, it uses the congested LTE band 66 to connect to 5G band N71). Something to maybe consider if you have good NSA 5G where you live (USA only), this kernel will work on both phones once it's fixed up. Then I intend to "tame the beast" Snapdragon 888 which is already overclocked to death, running 840mhz GPU and the X1 prime core which is not designed to be efficient - power only. The A78 Cortex cores are much more battery friendly.
BTW you didn't hear it from me, but the 888+ is already in the source code for the 888 devices clocked at 900mhz GPU and who knows what CPU frequency. It already throttles like mad on most devices (except this one (best phone w/out a fan), the ROG5, and RedMagic 6, which both use external cooling fans to avoid throttling, and will set you back some $800-$1000+). I'm not a gamer, so this is the best choice for an 888 if you want a nice phone that doesn't throttle as much as any other on the market (based on stress test videos of all the phones on YouTube), and don't want an expensive phone either. Uses the same Super AMOLED panel as the S21 Ultra by Samsung, just at FDH+ instead of the higher resolution. And the cameras are the best in the category, other than the Mi11 Ultra, Samsung S21 Ultra, etc.
Will you plan to support K40 Pro (non Plus) as well? My phone needs ~100 hours to unlock.
Thinks!
mslezak said:
you can copy the /proc/config.gz to your /sdcard/
Click to expand...
Click to collapse
this thing https://github.com/cfig/Android_boot_image_editor can parse boot.img with kernel_configs.txt.
like this https://github.com/alex9yust/alioth_bootimg_unpack/tree/master/boot.img
alex9yust said:
this thing https://github.com/cfig/Android_boot_image_editor can parse boot.img with kernel_configs.txt.
like this https://github.com/alex9yust/alioth_bootimg_unpack/tree/master/boot.img
Click to expand...
Click to collapse
Good call, I've been speaking with that developer over the last few weeks, I didn't realize the config.gz was in kernel_configs.txt (but I can't seem to find that file, unpacking the boot.img). Appreciate it. Although through further research I have found that the new GKI / ACK setup requires both an Image file (inside boot.img) and a GTK module set compiled (in vendor_boot).
khanhdx said:
Will you plan to support K40 Pro (non Plus) as well? My phone needs ~100 hours to unlock.
Click to expand...
Click to collapse
I think it's just a different config file, if I can figure out how to compile it right. The new GKI / ACK interface is causing me to use a whole new set of tools to do anything. GKI 1.0 sucks. I've built a Google Pixel kernel already but haven't managed to get the damn Xiaomi source code to output everything needed for the kernel to work properly. Although I have to wait another 6 days for my unlock to go through so I can't test the kernel I built (stock first, then I'll mod it). Issue is now the dtb is in vendor_boot instead of boot.img so I sent over some code to Osm0sis to put it into his AnyKernel3 when he gets a chance. Although kdrag0n's flasher should work already, he used it on a Google phone, can't recall which one. Both super cool devs BTW.
Anyway, don't expect this kernel to come out right away, these damn 888 phones throttle like mad. They need a lot of tweaking. I have to figure out what causes all the heat - the X1 cortex, the A78 medium cores, or the Adreno GPU... Then I have to tame that down and boost what isn't causing the heat to make up for it. The goal I have is a phone that will run as fast as stock but not fry an egg... if I can get it faster I will. If not, a phone that doesn't throttle would be a win. Just depends how busy I am at work...