Related
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.
Inspired by supercurio's move away from tarballs at http://forum.xda-developers.com/showthread.php?t=1054738 and my own successes with the Infuse community at http://forum.xda-developers.com/showthread.php?t=1185796 (man I need to update that thread...), I've put up the Samsung tarball on github for your forking pleasure.
github is a vastly superior way to manage kernel sources than putting up source tarballs of kernel releases.
Right now the source tree is a raw unmodified import of the Samsung Open Source Center's tarball. Chances are likely it needs some cleanup to get into a good buildable state, just like the Infuse source drops did.
Rather than importing a cleaned up tarball, I believe it's best to do a straight import, so the cleanup process is documented in git commits.
The repo is located at: https://github.com/Entropy512/linux_kernel_sgh-i777
A repo for the initramfs based on the stock initramfs dump is at https://github.com/Entropy512/initramfs_sgh-i777
I may be getting a GS2 tomorrow - it depends on if my local AT&T store is willing to give me any sort of deal via my corporate discount (probably not) and on the return policy. I'm really borderline as to whether the GSII is worth $549 to come from the Infuse.
yes it is. 21 hsdpa+ and dual core should be worth it.
mrRobinson said:
yes it is. 21 hsdpa+ and dual core should be worth it.
Click to expand...
Click to collapse
Infuse has the high speed HSPA too. GS2 has smaller screen and a worse headphone amp, which offsets the benefit of dual core. Even a 1.2 GHz single core is pretty snappy. Google Wallet support is going to be the make or break for me. Unfortunately it's sounding like AT&T will break it to do their own thing.
Sent from my SGH-I997 using Tapatalk
Here we go again...
1GB > 512MB
2 cores > 1 core
Those are the two selling points for me.
kletiz said:
1GB > 512MB
2 cores > 1 core
Those are the two selling points for me.
Click to expand...
Click to collapse
Actually the Infuse has 640MB, which is enough, but yeah, the dual core A9 and TouchWiz 4 are nice.
The answer would be clear if it were a choice between the two devices on contract subsidy.
However, it's "Is it enough of a step up from the Infuse to justify $549" - For me, not unless Google Wallet support is there (I have a Citi PayPass-enabled card, so the only thing I'm missing is the phone side of GW support). However with AT&T backing Isis this seems like it may not happen.
This is getting offtopic though... We should take the discussion of whether it's enough of a step up to General.
Successfully dumped the stock zImage, which means stock initramfs.
Now to get my kernel tree cleaned up and buildable, then to integrate clockworkmod from codeworkx's template.
I botched the kernel repo name. It should have been linux_kernel_sgh-i777, but was inux_kernel_sgh-i777. This has been fixed but if you cloned it, your remotes are probably screwed up.
Updates - kernel:
Cleaned up cruft from Samsung's tarball and set up .gitignores
Added easy-build script
Minor defconfig changes, mostly to support easy-build and also to generate smaller kernels
Integrate codeworkx's cpuidle fix patch (Assume this is valid for the GSII as it's in generic kernel code)
Updates - initramfs:
Attempt to integrate clockworkmod from codeworkx's template. (Tested - works as long as you use Home/Back instead of Power for selections)
@Entropy
https://github.com/teamhacksung/clockworkmod_galaxys2att_initramfs
Ramdisk is now based on UCKH7, which i've extracted from your stock kernel.
codeworkx said:
@Entropy
https://github.com/teamhacksung/clockworkmod_galaxys2att_initramfs
Ramdisk is now based on UCKH7, which i've extracted from your stock kernel.
Click to expand...
Click to collapse
Thanks, I'll work on merging in those changes. I may transition to using a fork of your initramfs for my kernel builds.
After seeing these 2 links out there I refuse to buy V30 as long as it has outdated kernel without sched governor support
What do you think?
Then don't get it. I'm going to.
Sent from my iPhone using Tapatalk Pro
Request a dev add it.
We'll have custom kernels.
ChazzMatt said:
Request a dev add it.
We'll have custom kernels.
Click to expand...
Click to collapse
No. I don't want to drop $840 for top-phone and than seek paths to get it hacked, rooted and flash custom kernel in it to get just the same experience which others have in their $400-$550 phones. Like Xiaomis which vendors are fast to deliver modern linux and android kernel enhancements
That's what EAS it for https://forum.xda-developers.com/z5-premium/general/announcement-energy-aware-scheduling-t3620897
I'm willing to bet it doesn't. Pixel devices were the first to launch with it because the code is baked into the AOSP mainline kernel. As much tinkering as every manufacturer does to their device, and the relative newness of this kernel schedule, chances are that it's not.
Sent from my VS995 using Tapatalk
ChazzMatt said:
Request a dev add it.
We'll have custom kernels.
Click to expand...
Click to collapse
Billy Madison said:
No. I don't want to drop $840 for top-phone and than seek paths to get it hacked, rooted and flash custom kernel in it to get just the same experience which others have in their $400-$550 phones. Like Xiaomis which vendors are fast to deliver modern linux and android kernel enhancements
That's what EAS it for https://forum.xda-developers.com/z5-premium/general/announcement-energy-aware-scheduling-t3620897
(This below is a quote from post #1 of that link, so this is what he wants you to read... I'm posting it so you don't have to go there. But feel free to click the link anyway if you wish.)
PDesire said:
In help with @zacharias.maladroit we ported Energy Aware Scheduling (EAS) to our Xperia Z5 Premium
The benefits I already see:
The CPU is really cooler (that what Snapdragon 810 needed)
The idle time has been increased ALOT (like 50% more idle time)
Also it seems battery life has been improved alot
The Port repo:
https://github.com/PDesire/XperiaSatsukiEliteKernel/commits/hotplug
Stay Tuned, this kernel will go online soon
Click to expand...
Click to collapse
Click to expand...
Click to collapse
Too funny. The link you just posted was a dev ADDING it to a Sony Experia Z5 custom kernel -- just like I said could be done easily for our LG V30 (if it doesn't have it already).
You proved my point.
Tbh why everyone wants EAS ? To have a ****ty Scheduler implementation provided by CodeAurora and get disappointed by it ?
The only device which works very well with EAS is the Pixel, and do you know why ? They don't use the CodeAurora implementation, they use their own one. And to use Google's implementation you need Google kernels and not kernels which are based on CAF (like most Snapdragon kernels are).
So keep with HMP, it's not bad like everyone is thinking
Your PDesire
Whats next? To blame the V30 cause it wont include itunes.. (-_-)
PDesire said:
Tbh why everyone wants EAS ? To have a ****ty Scheduler implementation provided by CodeAurora and get disappointed by it ?
The only device which works very well with EAS is the Pixel, and do you know why ? They don't use the CodeAurora implementation, they use their own one. And to use Google's implementation you need Google kernels and not kernels which are based on CAF (like most Snapdragon kernels are).
Click to expand...
Click to collapse
Thanks, mate. I see that you know vastly more than I do in android development space
But please look at that
Even if not look into second run which V30 supposedly loose due to 4Gb onboard vs 6Gb the first round speed is also pathetic. And this link in OP is telling us of very much improved kernel in Galaxy Note 8 compared with all previous generations of Touchwiz and Samsung kernels. Samsung was a beaten boy for it's proverbial lage but it is no more. While LG is becoming the most laughed at Android vendor with it's stutters, lags and hiccups every one complaining about. LG doesn't do nothing to improve in that space, what leads to frustrated and disgruntled customers hence loss continuing for 12 quarters loss of sales and market share. With that pace LG is gonna vanish and be sold to Google as ODM like HTC at best
Does Oreo for V30 support Energy Aware Scheduling (EAS) ?
https://github.com/xzr467706992/KonaBess/releases/tag/v0.14 is the app that allows us to play with frequency clocks, regulators, etc.
I wrote a post in another thread - How to Guide Redmi K40 Pro ROOT Tools. This is just the instructions so you can get right to it. Make sure you have the fastboot ROM installed (the way Xiaomi.eu is packaged or the MIUI source you used on your phone), or you can export in the KonaBess app to the root SD card and transfer back to your PC. I highly recommend using the most updated FastBoot and ADB tools found here, the guy is religious so go pray to your deity of choosing, or to the earth, wind, fire, whatever the heck you believe in I don't care. https://forum.xda-developers.com/t/...sb-driver-installer-tool-for-windows.3999445/ thanks bro for that tool.
****** SO HERE ARE THE INSTRUCTIONS SO YOU CAN GET MODDING!!!! *******
Just FYI, most people don't know what I'm talking about when I say "voltage regulators for the GPU." The goal here is to use the first one on the top of the list (top is lowest voltage, bottom is highest) that can support the frequency your GPU Mhz are defined at. As you go up a regulator, the voltage increases, which leads to more power usage and hotter temperatures. Note that I played with it a little bit, and it DOES NOT seem to allow large changes in frequencies (higher that is, without upping the regulator*** you may not be able to use the higher regulators because of a commit I found in KonaBess (noted later). So it's usefulness may be not as great as I had hoped on the OC side, the throttling side, yes this could be invaluable.
If it doesn't boot, ensure you have your fastboot ROM downloaded somewhere (or use the program, it will extract vendor_boot.img to the root directory for you, save off to your PC where fastboot is located as you'll have to use PWR+Volume Down to go to fastboot, then reinstall the original vendor_boot.img (the new format saves this info in this new partition) by typing:
fastboot flash vendor_boot vendor_boot.img
fastboot reboot
Now this tool looks great for underclocking. I booted at 295mhz low and 825mhz high without changing the voltage regulators. But note the program seems a bit buggy - it will (sometimes) drop the max clock when you change it, so you MAY need a kernel manager like SmartPack to set on boot the max clock speed. At least until the code is fixed. I was able to boot on a lower regulator at 150mhz BTW [LEVEL_LOW_SVS_D1], and I didn't notice any performance difference! Just watch out for dropped frames, which can happen if your spacing is too far apart, or your frequency clock not giving enough juice. This can be done just viewing the screen - set it how you like it - power hungry or power friendly or mix and match.
These are the GPU Voltage Regulator Names (extracted from Linux 5.6.41 K40 Pro Plus / Mi11i source, codenamed haydn), listed from lowest voltage to highest. You have 10 choices I believe (regulator 0 is always the max frequency, regulator 9 is the lowest frequency):
LEVEL_RETENTION (so low it may not display anything)
LEVEL_MIN_SVS
LEVEL_LOW_SVS_D1 (note: I got it to boot at 150mhz on this regulator)
LEVEL_LOW_SVS default for 315000000 (315mhz) [REGULATOR 9 STOCK]
LEVEL_LOW_SVS_L1 default for 379000000 (379mhz)
LEVEL_LOW_SVS_L2
LEVEL_SVS default for 443000000 (443mhz)
LEVEL_SVS_L0 default for 491000000 (490mhz)
LEVEL_SVS_L1 default for 540000000 (540mhz)
LEVEL_SVS_L2 default for 608000000 (608mhz)
LEVEL_NOM default for 676000000 (676mhz)
LEVEL_NOM_L1 default for 738000000 (738mhz)
LEVEL_NOM_L2
LEVEL_TURBO default for 778000000 (778mhz)
**LEVEL_TUBRO_L0 -> added by KonaBess, not sure you can actually use it as it would require a kernel modification
LEVEL_TURBO_L1 default for 840000000 (840mhz) [REGULATOR 0 STOCK]
The levels below are turned off by KonaBess on "old 888 firmware" in commit https://github.com/xzr467706992/KonaBess/commit/e12afa47c7255e5ce1d33d97700479f67449ff89 - I presume the K40 Pro Plus supports it as it has an 888+ qcom,speed-bin = <1> defined at 900mhz on the LEVEL_TURBO_L2 regulator in the file lahaina-gpu-v2.dtsi, while Mi11 code does not have this regulator defined in the file: qcom,rpmh-regulator-levels.h) NOTE: get fastboot up on your PC before you mess with any of these regulators, you'll need it! You'll be fastboot flashing vendor_boot.img a lot. The device is already super OC'd by Qualcomm stock. That's why 888's throttle so much. Now that may be GPU or CPU related, we don't know yet. This will give us some idea. Watch temps wisely:
LEVEL_TURBO_L2
LEVEL_SUPER_TURBO
LEVEL_SUPER_TURBO_NO_CPR (okay this regulator sounds scary - CPR is used to bring someone's heart back to life after it stops beating... use with EXTREME CAUTION. My guess is it turns off all overheating protection)
My K40 Pro Plus is packed up for resale, start a conversation with me if interested ($620 USD basically Mint condition + S&H, extra rugged case + cam lens tempered glass, no markup @ China price, Xiaomi.EU stable 12.5.3 rooted with Magisk Stable and has Vanced (YouTube and Music no ads), Netflix L1, Amazon US, AdAway, all Google Services and apps like Calendar, Contacts, Messages, Chome, Discovery, Lens, GPay always worked when I used the phone before, etc. just login to your Google account and everything will auto-setup). A guy said he'd buy it from me this Friday if I hold it for $700, we'll see about that. I know it works on T-mobile USA alright LTE (N41 5G IF deployed to your area, its not in Houston, TX yet for me to test) and many EU countries frequency coverage is even better. Start of conversation with me if interested I have loads of pics on other websites. Selling because I can only build so many kernels and I have way too many phones. **I'll delete this portion once sold, not sure if the XDA rules allow me to post it (sorry moderators if I violated a rule, just trying to give a great deal to someone who is looking for an 888, I'm not making ANY money).
Back to the topic at hand. I would begin starting at the 840mhz and switch it to one lower regulator, i.e. switch to TURBO instead, and likely drop the mhz too if it fails to boot. Then repeat the rest the same way (1 level down) but only modify 1 at a time, test, then it's fastboot time if it doesn't support it OR you succeeded (write down the numbers). Then run 3DBench 1 test run first. If that works fine, you can run the stress test for 20m after you're happy with all your new frequencies and see if it runs well (no fragments, no lag, etc). If so, keep it there. You should be able to see any FREQUENCY changes in SmartPack Kernel Manager (free on the Playstore or Github, under GPU menu). You can make up your own clock speeds too. I tried dropping the max clock to 825mhz from 840mhz and it booted fine; the AnTuTu v9.0.5-OB graphics segment was lag free. This is silicon lottery customization BTW, some chips will run better at different frequencies and regulators than others.
I hope you find this post useful, took me A VERY LONG TIME to put it together to simplify the GPU adjustments using KonaBess app. It's easiest to make small changes, remember OC'ing an already OC'd device (straight from QCOM, yes they OC'd it) is not likely to work work well - any OC attempts should be like +5000mhz or +10000 at a time. All 888 phones throttle on the default config when pushed hard enough (i.e. like during a bench / stress test session). Since you are mostly testing graphics, I suggest the 3DMark 20 minute stress test for stability verification. If you underclock the GPU enough, you can probably eliminate throttling while still getting a good bench result, while adding to your screen on time (SOT). Throttle free and fast, with decent battery, and you have a winner.
Although if you want to play with the often randomly changing AnTuTu benchmark, you can do that that a little bit faster. I just think that is used by OEMs to sell phones after using it for so many years, I noticed the version #s started to increment a lot faster as more 888 phones were released. From AnTuTu v9.0.1-OB to v9.0.5-OB scores just randomly seemed to change. Companies like RealMe and Nubia (RedMagic) cheat the bench anyway to give you higher scores that don't mean anything in actual use. 3DMark seems like a more consistent bench. Anyway, regardless of which bench you chooose, mark the first runs at the current settings. Let the phone cool down and close all open apps before benching (5 minutes is a good rule of thumb for all apps to load). For more consistency, turn on airplane mode and turn off bluetooth / nfc / etc. Try to run your benches at the same battery % (have that charger ready).
Please post your findings here and notate your device, the mhz you chose, the regulator you chose, etc. so people can work from your values. As I mentioned, you are testing your silicon lotto ticket here - most chips will differ between one another. Your 888 only has to pass a minimum spec to make it to production. Some are all stars and some barely make the cutoff. That's life, it's okay, they are all fast anyway. Even the worst chip will still be fast.
Feel free to like this post if it helped you out!
mslezak said:
https://github.com/xzr467706992/KonaBess/releases/tag/v0.14 is the app that allows us to play with frequency clocks, regulators, etc.
I wrote a post in another thread - How to Guide Redmi K40 Pro ROOT Tools. This is just the instructions so you can get right to it. Make sure you have the fastboot ROM installed (the way Xiaomi.eu is packaged or the MIUI source you used on your phone), or you can export in the KonaBess app to the root SD card and transfer back to your PC. I highly recommend using the most updated FastBoot and ADB tools found here, the guy is religious so go pray to your deity of choosing, or to the earth, wind, fire, whatever the heck you believe in I don't care. https://forum.xda-developers.com/t/...sb-driver-installer-tool-for-windows.3999445/ thanks bro for that tool.
****** SO HERE ARE THE INSTRUCTIONS SO YOU CAN GET MODDING!!!! *******
Just FYI, most people don't know what I'm talking about when I say "voltage regulators for the GPU." The goal here is to use the first one on the top of the list (top is lowest voltage, bottom is highest) that can support the frequency your GPU Mhz are defined at. As you go up a regulator, the voltage increases, which leads to more power usage and hotter temperatures. Note that I played with it a little bit, and it DOES NOT seem to allow large changes in frequencies (higher that is, without upping the regulator*** you may not be able to use the higher regulators because of a commit I found in KonaBess (noted later). So it's usefulness may be not as great as I had hoped on the OC side, the throttling side, yes this could be invaluable.
If it doesn't boot, ensure you have your fastboot ROM downloaded somewhere (or use the program, it will extract vendor_boot.img to the root directory for you, save off to your PC where fastboot is located as you'll have to use PWR+Volume Down to go to fastboot, then reinstall the original vendor_boot.img (the new format saves this info in this new partition) by typing:
fastboot flash vendor_boot vendor_boot.img
fastboot reboot
Now this tool looks great for underclocking. I booted at 295mhz low and 825mhz high without changing the voltage regulators. But note the program seems a bit buggy - it will (sometimes) drop the max clock when you change it, so you MAY need a kernel manager like SmartPack to set on boot the max clock speed. At least until the code is fixed. I was able to boot on a lower regulator at 150mhz BTW [LEVEL_LOW_SVS_D1], and I didn't notice any performance difference! Just watch out for dropped frames, which can happen if your spacing is too far apart, or your frequency clock not giving enough juice. This can be done just viewing the screen - set it how you like it - power hungry or power friendly or mix and match.
These are the GPU Voltage Regulator Names (extracted from Linux 5.6.41 K40 Pro Plus / Mi11i source, codenamed haydn), listed from lowest voltage to highest. You have 10 choices I believe (regulator 0 is always the max frequency, regulator 9 is the lowest frequency):
LEVEL_RETENTION (so low it may not display anything)
LEVEL_MIN_SVS
LEVEL_LOW_SVS_D1 (note: I got it to boot at 150mhz on this regulator)
LEVEL_LOW_SVS default for 315000000 (315mhz) [REGULATOR 9 STOCK]
LEVEL_LOW_SVS_L1 default for 379000000 (379mhz)
LEVEL_LOW_SVS_L2
LEVEL_SVS default for 443000000 (443mhz)
LEVEL_SVS_L0 default for 491000000 (490mhz)
LEVEL_SVS_L1 default for 540000000 (540mhz)
LEVEL_SVS_L2 default for 608000000 (608mhz)
LEVEL_NOM default for 676000000 (676mhz)
LEVEL_NOM_L1 default for 738000000 (738mhz)
LEVEL_NOM_L2
LEVEL_TURBO default for 778000000 (778mhz)
**LEVEL_TUBRO_L0 -> added by KonaBess, not sure you can actually use it as it would require a kernel modification
LEVEL_TURBO_L1 default for 840000000 (840mhz) [REGULATOR 0 STOCK]
The levels below are turned off by KonaBess on "old 888 firmware" in commit https://github.com/xzr467706992/KonaBess/commit/e12afa47c7255e5ce1d33d97700479f67449ff89 - I presume the K40 Pro Plus supports it as it has an 888+ qcom,speed-bin = <1> defined at 900mhz on the LEVEL_TURBO_L2 regulator in the file lahaina-gpu-v2.dtsi, while Mi11 code does not have this regulator defined in the file: qcom,rpmh-regulator-levels.h) NOTE: get fastboot up on your PC before you mess with any of these regulators, you'll need it! You'll be fastboot flashing vendor_boot.img a lot. The device is already super OC'd by Qualcomm stock. That's why 888's throttle so much. Now that may be GPU or CPU related, we don't know yet. This will give us some idea. Watch temps wisely:
LEVEL_TURBO_L2
LEVEL_SUPER_TURBO
LEVEL_SUPER_TURBO_NO_CPR (okay this regulator sounds scary - CPR is used to bring someone's heart back to life after it stops beating... use with EXTREME CAUTION. My guess is it turns off all overheating protection)
My K40 Pro Plus is packed up for resale, start a conversation with me if interested ($620 USD basically Mint condition + S&H, extra rugged case + cam lens tempered glass, no markup @ China price, Xiaomi.EU stable 12.5.3 rooted with Magisk Stable and has Vanced (YouTube and Music no ads), Netflix L1, Amazon US, AdAway, all Google Services and apps like Calendar, Contacts, Messages, Chome, Discovery, Lens, GPay always worked when I used the phone before, etc. just login to your Google account and everything will auto-setup). A guy said he'd buy it from me this Friday if I hold it for $700, we'll see about that. I know it works on T-mobile USA alright LTE (N41 5G IF deployed to your area, its not in Houston, TX yet for me to test) and many EU countries frequency coverage is even better. Start of conversation with me if interested I have loads of pics on other websites. Selling because I can only build so many kernels and I have way too many phones. **I'll delete this portion once sold, not sure if the XDA rules allow me to post it (sorry moderators if I violated a rule, just trying to give a great deal to someone who is looking for an 888, I'm not making ANY money).
Back to the topic at hand. I would begin starting at the 840mhz and switch it to one lower regulator, i.e. switch to TURBO instead, and likely drop the mhz too if it fails to boot. Then repeat the rest the same way (1 level down) but only modify 1 at a time, test, then it's fastboot time if it doesn't support it OR you succeeded (write down the numbers). Then run 3DBench 1 test run first. If that works fine, you can run the stress test for 20m after you're happy with all your new frequencies and see if it runs well (no fragments, no lag, etc). If so, keep it there. You should be able to see any FREQUENCY changes in SmartPack Kernel Manager (free on the Playstore or Github, under GPU menu). You can make up your own clock speeds too. I tried dropping the max clock to 825mhz from 840mhz and it booted fine; the AnTuTu v9.0.5-OB graphics segment was lag free. This is silicon lottery customization BTW, some chips will run better at different frequencies and regulators than others.
I hope you find this post useful, took me A VERY LONG TIME to put it together to simplify the GPU adjustments using KonaBess app. It's easiest to make small changes, remember OC'ing an already OC'd device (straight from QCOM, yes they OC'd it) is not likely to work work well - any OC attempts should be like +5000mhz or +10000 at a time. All 888 phones throttle on the default config when pushed hard enough (i.e. like during a bench / stress test session). Since you are mostly testing graphics, I suggest the 3DMark 20 minute stress test for stability verification. If you underclock the GPU enough, you can probably eliminate throttling while still getting a good bench result, while adding to your screen on time (SOT). Throttle free and fast, with decent battery, and you have a winner.
Although if you want to play with the often randomly changing AnTuTu benchmark, you can do that that a little bit faster. I just think that is used by OEMs to sell phones after using it for so many years, I noticed the version #s started to increment a lot faster as more 888 phones were released. From AnTuTu v9.0.1-OB to v9.0.5-OB scores just randomly seemed to change. Companies like RealMe and Nubia (RedMagic) cheat the bench anyway to give you higher scores that don't mean anything in actual use. 3DMark seems like a more consistent bench. Anyway, regardless of which bench you chooose, mark the first runs at the current settings. Let the phone cool down and close all open apps before benching (5 minutes is a good rule of thumb for all apps to load). For more consistency, turn on airplane mode and turn off bluetooth / nfc / etc. Try to run your benches at the same battery % (have that charger ready).
Please post your findings here and notate your device, the mhz you chose, the regulator you chose, etc. so people can work from your values. As I mentioned, you are testing your silicon lotto ticket here - most chips will differ between one another. Your 888 only has to pass a minimum spec to make it to production. Some are all stars and some barely make the cutoff. That's life, it's okay, they are all fast anyway. Even the worst chip will still be fast.
Feel free to like this post if it helped you out!
Click to expand...
Click to collapse
Many thanks for your contribute. Hope that this community will grow and we'll have TWRP and custom ROM son
It will take some time, but someone in China is likely working on it since Venus (Mi11) TWRP just came out.
mslezak said:
It will take some time, but someone in China is likely working on it since Venus (Mi11) TWRP just came out.
Click to expand...
Click to collapse
BTW it could be out there already if you search Chinese websites, someone just "found" the Mi11 TWRP in Chinese, we have no idea who made it. I'd search for haydn TWRP or K40 Pro TWRP and see where it gets you ...
mslezak said:
BTW it could be out there already if you search Chinese websites, someone just "found" the Mi11 TWRP in Chinese, we have no idea who made it. I'd search for haydn TWRP or K40 Pro TWRP and see where it gets you ...
Click to expand...
Click to collapse
Wow, really looking forward to this. I'll keep an eye out. As far as i know there're a TWRP for alioth. Soon be haydn.
Can you port ROM for this devices. I'm trying to learn but there're no up to day document for me to start
makiothekid said:
Wow, really looking forward to this. I'll keep an eye out. As far as i know there're a TWRP for alioth. Soon be haydn.
Can you port ROM for this devices. I'm trying to learn but there're no up to day document for me to start
Click to expand...
Click to collapse
Someone needs to make the kernel first, AOSP, which will be a challenge. I have never done it.
awesome - thanks very much for your efforts!
I have set 840MHz to Turbo and 768 on Nom_L3.
The phone is booting fine.
So is there any way to know if the settings are applied?
Kernel manager shows power level 9.
And clock reaches 840 fine during tests.
I applied with the flash option in konaBess.
11x pro
Going to try this now!
I also started to undervolting the Snapdragon 888 GPU. I'm on xiaomi.eu weekly ROM.
I cannot use any Benchmark/stresstest app because of the Xiaomi block. Can someone help me please, how to use 3DMark or something like that on a xiaomi.eu ROM?
Since a week I'm using the following values. It seems to be stable including gaming.
Kernel manager shows power level 10 (because of adding custom freq?) and i need to set max. freq to 840 MHz on boot in kernel manager.
Here are my first results:
Voltage LevelDefault Frequency (MHz)UV Frequency (MHz)NotesLEVEL_RETENTION--not available on haydnLEVEL_MIN_SVS--LEVEL_LOW_SVS_D1-150added 1 of max. 1 custom FrequencyLEVEL_LOW_SVS315315LEVEL_LOW_SVS_L1379379LEVEL_LOW_SVS_L2-443LEVEL_SVS443491LEVEL_SVS_L0491540LEVEL_SVS_L1540608LEVEL_SVS_L2608676LEVEL_NOM676738LEVEL_NOM_L1738-LEVEL_NOM_L2-778LEVEL_NOM_L3--not mentioned in the first postLEVEL_TURBO778800LEVEL_TUBRO_L0--not tried, see note in first postLEVEL_TURBO_L1840-
mslezak said:
https://github.com/xzr467706992/KonaBess/releases/tag/v0.14 is the app that allows us to play with frequency clocks, regulators, etc.
I wrote a post in another thread - How to Guide Redmi K40 Pro ROOT Tools. This is just the instructions so you can get right to it. Make sure you have the fastboot ROM installed (the way Xiaomi.eu is packaged or the MIUI source you used on your phone), or you can export in the KonaBess app to the root SD card and transfer back to your PC. I highly recommend using the most updated FastBoot and ADB tools found here, the guy is religious so go pray to your deity of choosing, or to the earth, wind, fire, whatever the heck you believe in I don't care. https://forum.xda-developers.com/t/...sb-driver-installer-tool-for-windows.3999445/ thanks bro for that tool.
****** SO HERE ARE THE INSTRUCTIONS SO YOU CAN GET MODDING!!!! *******
Just FYI, most people don't know what I'm talking about when I say "voltage regulators for the GPU." The goal here is to use the first one on the top of the list (top is lowest voltage, bottom is highest) that can support the frequency your GPU Mhz are defined at. As you go up a regulator, the voltage increases, which leads to more power usage and hotter temperatures. Note that I played with it a little bit, and it DOES NOT seem to allow large changes in frequencies (higher that is, without upping the regulator*** you may not be able to use the higher regulators because of a commit I found in KonaBess (noted later). So it's usefulness may be not as great as I had hoped on the OC side, the throttling side, yes this could be invaluable.
If it doesn't boot, ensure you have your fastboot ROM downloaded somewhere (or use the program, it will extract vendor_boot.img to the root directory for you, save off to your PC where fastboot is located as you'll have to use PWR+Volume Down to go to fastboot, then reinstall the original vendor_boot.img (the new format saves this info in this new partition) by typing:
fastboot flash vendor_boot vendor_boot.img
fastboot reboot
Now this tool looks great for underclocking. I booted at 295mhz low and 825mhz high without changing the voltage regulators. But note the program seems a bit buggy - it will (sometimes) drop the max clock when you change it, so you MAY need a kernel manager like SmartPack to set on boot the max clock speed. At least until the code is fixed. I was able to boot on a lower regulator at 150mhz BTW [LEVEL_LOW_SVS_D1], and I didn't notice any performance difference! Just watch out for dropped frames, which can happen if your spacing is too far apart, or your frequency clock not giving enough juice. This can be done just viewing the screen - set it how you like it - power hungry or power friendly or mix and match.
These are the GPU Voltage Regulator Names (extracted from Linux 5.6.41 K40 Pro Plus / Mi11i source, codenamed haydn), listed from lowest voltage to highest. You have 10 choices I believe (regulator 0 is always the max frequency, regulator 9 is the lowest frequency):
LEVEL_RETENTION (so low it may not display anything)
LEVEL_MIN_SVS
LEVEL_LOW_SVS_D1 (note: I got it to boot at 150mhz on this regulator)
LEVEL_LOW_SVS default for 315000000 (315mhz) [REGULATOR 9 STOCK]
LEVEL_LOW_SVS_L1 default for 379000000 (379mhz)
LEVEL_LOW_SVS_L2
LEVEL_SVS default for 443000000 (443mhz)
LEVEL_SVS_L0 default for 491000000 (490mhz)
LEVEL_SVS_L1 default for 540000000 (540mhz)
LEVEL_SVS_L2 default for 608000000 (608mhz)
LEVEL_NOM default for 676000000 (676mhz)
LEVEL_NOM_L1 default for 738000000 (738mhz)
LEVEL_NOM_L2
LEVEL_TURBO default for 778000000 (778mhz)
**LEVEL_TUBRO_L0 -> added by KonaBess, not sure you can actually use it as it would require a kernel modification
LEVEL_TURBO_L1 default for 840000000 (840mhz) [REGULATOR 0 STOCK]
The levels below are turned off by KonaBess on "old 888 firmware" in commit https://github.com/xzr467706992/KonaBess/commit/e12afa47c7255e5ce1d33d97700479f67449ff89 - I presume the K40 Pro Plus supports it as it has an 888+ qcom,speed-bin = <1> defined at 900mhz on the LEVEL_TURBO_L2 regulator in the file lahaina-gpu-v2.dtsi, while Mi11 code does not have this regulator defined in the file: qcom,rpmh-regulator-levels.h) NOTE: get fastboot up on your PC before you mess with any of these regulators, you'll need it! You'll be fastboot flashing vendor_boot.img a lot. The device is already super OC'd by Qualcomm stock. That's why 888's throttle so much. Now that may be GPU or CPU related, we don't know yet. This will give us some idea. Watch temps wisely:
LEVEL_TURBO_L2
LEVEL_SUPER_TURBO
LEVEL_SUPER_TURBO_NO_CPR (okay this regulator sounds scary - CPR is used to bring someone's heart back to life after it stops beating... use with EXTREME CAUTION. My guess is it turns off all overheating protection)
My K40 Pro Plus is packed up for resale, start a conversation with me if interested ($620 USD basically Mint condition + S&H, extra rugged case + cam lens tempered glass, no markup @ China price, Xiaomi.EU stable 12.5.3 rooted with Magisk Stable and has Vanced (YouTube and Music no ads), Netflix L1, Amazon US, AdAway, all Google Services and apps like Calendar, Contacts, Messages, Chome, Discovery, Lens, GPay always worked when I used the phone before, etc. just login to your Google account and everything will auto-setup). A guy said he'd buy it from me this Friday if I hold it for $700, we'll see about that. I know it works on T-mobile USA alright LTE (N41 5G IF deployed to your area, its not in Houston, TX yet for me to test) and many EU countries frequency coverage is even better. Start of conversation with me if interested I have loads of pics on other websites. Selling because I can only build so many kernels and I have way too many phones. **I'll delete this portion once sold, not sure if the XDA rules allow me to post it (sorry moderators if I violated a rule, just trying to give a great deal to someone who is looking for an 888, I'm not making ANY money).
Back to the topic at hand. I would begin starting at the 840mhz and switch it to one lower regulator, i.e. switch to TURBO instead, and likely drop the mhz too if it fails to boot. Then repeat the rest the same way (1 level down) but only modify 1 at a time, test, then it's fastboot time if it doesn't support it OR you succeeded (write down the numbers). Then run 3DBench 1 test run first. If that works fine, you can run the stress test for 20m after you're happy with all your new frequencies and see if it runs well (no fragments, no lag, etc). If so, keep it there. You should be able to see any FREQUENCY changes in SmartPack Kernel Manager (free on the Playstore or Github, under GPU menu). You can make up your own clock speeds too. I tried dropping the max clock to 825mhz from 840mhz and it booted fine; the AnTuTu v9.0.5-OB graphics segment was lag free. This is silicon lottery customization BTW, some chips will run better at different frequencies and regulators than others.
I hope you find this post useful, took me A VERY LONG TIME to put it together to simplify the GPU adjustments using KonaBess app. It's easiest to make small changes, remember OC'ing an already OC'd device (straight from QCOM, yes they OC'd it) is not likely to work work well - any OC attempts should be like +5000mhz or +10000 at a time. All 888 phones throttle on the default config when pushed hard enough (i.e. like during a bench / stress test session). Since you are mostly testing graphics, I suggest the 3DMark 20 minute stress test for stability verification. If you underclock the GPU enough, you can probably eliminate throttling while still getting a good bench result, while adding to your screen on time (SOT). Throttle free and fast, with decent battery, and you have a winner.
Although if you want to play with the often randomly changing AnTuTu benchmark, you can do that that a little bit faster. I just think that is used by OEMs to sell phones after using it for so many years, I noticed the version #s started to increment a lot faster as more 888 phones were released. From AnTuTu v9.0.1-OB to v9.0.5-OB scores just randomly seemed to change. Companies like RealMe and Nubia (RedMagic) cheat the bench anyway to give you higher scores that don't mean anything in actual use. 3DMark seems like a more consistent bench. Anyway, regardless of which bench you chooose, mark the first runs at the current settings. Let the phone cool down and close all open apps before benching (5 minutes is a good rule of thumb for all apps to load). For more consistency, turn on airplane mode and turn off bluetooth / nfc / etc. Try to run your benches at the same battery % (have that charger ready).
Please post your findings here and notate your device, the mhz you chose, the regulator you chose, etc. so people can work from your values. As I mentioned, you are testing your silicon lotto ticket here - most chips will differ between one another. Your 888 only has to pass a minimum spec to make it to production. Some are all stars and some barely make the cutoff. That's life, it's okay, they are all fast anyway. Even the worst chip will still be fast.
Feel free to like this post if it helped you out!
Click to expand...
Click to collapse
How do I extract vendor_boot.img directly from the phone? I have op9pro and can't find the rom version I have installed, and konabess seems to extract boot.img
Unfortunately, this doesn't work for the Mi 11X Pro. Doesn't it support phones with the Snapdragon 888 chipset?