Related
Current android versions:
CM7.2
Kernel Status:
- Kernel v3.10
- LCD
- Keyboard
- SDHC MMC
- Max1587a
- Asic3 Buttons
- Automatic screen rotation
- Touchscreen
- Bluetooth (audio and mouse tested and working)
- Usb host (supports everything USB 1.1 compliant)
- Backlight
- Adb and Usb mass storage
- M24C08 Eeprom
- Keyboard and button backlights
- RTC8564
- Led's - Red, Green, Blue
- Vibrate
- AC Charging
- USB Charging
- WIFI
- Support for EXT4 filesystems
- Modem
- Phone Support
- Audio Support - no input from mics, routing related.
- Data -3g or GPRS
- Power Management - Standby works which is a low power state, Deep sleep and suspend to mem is not working
- DOC flash chips are supported by kernel for both g3 and g4 devices
Not Working/To-do list::
- Camera's - need to add V4L driver to android and dual cam support for camera app and kernel driver.
- add video/audio decoders/encoders
- add modem sound routing to kernel or android (AT commands )
Link to files: (Link)
Link to Kernel source: (Link)
WOW i'll try it. Thanks
Thanks notime!
Not a Universal owner, but glad to see Android made it's way to this device.
Is there any software that can assist to create the 3 partitions?
is anyone working on getting the touchscreen going? if it had touchscreen working i'd jump on this in a hot second.
Now this is so cool, that somebody is actually developing android 4 our beloved Uni :-D:-D:-D
Hi
For me it's not working.
I wrote it here
Here is my LOG
EDIT: It's working. I had the phone off.
Android version
Hi,
first of all - great work!
Second - this will probably be a seen as a stupid question but why are you trying this with such an old version of Android? Are the new versions requiring so much more memory or something?
Anyhow, good luck with further work and thanks for restoring my hopes of Uni resurrection
asdafer said:
Hi,
first of all - great work!
Second - this will probably be a seen as a stupid question but why are you trying this with such an old version of Android? Are the new versions requiring so much more memory or something?
Anyhow, good luck with further work and thanks for restoring my hopes of Uni resurrection
Click to expand...
Click to collapse
That is a good question..., it was the only one i had on hand at the time. But the kernel i'm using is based off 2.6.32.9 the current android 2.1 eclair is based off 2.6.29 so theoretically that and the newer android version froyo should work. If i find or build a 2.1 rootfs that works i will post it.
id say any android functioning on the uni is a giant step in the right direction. we don't need to get picky lmfao
Hi Notimer,
is there any software which can allow me to partition my SD card?
yes. knoppix and fdisk.
Touchscreen
Does anybody know what this ts_calibrate output means or familar with it?
xres = 480, yres = 640
Took 1 samples...
Top left : X = 65492 Y = 678
Took 1 samples...
Top right : X = 65494 Y = 678
Took 1 samples...
Bot right : X = 65492 Y = 678
Took 2 samples...
Bot left : X = 65493 Y = 678
Took 2 samples...
Center : X = 65493 Y = 678
256.000000 0.002021 0.125000
256.000000 0.002694 0.250000
Calibration constants: 16777216 132 8192 16777216 176 16384 65536
If you don't feel like dealing with a full linux distro or the command line when partitioning, try the G-partd Live CD. It's a great, Partition Magic style GUI for the Linux command line partition tools.
http://gparted.sourceforge.net/livecd.php
it'd be better if we just had a 128mb dd image methinks. simpler and faster lmfao
Updates
I posted a new kernel and updated the working functions list on the first post. I know it might not be the updates some were wanting but....it's a update i thought was worth posting...but still no touch screen.
Has anyone tried or built any other android rootfs or images to test with this kernel or know how to?
Does anyone know of a device running Linux that has a phone chip similar to the one in the universal?
Can you compile a kernel image that mounts loopback image files instead of actual ext2 partitions for those that don't feel like partitioning their SD cards? I think it would encourage many more testers.
im confused here, titchy linux runs just fine on the universal. why is it we dont harvest drivers from that?
I think that some devs already knew this and they are working on this, but I cannot understand why they didn't tell this to other devs.
download HTC desirec_2.6.29 kernel sources here:
http://developer.htc.com/ , if you couldn't see it, use tor or some other proxy software to visit the site.
extract it. look into arch/arm/configs folder.
you will find a file named "0001-Symptom-HeroC-remove-other-project-board-config-fi.patch"
revert this patch, you will get almost all board files. with some minor changes, you could boot the HTC official 2.6.29 kernel on your devices.
what changes? 32A new radio for example:
1. the "EBI1 supports 256MB" is removed, add it or make your changes, a simple modification, at beginning of board-sapphire.h:
#ifndef __ARCH_ARM_MACH_MSM_BOARD_SAPPHIRE_H
#define __ARCH_ARM_MACH_MSM_BOARD_SAPPHIRE_H
#define CONFIG_MSM_AMSS_SUPPORT_256MB_EBI1 //add this line.
2. the freq table for 32A is not added (this is the main reason why you can't boot), edit it in the acpulock-arm11.c:
static struct freq_tbl_map acpu_freq_tbl_list[] = {
/* you do not need to comment out these devices, though they are useless for 32A
TABLE_CONFIG(LEGEND, 7227),
TABLE_CONFIG(LATTE, 7227),
TABLE_CONFIG(LIBERTY, 7227),
TABLE_CONFIG(BAHAMAS, 72xx),
TABLE_CONFIG(MEMPHIS, 72xx),
TABLE_CONFIG(PARADISE, 72xx),
TABLE_CONFIG(HERO, 72xx),
TABLE_CONFIG(HEROC, 72xx),
TABLE_CONFIG(DESIREC, 72xx),
*/
TABLE_CONFIG(SAPPHIRE, 72xx), //our device
{ 0, 0, 0}
};
3. touchscreen data for elan hardware is not correct. but our 32A phone don't use it. comment out these things in board-sapphire.c:
/* comment out this
static struct elan_i2c_platform_data elan_i2c_data[] = {
{
.version = 0x104,
.abs_x_min = 0,
.abs_y_min = 0,
.intr_gpio = SAPPHIRE_GPIO_TP_ATT_N,
.power = sapphire_ts_power,
.display_width = 320, //me
.display_height = 480, //me
},
{
.version = 0x103,
.abs_x_min = 0,
.abs_x_max = 512 * 2,
.abs_y_min = 0,
.abs_y_max = 896 * 2,
.intr_gpio = SAPPHIRE_GPIO_TP_ATT_N,
.power = sapphire_ts_power,
.display_width = 320, //me
.display_height = 480, //me
},
{
.version = 0x102,
.abs_x_min = 0,
.abs_x_max = 384,
.abs_y_min = 0,
.abs_y_max = 576,
.intr_gpio = SAPPHIRE_GPIO_TP_ATT_N,
.power = sapphire_ts_power,
.display_width = 320, //me
.display_height = 480, //me
},
{
.version = 0x101,
.abs_x_min = 32 + 1,
.abs_x_max = 352 - 1,
.abs_y_min = 32 + 1,
.abs_y_max = 544 - 1,
.intr_gpio = SAPPHIRE_GPIO_TP_ATT_N,
.power = sapphire_ts_power,
.display_width = 320, // or you could just comment out these fields (in all structs in this array)
.display_height = 480, // in this case, you don't need to comment out all elan things.
}
};
*/
static struct i2c_board_info i2c_devices[] = {
{
I2C_BOARD_INFO(SYNAPTICS_I2C_RMI_NAME, 0x20),
.platform_data = sapphire_ts_data,
.irq = SAPPHIRE_GPIO_TO_INT(SAPPHIRE_GPIO_TP_ATT_N)
},
/* comment out this, if you disabled the entire elan data array.
{
I2C_BOARD_INFO(ELAN_8232_I2C_NAME, 0x10),
.platform_data = &elan_i2c_data,
.irq = SAPPHIRE_GPIO_TO_INT(SAPPHIRE_GPIO_TP_ATT_N),
},
*/
{
I2C_BOARD_INFO("akm8976", 0x1C),
.platform_data = &compass_platform_data,
.irq = SAPPHIRE_GPIO_TO_INT(SAPPHIRE_GPIO_COMPASS_IRQ),
},
};
maybe there are other modifications to be needed by compiling the kernel, but they could be found easily, just follow the output by your compiler.
I remembered that with only these changes, the kernel could be compiled, the device could be booted, and all things were working fine except the color of the screen is not correct(for this problem, we could get right settings from htc-kernel-2.6.27 for sapp and hero).
I am under Windows now so I can't make a patch which would work directly. but with the original leaked patch, I think that it is not difficult to make things right by yourselves.
Great news Sanpei. Now maybe our android 2.1 will work better on new radio.
Thats more than great news What can we say more ? Thank U for that But there are not many devs who wants to play with kernels for Magic ;P You were the only one Hope one day U`ll bring us good .29 to live Cheers !
And it only took you about six months to share this info with others. How great...
Nevertheless, thanks.
Case_ at least he is sharing it now
sanpei I'm working off HeroC source:
http://github.com/toastcfh/CdMa-HeRoC-2.6.29/
The correct changes were made in board-sapphire files already. Might be other stuff.
All devs need is to add the EBI1 config!
there are additional mods sanpei has not mentioned. maybe that's why his kernels have been a little finicky. but this is probably it: http://github.com/cyanogen/cm-kernel/commit/fef60feb4caa22d82a35636b1679243e67512ce5#L7L160
CPU freq tablets already fully support our CPU there. Overclock should work as well.
As for eflan, I'll have to play with it
toastcfh sent me a compile last night with board files added, but I think there was still some stuff missing, but...
EBI1 was why my device didn't boot! Going to compile that and see what happens now!
As for him not sharing it, at least he is sharing it now.
Thanks sanpei my fellow countryman
I feel dumb for compiling the source when the board files wheren't even there. I don't know if this is all I needed to do but this is a big step in the right direction. I have no knowledge of how stuff like this works. I am not a dev still.
sanpei I wish I had better understanding of all this code. But I don't. In any case thanks for sharing this with us now.
the only two reasons i didnt make the patch public is one because of the EVO (superconic) source in it, second in hopes that it wouldnt be the last mess up by HTC. the source has ony been up for 3 or 4 weeks. so the 6 months idk. i released the source as i got it to compile. i had other projects also like making source for the CDMA heroc. which oddly enough the patch says heroc on it :/ but lacks source for our device. as soon as i finished the heroc project of creating board files compatible with the heroc, i moved on to commitig the board files for the other devices. starting with the GSM hero (which was unfinished) and then the Sapphire (also unfinished). all know devices have been commited and someone at least informed of the files being there. im a busy person and have a life of my own. the patch did me no good while i was creating board files for the CDMA hero. once i finished that i turned my attention to releasing the rest of the devices. but yeah i doubt HTC will make this mistake again for sure now that its publicly announced.
so yeah i only was trying to protect a interest that everyone can gain from.
interesting none the less...
first try didn't go (defined ebi1 in .h file, compiled and flashed)
i'm giving it another last chance, this time defining ebi1 in the kconfig.
i might be missing more stuff than this.
edit: I'm blind. didnt' edit acpuclock properly. lol. doing another compile.
for the color issues look into ur panel settings. its most likely the reason the color is messed up. maybe wrong settings
Holy **** it's booting
Colors look okay actually. My touchscreen is broked though!
Cursorsense too lol
BUTTONS ALL OKAY
sounds interesting lets see what you get fixed
I'm hoping you can get it to work properly, good luck mate, crossed fingers !
All you need to start with to get 2.1 roms working
Not all of sanpei's changes are needed to fix what is on toastcfh's github.
My .config is still messed I bet.
In Cursorsense pretty much everything is broken.
http://www.youtube.com/watch?v=lasToRLQQCA&feature=player_embedded
I HAVE A BOOTSCREEN ON AHERO
For devs, if you are working off toastcfh's github source, this is what you need to get it working:
a)
acpuclockarm11.c sanpei mentioned
edit it in the acpulock-arm11.c:
static struct freq_tbl_map acpu_freq_tbl_list[] = {
/* you do not need to comment out these devices, though they are useless for 32A
TABLE_CONFIG(LEGEND, 7227),
TABLE_CONFIG(LATTE, 7227),
TABLE_CONFIG(LIBERTY, 7227),
TABLE_CONFIG(BAHAMAS, 72xx),
TABLE_CONFIG(MEMPHIS, 72xx),
TABLE_CONFIG(PARADISE, 72xx),
TABLE_CONFIG(HERO, 72xx),
TABLE_CONFIG(HEROC, 72xx),
TABLE_CONFIG(DESIREC, 72xx),
*/
TABLE_CONFIG(SAPPHIRE, 72xx), //our device
{ 0, 0, 0}
};
Click to expand...
Click to collapse
b) touchscreen fix by using the aosp synaptics driver here (rename this file)
http://github.com/toastcfh/CdMa-HeRoC-2.6.29/tree/master/drivers/input/touchscreen/
synaptics_i2c_rmi.c-AOSP-fix -> synaptics_i2c_rmi.c
c)
make changes to 'Kconfig' here, and enabled the config option during make
http://github.com/cyanogen/cm-kernel/commit/fef60feb4caa22d82a35636b1679243e67512ce5
The board files that are up work perfectly.
d) work off my config or similar:
http://pastebin.com/cKkBNtKJ
e) download aHero for GSM Hero here:
http://forum.xda-developers.com/showthread.php?t=638584
e) PROFIT
note that all apps are force-closing on aHero right now. but launcher works. boot screen works. radio works.
I will play with this later. For now I need a working phone.
Did a wipe. Most apps work. Random stuff is broken but that's okay.
But I talked to zinx in irc. He said CM-Kernel actually already supports new radio Magics.
commited the changes above to alow the sapphire to boot
github.com/toastcfh
It boots but the drivers are broked. I messed up my source and don't want to touch it for a while.
Sanpei?
Case_ said:
And it only took you about six months to share this info with others. How great...
Nevertheless, thanks.
Click to expand...
Click to collapse
do you know when the desirec_2.6.29 had been released? or, do you think that I was a time traveler?
I found this leaked patch 1~2 weeks ago. I was working on my career jobs these days (I even didn't have time to visit here), and I thought that others would find it and share with each other, so I didn't post it immediately.
yesterday, when I visited here, I found that it was not mentioned by any other people. so I decided to write something.
and hope that it won't surprise you, the .29 and .32 kernel builds made by me are not based on htc-kernels, and I never use any files from HTC. I just made aosp kernel working with our devices.
to put it simply: for 32A device, I don't need any pieces of codes from HTC, I just need the information about radio versions and interfaces between hardware and software, and I already know/understand some of them.
to be honest, I never change my mind. I won't open "my" sources before I would have considered that they could be open.
but this patch, it is leaked from HTC's sources and I don't make any efforts on it. so I think that if I shared this information, all of you will get what you want, and it is not conflict with my "moral standards" what I had mentioned in previous arguments.
maybe you and others think that I am a selfish man or bad person. I don't care. take what you want, and leave me alone.
but if you and others could reconsider what I am, and think about if I could be a friend of you, I will be very happy.
Oh but we (I) did make a thread. It should be on the 3rd page or so by now. This ROM is flooded by rom ports and has zero dev activity. There's just hopelessly few devs on Sapphire forums. That's why all you see see are ports and no AOSP stuff.
But since you have a .3X kernel anyways I don't see you really needing this. Toastcfh did remind me to replace the synaptic touchscreen driver to get it working properly for the Sapphire.
Or we could use your source. Because I have no idea what I need to do to fix wifi and camera on my port. I have CM5 working with sound, rotation, sleep, Youtube, 3D on a 32A Magic. It's not my phone though so I wont try much more on it now.
I first booted into Cursorsense, then aHero and finally Cyanogenmod 5. CM5 as a ***** because squash fs didn't compile, so it broke my xbin completely. I worked around it by extracting xbin through my virtual machine since my PC runs windows before I realized I can just install busybox from the recovery onto the phone. I pushed the lib*camera*.so files from aHero and after data wipe I had ZERO force closes, bluetooth + audio + video + rotation. Not bad for a noob, but I have no idea how to fix. This isn't my career path
toastcfh helped me a lot
Question
Doesn't it make more sense to get Cyanogen's kernel source working? All it needs is AMSS 6355 support, and the code difference doesn't seem to be that great. It already has up to AMSS6350 the last time I checked. It's actually not that bad to add new phones, but their kernel source is kind of different than HTC's now that it's now harder to just add new phones. zinx expressed interest, and I'm sure bcrook is interested as well.
We can use a plain HTC source and adapt it, but CM already should have a lot of 32a bits in it including native EBi1 support, compatible makefiles and a kernel version ready to boot any 2.1 rom.
The major differences between the AMSS versions 6350 and 6355 seem to be in the multimedia msm drivers. That's probably less than 10 files to edit in total.
The existing CM5 config should build new radio 32As no problem.
But is there a point anymore? Sanpei your kernel seems pretty darn stable right now. If I figure out how to throw it in Koush Anykernel we can probably have working ports for every ROM out there. The only thing is since you have source code sometimes the local version doesn't work well with some ROMs. So yes we still want your source because it works well.
xaueious said:
Oh but we (I) did make a thread. It should be on the 3rd page or so by now. This ROM is flooded by rom ports and has zero dev activity. There's just hopelessly few devs on Sapphire forums. That's why all you see see are ports and no AOSP stuff.
But since you have a .3X kernel anyways I don't see you really needing this. Toastcfh did remind me to replace the synaptic touchscreen driver to get it working properly for the Sapphire.
Or we could use your source. Because I have no idea what I need to do to fix wifi and camera on my port. I have CM5 working with sound, rotation, sleep, Youtube, 3D on a 32A Magic. It's not my phone though so I wont try much more on it now.
I first booted into Cursorsense, then aHero and finally Cyanogenmod 5. CM5 as a ***** because squash fs didn't compile, so it broke my xbin completely. I worked around it by extracting xbin through my virtual machine since my PC runs windows before I realized I can just install busybox from the recovery onto the phone. I pushed the lib*camera*.so files from aHero and after data wipe I had ZERO force closes, bluetooth + audio + video + rotation. Not bad for a noob, but I have no idea how to fix. This isn't my career path
toastcfh helped me a lot
Question
Doesn't it make more sense to get Cyanogen's kernel source working? All it needs is AMSS 6355 support, and the code difference doesn't seem to be that great. It already has up to AMSS6350 the last time I checked. It's actually not that bad to add new phones, but their kernel source is kind of different than HTC's now that it's now harder to just add new phones. zinx expressed interest, and I'm sure bcrook is interested as well.
We can use a plain HTC source and adapt it, but CM already should have a lot of 32a bits in it including native EBi1 support, compatible makefiles and a kernel version ready to boot any 2.1 rom.
The major differences between the AMSS versions 6350 and 6355 seem to be in the multimedia msm drivers. That's probably less than 10 files to edit in total.
The existing CM5 config should build new radio 32As no problem.
But is there a point anymore? Sanpei your kernel seems pretty darn stable right now. If I figure out how to throw it in Koush Anykernel we can probably have working ports for every ROM out there. The only thing is since you have source code sometimes the local version doesn't work well with some ROMs. So yes we still want your source because it works well.
Click to expand...
Click to collapse
no, it is not that "my" kernel works well, it is the original aosp kernel works well, except some minor bugs (which are already fixed in my kernel build). and I think that .32 is more suitable than .33, since .33 is marked as experimental by Google.
some "custom" mods of .33 use older drivers which are taken from kernel sources of an older version. I can't sure if these drivers could work properly with new radio, though you could boot your device and most features will works.
and sorry, I don't want to talk about other's works. but I must repeat again: all "custom" kernels are just original kernels from Google/Qualcomm/HTC's repo, and with little public patches made by some real programmers.
so don't care about their brands. you should find out what they are using: drivers, hacks, and patches of features.
if you use a lib (in userspace or android layer) because it is necessary for a radio version (because the lib and the radio have some conventions directly), then you should choose the kernel driver which could work with this lib. KERNEL itself is NOT the KEY problem in this case.
in fact, the most programming jobs I had done are in android layer; and if I have spare time, what I would work on are in android layer too. (except OC or other things which do most things in the kernel).
for devs who don't have enough experiences in kernel jobs or programming, and if they want a most stable kernel which would works with new radio, I recommend them start from htc-kernel. it's always more reliable, because we (I, you and others) can't know every changes of hardware configurations between each radio versions, and HTC knows these things exactly.
but why I would still be working on .32 kernel?
because I think that I could fix every bugs (if we would encounter) by myself , and I want to learn and remember the new changes Google made in kernel. thus, I wouldn't need to learn these things again when newer versions of android (they might need these changes in kernel) will be coming.
a kernel and some libs for new radio, and they could work with both AOSP and HTC ROMs, it's my current goal. and you could see giant's work on AOSP ROM, I think that we are more close to this goal now.
"my" sources..., I will think about it (and I often considered if it's the time). but I am rather obstinate
and for problems of using htc-kernel, I can't remember all the details of my tweaks and tests. maybe I will take a look for you. but I won't make any promise, since I really don't have enough time at current.
Here is a slightly separate but related thought.
It seems to me (and I am the first to admit I am not knowledgeable in this stuff so I could be wrong) that one of the following statements are true regarding the devs working on the G1 and other phones:
(1) Either they are not very knowledgeable when it comes to kernel programming and development (and so they are not capable of getting a kernel working on the 32a like Sanpei did), or
(2) The other devs are not interested about the 32a user community enough to spend their time providing us with support (and so they do not focus their time getting a kernel working on the 32a).
My guess is that it is a combination of the two possibilities above. Devs are not as knowledgeable as we think when it comes to kernel development and the required changes HTC and qualcomm do to get a kernel working on different phones especially the 32a, and even if they could do some reverse engineering and some hacking that they don't want to spend the time and energy supporting the 32a user community which is probably a lot smaller than the 32b community. (I don't fault anyone for not wanting to support a community - it takes time and there is probably very little financial reward.)
I believe the lack of a working new radio kernel for 32a supports Sanpei's view that other devs should not be branding the kernel with their names after they have done some minor tweaks. I believe that anyone capable of doing major work on a kernel worth re-branding the kernel to their own name would have already been able to get it working on the 32a properly.
But what do I know.
Lastly, I don't mean to disrespect any dev with these views. All of the devs have contributed - big or small - to the user experience and all devs have done a lot more than I will or could ever do to support Android. However, I do think we should be honest about what we can and can't do and what we take credit for.
It is also interesting....
(1) How xaueious has good things to say about "Sanpei's" kernel
(2) How Sanpei refuses to call it his kernel, or to take credit for the 6.35 .32 kernel, and how Sanpei actually plays down or belittles what he had to do to get the .32 kernel working on the new radio (something which no one else has done), and
(3) How guys like Alan who know very little about kernel development choose to criticise the .32 new radio kernel ported by Sanpei, going so far to call it "garbage"
All of these things point to people's approach and character.
As I cannot find any related guide while google-ing, I want to post this question on here for the purpose of learning and probably helping other people.
[Q1] How to overclock a kernel
which files are needed -> kernel source .. ?
what files need to be edited ?
is the cpufreq driver related ?
how to determine which frequencies need higher voltage and how high exactly ?
[Q2] Undervolting
which files are needed -> kernel source .. ?
what files need to be edited ?
is the cpufreq driver related ?
how to determine which frequencies can use lowered voltage and how to calculate them ?
I would be very thankful if any developer could teach me (probably others too) and I will contribute back for sure.
I am right now fixing up bugs in TeamGummy rom, and I'm nearly finished.
Only thing I lack is a custom kernel, which I want to build myself along with the rom.
*push*
Watch out guys, master guevor is going to teach us a little of his enormous knowlegde, so better keep your eyes on this one.
Overclocking
I must say that all I'm going to write, is what I've gathered looking at the code and changes made by others (thanks Blades and Roach2010) (I have not had any documentation about it), so I could make mistakes or misinterpretation.
Nor do I explain everything, because if you do not have a minimal knowledge get to play this directly may be dangerous.
(Q1) Overclocking
Files to modify
arch/arm/mach-tegra/tegra2_clocks.c (All matters relating to the frequencies.)
The system uses a series of programmed pll clocks which in turn can be used as a basis to other clocks. Let's say for this case pll_x is used for the base of processor clock.
The frequency table are in tegra_pll_x_freq_table processor. Seeing the type definition clk_pll_freq_table in clock.h we know that has entries consisting of 6 values. (input_rate, output_rate, n, m, p, cpcon)
These values allow tegra2_pll_clk_set_rate function to set the pll frequency.
The values of interest are the frequency of input and output that indicates the input frequency base to be used and what frequency we want to set (it will use the frequency corresponding to the current base and the output frequency we want). m * p values give us the divisor and n is the multiplier. For simplicity we say that n/(m*p) will give us the multiplier, which applied to the base frequency will give the target frequency.
So if we want to add new frequencies, we must add entries in this structure (tegra_pll_x_freq_table) so the system knows how to program a frequency we want to use.
Add 4 entries for each frequency we want to add (one for each base frequency: 12000000,13000000,19200000,26000000 in our case), with multipliers/dividers to calculate the frequency for which we are adding.
If we add higher frequencies than at present, we have to change the maximum (max_rate) in the tegra_clk_virtual_cpu and tegra_clk_cclk structures, otherwise the system will ignore it. Also have to change the limits for our type of processor in sku_limits. For this case the cpu, cclk y pll_x in the values for our processor (0x04, 0x08, 0x0F).
Finally we modify the table of frequencies used by the processor (frequency list and their order). Is defined at cpufreq_tables and contains a list of lists where we can add a new list or not to touch anything and modify an existing list.
We can look at the existing list freq_table_1p2GHz or in my source I added the list freq_table_1p7GHz.
Contains a list of frequencies that the system can select. It uses the list whose maximum corresponds to the maximum indicated above.
arch/arm/mach-tegra/tegra2_dvfs.c (Everything related to the voltages and its relationship with the frequencies.)
This part is much more sensitive and therefore can affect much to the duration of the battery as to stability. I have no formula (unfortunately for me) on how to modify the values, so the task has been more trial and error.
The first thing to know is that one must distinguish between the core voltage and the cpu and should be the latter inferior to the first. In tegra2_dvfs_rel_vdd_cpu_vdd_core function establishes the relationship between the two, being the default 120mV core above the cpu.
Basically what we do if we have added frequencies higher than normal, is to increase the voltage so that they are stable (depend on each processor). I recommend (at first) increment in the same extent all the values involved (maximum voltage).
Therefore we can modify:
Table core_millivolts, establishing the voltages that core can use.
Table cpu_millivolts, establishing the voltages that cpu can use. It contains all the steps and should take into account the difference with the core discussed earlier. If we added any frequency, we add the corresponding voltages.
Tables core_speedo_nominal_millivolts and cpu_speedo_nominal_millivolts contain a nominal voltage of both the core and the cpu.
The maximum and nominal voltages in structures tegra2_dvfs_rail_vdd_cpu, tegra2_dvfs_rail_vdd_core and tegra2_dvfs_rail_vdd_aon.
Finally we adjust the settings for dvfs_init ("cpu", 1,) according to the list of frequencies we want to use (adding if we added new frequencies or changing them if changed change some)
With these changes we should be able to overclock, although we know that although you can configure (once started) a maximum frequency below the maximum that we put on the tables, there is a problem and many times after suspending the system will use the maximum frequency of the table. To avoid this we must make some changes in cpufreq.c
drivers/cpufreq/cpufreq.c
The problem occurs in the second core when reconnected after being disconnected in the suspension process. The problem is solved with the next patch.
Code:
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index e157205..2626e2d 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1048,18 +1048,27 @@ static int cpufreq_add_dev(struct sys_device *sys_dev)
/* Set governor before ->init, so that driver could check it */
#ifdef CONFIG_HOTPLUG_CPU
+ struct cpufreq_policy *cp;
for_each_online_cpu(sibling) {
- struct cpufreq_policy *cp = per_cpu(cpufreq_cpu_data, sibling);
+ cp = per_cpu(cpufreq_cpu_data, sibling);
if (cp && cp->governor &&
- (cpumask_test_cpu(cpu, cp->related_cpus))) {
+ (cpumask_test_cpu(cpu, cp->related_cpus))) {
+ dprintk("found sibling CPU, copying policy\n");
policy->governor = cp->governor;
+ policy->min = cp->min;
+ policy->max = cp->max;
+ policy->user_policy.min = cp->user_policy.min;
+ policy->user_policy.max = cp->user_policy.max;
found = 1;
break;
}
}
#endif
if (!found)
+ {
+ dprintk("failed to find sibling CPU, falling back to defaults\n");
policy->governor = CPUFREQ_DEFAULT_GOVERNOR;
+ }
/* call driver. From then on the cpufreq must be able
* to accept all calls to ->verify and ->setpolicy for this CPU
*/
@@ -1071,6 +1080,16 @@ static int cpufreq_add_dev(struct sys_device *sys_dev)
policy->user_policy.min = policy->min;
policy->user_policy.max = policy->max;
+ if (found)
+ {
+ /* Calling the driver can overwrite policy frequencies again */
+ dprintk("Overriding policy max and min with sibling settings\n");
+ policy->min = cp->min;
+ policy->max = cp->max;
+ policy->user_policy.min = cp->user_policy.min;
+ policy->user_policy.max = cp->user_policy.max;
+ }
+
blocking_notifier_call_chain(&cpufreq_policy_notifier_list,
CPUFREQ_START, policy);
Ok, I'm on it. Trying my best, but I'm afraid you have to push me a little..
Facing heavy compile errors.
Question :
In your kernel source dir, which command do you use to start compiling ?
EDIT :
EDIT 2 :
@ all people trying to compile, do NOT use
Code:
make tegra_defconfig
!
Better grab an existing .config file from an already running kernel (thanks to guevor for this)
Just google "cyanogenmod building kernel from source" , it's described well over there.
If people request, I can share the kernel config and the precompiled blob tools once I get them from guevor.
First kernel compiled successfull, I have my zImage ready.
OC'd and Voltages changed.
First test kernel incoming the next days, I could need some testers.
Pm me if you want to test.
Thanks for this! I love your work and you sharing your vast knowledge of this subject! Thanks OP for giving him the means of enlightening us
back from the dead
edited
I was a little sleep deprived... my bad
Necromancy!
Say I want to just simply modify my cpu_max_freq via my stock kernel (no source availabel) and I have the boot.img and have unpacked it to boot.img-kernel. What should I do from here to get into the internals of the kernel to adjust the cpu_max_freq? I'm running an ARM Cortex A9, the same as the Tegra2 cpu per say.
Thanks
1chris89 said:
Say I want to just simply modify my cpu_max_freq via my stock kernel (no source availabel) and I have the boot.img and have unpacked it to boot.img-kernel. What should I do from here to get into the internals of the kernel to adjust the cpu_max_freq? I'm running an ARM Cortex A9, the same as the Tegra2 cpu per say.
Thanks
Click to expand...
Click to collapse
You can't do it that way. You can try to create oc modules but I couldn't tell you how to do that
Sent from my EVO using Tapatalk 2
Can you send me in the right direction?
Looks like unpacking the kernel isn't happening but I can create an overclock module which is FAR from easy but here's something I started on a little not sure if it's specific to the other device or whatever but I'll see how it goes.
http://forum.ppcgeeks.com/android-t...modules-tinboot-nand-boot-more-beginners.html
1chris89 said:
Say I want to just simply modify my cpu_max_freq via my stock kernel (no source availabel) and I have the boot.img and have unpacked it to boot.img-kernel.
Click to expand...
Click to collapse
Since the kernel is under GPL, get the sources from where you got the binary.
1chris89 said:
I'm running an ARM Cortex A9, the same as the Tegra2 cpu per say.
Click to expand...
Click to collapse
Is it a Tegra 2 or not? If not, this thread won't help you.
I don't understand this part:
The values of interest are the frequency of input and output that indicates the input frequency base to be used and what frequency we want to set (it will use the frequency corresponding to the current base and the output frequency we want). m * p values give us the divisor and n is the multiplier. For simplicity we say that n/(m*p) will give us the multiplier, which applied to the base frequency will give the target frequency.
So if we want to add new frequencies, we must add entries in this structure (tegra_pll_x_freq_table) so the system knows how to program a frequency we want to use.
Add 4 entries for each frequency we want to add (one for each base frequency: 12000000,13000000,19200000,26000000 in our case), with multipliers/dividers to calculate the frequency for which we are adding.
Click to expand...
Click to collapse
I want to add new frequencies but I don't get it.. also, why 4 entries for a single frequency? thanks!
Someone pleaseeee?
I hope there's a video tutorial for "adding overclocking features to your kernel", I hate to admit that I can't follow the instructions carefully due to lack of English knowledge
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
for OOS-N, and LOS-N
Code:
/* *** Disclaimer
* I am not responsible for bricked devices, dead SD cards, thermonuclear war,
* or you getting fired because the alarm app failed. Please do some research
* if you have any concerns about features included in this KERNEL
* before flashing it! YOU are choosing to make these modifications, and if
* you point the finger at me for messing up your device, I will laugh at you.
* BOOM goes the Dynamite
*/
I am releasing this kernel because I like to share my work and have had requests to do so and, lastly, because we needed yet another kernel released for our beloved OP3! I started out at XDA because I wanted to learn and share what I have learned. My goal with this kernel is to be a very fast and stable build that offers some things that the other kernels do not. I also want to initiate Development Discussions among the community. This will be a noob friendly thread as long as users follow two rules. First is to do some research before asking. Most likely your question has already been asked. If not in this thread then in another. Remember to always search first! Second is BE RESPECTFUL. You do these two things and even the most hardened Dev will assist you.
Wanna be notified of an Update? Here is my PushBullet Channel!!
https://www.pushbullet.com/channel?tag=renderkernel
Current Features
General List:
* EAS Only
* Built with LINARO 6.x
* Updated with CAF LA.UM.5.5
* IO Scheds - FIOPS, CFQ, BFQ, ROW, DEADLINE, NOOP, and ZEN Schedulers
* Flar Sound Control
* Wake Gestures - DT2W, S2W, and S2S
* Complete Color Calibration Thanks to @savoca
* F2FS Support
* Adrenoboost
* USB Fast Charging
I recommend Kernel Aduitor for making kernel changes
Kernel Downloads:
LOS-(EAS/HMP) Downloads
OOS-(EAS/HMP) Downloads
Instructions:
* Boot into Recovery
* (Recommended) Make a complete backup of everything!
* At least backup BOOT via TWRP
* Flash Zip
* Reboot
THANKS!!!!
First I want to say thank you to everyone who has answered my questions and responded to my pm's when I know they are busy with their own lives. Pretty much everyone I have come into contact with here on XDA has been truly helpful and respectful. Here is a list of people that had helped me in one way or the other:
Neobuddy89, ak, myfluxi, Dorimanx, Savoca, Faux123, DespairFactor and Many More!
Thank you guys! Without your contributions to the community we would not have the level of performance, stability and interaction that we have today
Special Thanks!
Donators: @nfin1te, @MrDarkKV, @V1TRU, @Really now @erad1
Source Links:
https://github.com/RenderBroken/OP3-kernel
https://github.com/RenderBroken/OP3-LOS-kernel
https://github.com/RenderBroken/RenderKernel-AnyKernel2
XDA:DevDB Information
[UNIFIED] Render Kernel [OOS-N-EAS-R2][LOS-N-EAS-R8], ROM for the OnePlus 3
Contributors
RenderBroken, Mostafa Wael, joshuous
ROM OS Version: 7.x Nougat
Version Information
Status: Testing
Created 2016-11-23
Last Updated 2017-12-15
Note:
Great write-up from @Mostafa Wael
HMP vs EAS - OxygenOS 4.1.3 stable
Right here we go!
First things first, this is a comparison between two kernels and NOT just two different scheduling systems. With the latter being undeniably the biggest difference between RenderKernel and the stock kernel, changes can extend to other default settings, should @RenderBroken choose to do so. One of which is the default choice of BFQ I/O scheduler instead of the default CFQ I/O scheduler of stock kernel. If you want to have a quick debrief of what (the current implementation of) EAS is all about, read this post here
MMX Hill Dash
HMP - most of the time the game is mainly operated by the big cluster while the little cluster is mostly at the lower end of the frequency table, hovering around the absolute minimum frequency of 307 MHz for most of the time. The big cluster however was noticeably more active, hovering around 1.25 GHz to 1.55 GHz with rare dips below 1 GHz and slightly more often spikes to 1.7 GHz and above. So to sum up HMP's management of the CPU in this particular game, it is safe to state that the game is more or less solely operated by the big cluster, running mostly on the intermediate frequency steps between 1.25 GHz and 1.55 GHz with occasional spikes to 1.7+ GHz and much scarcer dips to sub 1 GHz. As far as performance goes, there are no major complaints. The game runs incredibly smoothly and the game is loaded in a reasonably quick manner; launching the game takes between 8s and 10s from the get-go.
EAS - It's remarked that all 4 cores are active when playing this game, unlike HMP, with the little cluster spending almost all of the time at the 1.11 GHz step with very rare dips to the minimum frequency. While that may sound like a bummer, there is an upside to the surprisingly increased activity of the little cluster. Apparently the big cores have some of the loaded lifted, since the big cluster is being utilised at noticeably lower frequency steps compared to HMP, staying on the 1.11 GHz frequency step much more often, otherwise roaming between 1.25 GHz and 1.55 GHz with very scarce spikes to the max frequency. Like HMP, the game runs flawlessly with no major complaints and surprisingly the game is loaded just as quick as HMP too, if not a tad quicker sometimes! Crikey!
True Skate
HMP - Both clusters are heavily fluctuating with no predictable trend. However, it is quite noticeable that the big cluster can hit the high end of the frequency table quite often. Little cluster is relatively less active, but it is not that dormant either. With that said, it is no wonder that the game runs silky-smooth. However, there were some instances where the frame rate would suddenly drop to around 40-45 fps for mere seconds, where the cause has been determined to be some background tasks being executed like Play Store checking for whether there are apps need to be updated, and social media apps refreshing in the background. Theoretically such an issue would not exist on EAS due to cleverer tasks placement techniques to avoid overstressing the CPU.
EAS - Both clusters spend most of their time at the 1.11 GHz frequency step, with the big cluster ramping up to the max frequency for a considerable amount of time. With that said, a natural consequence would be witnessing one of the most consistently smooth and fluid gaming sessions of that particular game. And even with lots of background processes taking their toll on the silicon, performance is not hindered by any means.
Browsing via Chrome
HMP - Flinging through the webpage will immediately crank up the big cores to max frequency straight away till the content is loaded. Should there be a video to be buffered, the big cores keep operating at medium high frequencies between 1.25 GHz and max frequency with rare dips to minimum frequency. Once all contents are loaded, the big cores gradually get toned down and caged into the lower end of the frequency table. The little cores on the other hand are not wrestling with the controls surprisingly enough, rather sitting most of the time comfortably at 0.96 GHz to 1.1 GHz, with a considerable amount of time spent on the lowest two frequency steps of 307 MHz and 422 MHz. Scrolling through the webpage is reasonably smooth, though sometimes it tends to be a bit unresponsive and wonky if a lot of interactions were present or a lot of content are being loaded while scrolling. As far as battery backup goes, there is no escape that such a task would sip a lot of juice from that tank. And at 18%/hr, there is a lot to be desired when it comes to efficiency, bearing in mind that such a high active drain rate does not guarantee you a flawless silky-smooth UI.
EAS - Like HMP, flinging through the webpage will engage the big cores fully till the page contents are loaded. However, unlike HMP, the big cores do fade out quite faster when the page contents are loaded successfully. Things get much better when there is a video to be streamed, where the video is mainly handled by the little cluster while the big cluster is impressively tamed and utilised at sub 1 GHz frequencies, 0.7 GHz on average, while the little cluster lifts the burden from the furious big cores, operating at frequencies between 1.1 GHz and max frequency of 1.59 GHz. Scrolling through the pages is silky smooth with no hiccups of any sort, even when loading a lot of content while stubbornly scrolling the page, it does not stutter as much as it does on HMP. However, things are not all rosy when it comes to battery drain. Web browsing is undeniably demanding, which makes it logical to see a not-so-impressive 17%/hr drain rate. While it may sound marginally better, web browsing inevitably does take its toll on the battery for sure, and things are not that drastically better when it comes to battery conserving. However, when you couple that with the increased fluidity and consistency gained, EAS is the clear victor.
YouTube streaming
HMP - For such a medium/light workload, it is no wonder seeing the little cluster being noticeably more active than the big cluster, where it spends most of the time on the lower end of the frequency spectrum, with more than 60% spent on the lowest 2 frequency steps of 422 MHz and 307 MHz. However, there were some occasional bumps to a rather unexpectedly higher frequency of 960 MHz, taking around 11% of the total time. While the big cluster was relatively quite dormant, it was not asleep either. With around 7% of the time spent on 1.25 GHz, it is far from being asleep, which raises some eyebrows for sure. It's not that grim though. At 11.6%/hr drain rate, it's highly unlikely to find your phone depleted before lapping some 9 episodes of your favourite TV series, which in my case was the old Top Gear UK.
EAS - Surprisingly enough, there are almost no tangible improvements in battery life while streaming some videos on YouTube. With the consistently reported figure of 11.3%/hr by EXKM battery monitor, I am struggling to say anything other than the fact that battery life is very similar to that of HMPs. Moreover, the frequency distribution is not that all different either. Little cluster is expectedly sitting most of the time at the lowest two frequency steps with much shorter duration at the 480, 556 and 652 MHz steps. Same goes for the big cluster as well, with respective frequency steps considered of course. But rest assured, it is still as highly unlikely to miss out a season of your favourite TV series as with HMP.
Overall battery life
HMP - in the past couple of days, I often read a value between 14%/hr and 16%/hr in EXKM's battery monitor with my mixed not-so-light usage, which is pretty much decent though not perfect and definitely leaves something to be desired in that area. But since I get more than 5 hrs SOT at the end of the day with some little juice left in the tank at the end of the day, I think it is safe to say battery life is good enough for the overwhelming majority of users
EAS - While people may think this is pure EAS terrain, results are not dramatically different from what you get from HMP. Surprisingly enough, I often stumble across an active drain rate between 13%/hr and 15%/hr with approximately the same usage pattern, which is 3%/hr less than what you get from HMP in the best cases. This is a substantial improvement, make no mistake, but that may not live up to the expectations from an energy aware scheduling system. However, an area where EAS truly shines is screen-on idling. Not only does the CPU retreat to the minimum frequency quite quickly, but also remains utterly dormant with absolutely no random spikes, causing a dramatic decrease in the battery drain. This is purely e-book readers heaven for sure! The same cannot be said about HMP for sure.
let's get to the numbers...
App launches
[HMP]
PCMark: (7.13 + 8.32 + 6.65 + 7.00 + 7.85)/5 = 7.39 sec
Slack: (1.60 + 1.78 + 1.79 + 1.65 + 1.75)/5 = 1.71 sec
YouTube: (1.40 + 1.44 + 1.41 + 1.44 + 1.45)/5 = 1.43 sec
Telegram: (0.65 + 0.72 + 0.70 + 0.54 + 0.61)/5 = 0.64 sec
WhatsApp: (1.28 + 0.72 + 1.27 + 1.34 + 1.28)/5 = 0.91 sec
Hangouts: (1.38 + 1.34 + 1.31 + 1.34 + 1.38)/5 = 1.35 sec
Dropbox: (1.25 + 1.26 + 1.37 + 1.22 + 1.21)/5 = 1.26 sec
Chrome: (1.18 + 1.36 + 1.19 + 1.50 + 1.38)/5 = 1.32 sec
Keep: (0.94 + 1.03 + 0.97 + 0.94 + 0.97)/5 = 0.97 sec
MMX Hill Dash: (7.56 + 12.87 + 12.09 + 11.60 + 10.81)/5 = 10.99 sec
Twitter: (1.69 + 1.81 + 1.90 + 1.66 + 1.91)/5 = 1.79 sec
True Skate: (1.60 + 1.69 + 1.62 + 1.59 + 1.54)/5 = 1.61 sec
XDA Labs: (1.41 + 1.53 + 1.47 + 1.48 + 1.52)/5 = 1.48 sec
Test has been done with no active Internet connections (WiFi and mobile data turned off) to ensure that the phone is not bottlenecked by anything but the I/O and the CPU
CPU governor is Interactive with stock settings and I/O scheduler set to CFQ with 512 KB read ahead buffer size
[EAS]
PCMark: (9.13 + 9.63 + 9.50 + 9.84 + 9.50)/5 = 9.52 sec
Slack: (1.66 + 1.79 + 1.69 + 1.75 + 1.85)/5 = 1.75 sec
YouTube: (1.66 + 1.69 + 1.63 + 1.62 + 1.69)/5 = 1.66 sec
Telegram: (0.69 + 0.66 + 0.63 + 0.59 + 0.78)/5 = 0.67 sec
WhatsApp: (0.75 + 1.19 + 1.16 + 0.97 + 1.21)/5 = 1.06 sec
Hangouts: (1.34 + 1.29 + 1.36 + 1.25 + 1.31)/5 = 1.31 sec
Dropbox: (1.40 + 0.84 + 0.86 + 0.85 + 0.87)/5 = 0.96 sec
Chrome: (1.32 + 1.37 + 1.39 + 1.56 + 1.32)/5 = 1.39 sec
Keep: (0.97+ 0.91 + 0.85 + 0.93 + 0.84)/5 = 0.90 sec
MMX Hill Dash: (11.31 + ---) the game refuses to launch seamlessly, to be investigated later..
Twitter: (2.25 + 2.53 + 2.50 + 2.57 + 2.37)/5 = 2.44 sec
True Skate: (2.00 + 1.58 + 1.71 + 1.75 + 1.74)/5 = 1.76 sec
XDA Labs: (1.72 + 1.44 + 1.47 + 1.53 + 1.43)/5 = 1.52 sec
Test has been done with no active Internet connections (WiFi and mobile data turned off) to ensure that the phone is not bottlenecked by anything but the I/O and the CPU
CPU governor is Schedutil with stock settings and I/O scheduler set to BFQ with 512 KB read ahead buffer size
.
Synthetic Benchmarks
[HMP]
AnTuTu: 148,471
Geekbench 4.1.0: 1733 + 4191
Vellamo - Multicore: 3215
Vellamo - Metal: 3541
Vellamo - Chrome: 4825
[EAS]
AnTuTu: 143840
Geekbench 4.1.0: 1740 + 3290
Vellamo - Multicore: 2511
Vellamo - Metal: 3569
Vellamo - Chrome: 4350
This test was conducted with RenderKernel-OP3-OOS-N-EAS-R1-WALT and OnePlus's inbuilt kernel. OxygenOS version used was OOS 4.1.3 STABLE
Coming up next is a brief technical breakdown of OOS's behind-the-scenes stuff and how OnePlus fiddled around with them by XDA member @chinmai560621 .
Hope such an analysis benefits someone here. Sorry for the delay, but i have been double slapped by life for the past couple of weeks every day....
Reserved
An amazing write up by a talented dev @joshuous:
PELT and WALT
Time for me to flex the analogy muscles.
Just to set things straight, PELT and WALT are different load tracking metrics that try to determine the load of the system. The load will eventually be used by the frequency governor to set the frequency. Think of them (the load tracking metrics) as an employee who is dedicated to announcing how quickly customers are coming into your burger restaurant. The frequency governor is the burger chef, who isn't able to see the number of customers entering, so he has to rely on the announcer in order to know the rate at which he is making burgers. The announcer can say that there are "many" customers, and the chef has to decide how fast to make the burgers based on how he interprets "many".
One announcer can say that 10 customers is "many", while another may say that 20 is "many". An announcer may also attempt to predict the number of customers that will enter based on how many he sees at the current point in time. In this way, burger output is more 'bursty'. For example, there are 10 customers ("many"), then no customers ("none"), then 15 customers ("very many"). The chef works hard, then thinks he can take a break for a moment, then suddenly has to work like crazy to dish out burgers for 15 customers. An oversimplified analogy to WALT.
On the other hand, another announcer may observe a trend of customers and apply some prediction to guess how many customers might come through the door. Using the same customer sequence as before, he may instead tell the chef "many", "some", then "many". So the chef may make burgers even when there are no customers, in anticipation of future customers, but he won't be worked so darn hard all of a sudden. This is less bursty and more consistent. An oversimplified analogy to PELT.
In the same way there are different chefs (e.g. Sched and Schedutil). They have different interpretations of what "many" means to them. That's why their burger outputs may be different even when having the same announcer.
So which is better? It all boils down to your workload, and even so it is difficult to make a conclusion. All I can say is that you must test each mechanism for over a week and check your active drain rate (Ex Kernel Manager is good for this). Active drain rate is a much better measure than SOT. And make sure to keep jumping back and forth between the two to account for anomalies.
Edit: On another note, to complete the analogy... Interactive and HMP is more similar to the chef being the announcer as well. Except for he is able to see less than a dedicated announcer can. I.e the chef (interactive governor) can't look at the queue outside his restaurant but only the ones in his restaurant (so he is partly blind). A dedicated announcer can look at customers inside and outside the restaurant though.
Do note that this has little to do with EAS per se. EAS is a different beast that focuses on optimizing which customers is assigned to which chefs. I'll probably write the analogy for this another time if there is a demand for it
You can't imagine how happy I am to see you here!
Sent from my ONEPLUS A3003 using Tapatalk
Download links says, N6?
ELoTRIX said:
Download links says, N6?
Click to expand...
Click to collapse
See OP#2. Sorry, still updating OP
Work with 3.5.5. cb?
Sent from my ONEPLUS A3003 using XDA-Developers mobile app
isoladisegnata said:
Work with 3.5.5. cb?
Sent from my ONEPLUS A3003 using XDA-Developers mobile app
Click to expand...
Click to collapse
Sorry, it will not work for CB yet. I made that clearer in OP.
I would like to offer support for it though.
TaRsY said:
You can't imagine how happy I am to see you here!
Click to expand...
Click to collapse
Me too!! I love render since lg g2 times.. Thanks Render for coming here
omg another kernel. Im so exited !!!!!!!!
thank you very much!!!
cant wait to test!!!
looks very promissing!!
MBurns2 said:
Me too!! I love render since lg g2 times.. Thanks Render for coming here
Click to expand...
Click to collapse
Thanks! Glad to be here!
nadejo said:
omg another kernel. Im so exited !!!!!!!!
thank you very much!!!
cant wait to test!!!
looks very promissing!!
Click to expand...
Click to collapse
I appreciate the kind words!
Everyone, please remember to provide logs in case of a reboot. I dont like to release such builds but it will happen from time to time. Especially when porting new features such as EAS.
You can get a log from
/sys/fs/pstore/console-ramoops
New build. Fixes default governor not being set properly.
Default gov is supposed to be "SCHED"
R1-T40-EAS
Great work bud
__
v7
RenderBroken said:
New build. Fixes default governor not being set properly.
Default gov is supposed to be "SCHED"
R1-T40-EAS
Click to expand...
Click to collapse
Good to see you here Buddy.. No doubts now we have one more best kernel for our beast OP3. surely gonna use permanently...
Sent from my aicp_oneplus3 using Tapatalk
Render is great just bringing another great kernel to the Oneplus 3
Look who's here.. Render.. One of the most friendly and vocal devs.. Thank you for the kernel mate.. You made opo so amazing..
Flashed looks good!
lets see for next battery cycle.
Great! EAS is really where I was hyped for! Thx for your amazing work!.
I'm going to run it 24 hours and see if there are any reboots, if there won't be ill let you know. I noted that the Cpu frequency stays quite high when there is barely any load? Is this normal?
Edit: issue with standby, couldn't get my phone on when I didn't use it for like 3-4 minutes. Had to reboot, but couldn't reproduce the problem
Issues I encountered:
1. Had an instant where my phone's screen was off for 2 minutes, i couldnt get the screen back on so i had to reboot. Yet i failed to reproduce the issue. (Logs didnt show anything)
2. CPU frequency seems to be really overkilling a task. It doesnt like to stick to 300Mhz either.
Other then that it works smooth and flawless! Even Snapchat is now using all 4 cores instead of only 2 little ones on HMP.
Hi, I know you only support OOS. Having said that, will it cause any problems if I use it over custom roms?
ROM OS Version: 2.3.x Gingerbread
Click to expand...
Click to collapse
Sorry for disturbing, but OP need some correction
Anyway, I'm impatient to test it !
Hi Guys, this is a continuation from initial discussion (and my promise) on InsigniuX kernel thread HERE
UPDATE 1 : After further testing, incorporate input boost to CPU 1 and 5 actually help the performance without affecting battery, as long as we set it within the optimal frequency. I also put fine tuning in hispeed_delay value, please use latest Profile File if you are using PRESET, or check the new values bellow if you do manual config
NOTE : If you are too lazy too read all the technical stuff, simply download the PRESET KERNEL ADIUTOR PROFILE HERE, and apply it to your Kernel Adiutor (choose "profile" from side bar, hit the (+) icon, and choose "import" and choose the downloaded .json file)
as we all know and aware, we always look and try to find the most optimum configuration to achieve best battery life without sacrificing performance. And while of course Qualcomm and Xiaomi have the most talented developers in their team, sometimes the implementation between both in their mass product might left a room for improvement. And in that exact room, we as community here play our role,
so, in an attempt to get a better fluidness out of this device, without sacrificing battery life, i remember one of the guide made by @soniCron i used to stumbled upon few years ago. This Guide give a very detail insight on how to optimize the interactive governor on almost any device/any kernel/any rom (as long as you have root), and thats what i gonna try to apply to our device - if you want to check the guide yourself : HERE
so i take a look into Whyred Kernel Sources to see the voltage values being used by our processor for each frequency step. And here's the voltage/speed table in case you want to see :
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
from that table, we can see which frequencies are using most power, and where is the most jump in voltage usage happen when switching between frequency.
Higher voltage jump will cost more power, means less battery life.
in conclusion, i found few frequencies which are less favorable, which is
LITTLE CPU :
1136Mhz - step by step Speed Gain is fine, but when compared to straight jump to 1401Mhz, the Speed to Power Ratio is become less favourable
1536Mhz - Smallest Speed Gain compared to Power Usage
and i also found some which might be the best/favourite frequencies :
LITTLE & BIG CPU :
900Mhz - Best contender for base speed, as it use almost same power with 633Mhz, but with plenty of speed gain
1401Mhz - Good Speed to Power Ratio
and
1747Mhz - Good Speed to Power Ratio for BIG CPU
_____________________________________________________________________________________________________________________________________________________
Now we take into account of the minimum frequency needed to ensure smooth task (if you dont know what am talking about, read the GUIDE i mention in my opening paragraph) :fingers-crossed:
For Whyred, i've found the best frequency is as following :
Idle = 633MHz (Lowest we can go at the moment)
Scrolling = 900MHz (Use Chrome browser to scroll Facebook in desktop mode)
Video = 1401MHz (Play 1080p*60fps videos in Youtube app)
App load = 1747MHz (Can use any app really)
High load = 1843MHz (Max out just in case)
Using the formula take from soniCron guide, i tried calculate optimum CPU load (this will be used as target load config) config for each frequencies
If you want to see the formulas :
Code:
We want to determine 2 values for every available clock rate: the maximal efficient load and the minimal efficient load. To make this determination, we need to bust out our calculators. (Or spreadsheets!)
For the maximal efficient load, we want to correlate a load value no higher than 90% of a given clock rate before it would be more efficient to jump to the next clock rate–to avoid overwhelming a particular rate while avoiding premature jumps to the next. For this value, we calculate it as:
(clock rate * 0.9) / next highest clock rate
For example, the maximal efficient load for 600Mhz on the Nexus 5X would be calculated as:
(600000 * 0.9) / 672000 = 80.36% (rounded and normalized: 80)
For the minimal efficient load, we want to correlate a load value at which anything higher would be better served by a higher clock rate. To calculate this:
(1 - next highest clock rate / clock rate) * -1
For example, the minimal efficient load for 600Mhz on the Nexus 5X would be calculated as:
(1 - 672000 / 600000) * -1 = 12.00% (rounded and normalized: 12)
with this config, logically speaking we want to make the Governor to favour the "best" frequencies above, and minimize the usage of unfavourable freqs.
LITTLE
Code:
633Mhz : 63
900Mhz : 71
1136Mhz : 23
1401Mhz : 82
1536Mhz : 4
1612Mhz : 83
BIG
Code:
1136Mhz : 73
1401Mhz : 9
1747Mhz : 85
1843Mhz : 90
Now that we already get the optimum number, time to apply it
Use your favorite Kernel Manager, in my case, am using Kernel Adiutor, and go to CPU Config - CPU Governor Tunables and input these value (am using Hawktail base profile from soniCron thread, as it seems it work best for most of devices, and i already do trial & error with some other value like timer rate as well ) :
(LITTLE)
Code:
align_windows:1
go_hispeed_load: 95
above_hispeed_delay: 0 633600:60000 902400:75000 1401600:100000
timer_rate: 80000
hispeed_freq: 902400
timer_slack: 200000
target_loads: 70 633600:63 92400:71 1113600:23 1401600:82 1536600:4 1612800:83
min_sample_time: 35000
boost: 0
boostpulse_duration: 0
(BIG)
Code:
align_windows:1
go_hispeed_load: 95
above_hispeed_delay: 32000 1136000:60000 1401600:75000 1747200:80000
timer_rate: 60000
hispeed_freq: 1747200
timer_slack: 100000
target_loads: 98 1113600:23 1401600:9 1747200:85 1804200:94
min_sample_time: 20000
boost: 0
boostpulse_duration: 0
Other necessary adjustment :
Boost : ON For CPU 1 at 902400 and CPU 5 at 1401600 both for 100ms
Min Big CPU Hot Plug : 0
Disable all Toggle in Thermal Section
Run Terminal and command :
Code:
su
stop perfd
or Install this MAGISK MODULE to disable Stock Thermal & Hotplug Control (Courtesy of @Mr.Nguyen0504)
Now you can test it. Do full charge and use it normally, see whether you can see the improvement or not,
be mind that this config is not really adjusted towards battery life, but rather overall fluidness/performance, yet without sacrificing too much power
Hopefully it helps you as it seems to help me (you can expect no less than 7-8Hrs SoT, am quite heavy user myself, with 2 WhatsApp account and 1 LINE account constantly active. YouTube & Gaming at least hour/day as well). Discussion is more than welcome here, as these are considered an initial calculations that still yet to furtherly fine tuned for our CPU.
Thanks mate, was waiting for this.
Initial thoughts = project butter:good:
xdarkstar said:
Thanks mate, was waiting for this.
Click to expand...
Click to collapse
please let me know the experience, i only test it with my personal preferences, so your desire with your device may vary
but i think it shouldnt be that far
otonieru said:
please let me know the experience, i only test it with my personal preferences, so your desire with your device may vary
but i think it shouldnt be that far
Click to expand...
Click to collapse
Excellent guide as well. Will test parameters over the weekend.
I will test this
mxilil said:
I will test this
Click to expand...
Click to collapse
yes please,
in the meantime, i also testing another config with input boost enabled, and some fine adjustment to hispeed_delay,
if it turn out to be better, i might create 2nd preset, along with custom control to disable BCL and Perfd. So we do not need to type it in terminal manually after reboot and let adiutor do that.
otonieru said:
Run Terminal and command :
Code:
su
stop perfd
Click to expand...
Click to collapse
I think "stop perf-hal-1-0" is the proper command.
@otonieru Great thread, very nice presentation of the matter with just the right info and setup example.
I have followed the same tutorial for my previous device but ended up using the tunables from my ROM maintainer as I never managed to calculate it properly, probably because I overlooked the voltage jumps.
Now, I wonder whether the minimum freqs of 300mhz for both clusters would help in battery life gains, taking into account the proper target loads are set for both and "timer_rate" and "min_sample_time" are tuned to make CPU ramp up quickly to avoid lags and stutters.
Logically, voltage is lower for lower frequencies, but in this case, 300mhz and 633mhz might be the same on little cluster or the voltage jump might be insignificant, but the voltage jump on big cluster might be bigger. And since the big cluster is on minimum frequency most of the time we might see some gains there.
Can you check the sources of some kernels with full range of frequencies (not the ones who have undervolt applied) and see the voltage tables?
Where is perfd located, or the file that contains the values for perfd daemon? It seems that the terminal command to disable it doesn't work, on any load except standby it still hits 1612mhz on little cluster, which is extremely annoying.
EDIT: There is no line about running state of perfd like this:
Code:
[init.svc.perfd]: [running]
There is only a line pointing at the presence of perf daemon I believe. Does this mean that perfd is not running on my system at all, so the "stop perfd" command doesn't do anything?
EDIT2: My bad people, I've set target loads for 1536 and 1612 to 4 and 8 respectively, by missing another number. Now I've set them to 98 and 100 as it was set on my previous device for two of the highest CPU steps, now the use of freqs seems much better and the device performs nice.
Cirra92 said:
Where is perfd located, or the file that contains the values for perfd daemon? It seems that the terminal command to disable it doesn't work, on any load except standby it still hits 1612mhz on little cluster, which is extremely annoying.
EDIT: There is no line about running state of perfd like this:
There is only a line pointing at the presence of perf daemon I believe. Does this mean that perfd is not running on my system at all, so the "stop perfd" command doesn't do anything?
EDIT2: My bad people, I've set target loads for 1536 and 1612 to 4 and 8 respectively, by missing another number. Now I've set them to 98 and 100 as it was set on my previous device for two of the highest CPU steps, now the use of freqs seems much better and the device performs nice.
Click to expand...
Click to collapse
Actually, i didnt include 300Mhz in my calculation because i try to check various whyred kernel source, and found that not too many of them make the 300Mhz available to beanually selected, but i do check the voltage used by 300Mhz and its saving is almost neglectible,
and as i do this tweak based on my current kernel set up (InsigniuX), i do it with 633 as base.
as for 1612 being used much,
i found that there's probably a bug in our device kernel code that make cpu sometimes lock in its highest frequency (1804 & 1612), it only happen after you restart the phone, (and it happen with most kernel out there, so its not literally the dev mistake, more like xiaomi messed up some codes)
the fix for now is by opening adiutor, ensuring that the freq not locked up. If its locked, change it back manually to 633 and 1133 (for small and big respectively), i found that it manage to stay until another reboot.
my cpu usage is as how i expected from my target load. so i think it play nicely for now.
After further testing, i update the config to incorporate boost & better tuning of hispeed_delay for each frequencies,
please check main post
otonieru said:
After further testing, i update the config to incorporate boost & better tuning of hispeed_delay for each frequencies,
please check main post
Click to expand...
Click to collapse
I am still on first charge since tweaking the kernel. So far it seems that the battery life is going to be the same, but it feels to me that everything is just a bit faster now, app opening and loading times are shorter and a bit smoother, might be a placebo, but it works nice.
One thing you should fix in main post, your target load for 1612 mhz in little cluster is set to 8, but in calculations it is 83, I suppose you missed the 3 when you wrote the tunables
I am going to update the settings you added after it falls to 20% and I recharge it.
One more thing, if I use the Magisk module for thermal and hotplug (or simply turn off the Core control in Kernel manager) does it mean that the cores will go offline if there is no load?
I remember having different hotplug solutions on SD801 devices which actually turned off 3 cores and left only one to do basic functions in deep sleep, or turn on 2 of them when there is low load on the CPU.
@Cirra92 ah right ! i might hit the backspace accidently, LoL
about hotplug, honestly am still testing it myself to figure whether the config work as intended or not, since the behaviour of this chipset it quite different. And since oreo its a bit harder to really track the cpu activities, we need to run an app to see the activities, but the app itself is giving load to cpu, thus the reading might not actually accurate.
1. Can you repost the voltage table image again? i can't see or is it missing? i really need this voltage info table, I've been playing with kernel tweaks this last few weeks.
2. On your 1st post,little cpu target load arguments are as follows : target_loads: 70 633600:63 92400:71 1113600:23 1401600:82 1536600:4 1612800:83
I don't think its the right setup. the first argument is target load which is 70, is affecting all freq starting from lowest to the highest (if there are no more arguments). but on 2nd argument you write 633600:63 (assuming 633600 is our lowest freq) then the first target load (70) has no effect. cpu target load for lowest freq (633Mhz) will be 63%, at 902Mhz the target load max is 71% and so on. And your screenshot shows the setup behavior. It idles at 633 then only spend small amount of time at 902 and 1401 and go right at the max freq for almost one and a half hours of total. If you want 633600 max target load 63% then the setup as follow :
target_loads: 63 92400:71 1113600:23 1401600:82 1536600:4 1612800:83
It means max target load from the lowest freq (633Mhz) will be 63% until below 902400. at 902400 max target load is 71% until below 1113600... and so on.
CMIIW
blackbellz said:
1. Can you repost the voltage table image again? i can't see or is it missing? i really need this voltage info table, I've been playing with kernel tweaks this last few weeks.
2. On your 1st post,little cpu target load arguments are as follows : target_loads: 70 633600:63 92400:71 1113600:23 1401600:82 1536600:4 1612800:83
I don't think its the right setup. the first argument is target load which is 70, is affecting all freq starting from lowest to the highest (if there are no more arguments). but on 2nd argument you write 633600:63 (assuming 633600 is our lowest freq) then the first target load (70) has no effect. cpu target load for lowest freq (633Mhz) will be 63%, at 902Mhz the target load max is 71% and so on. And your screenshot shows the setup behavior. It idles at 633 then only spend small amount of time at 902 and 1401 and go right at the max freq for almost one and a half hours of total. If you want 633600 max target load 63% then the setup as follow :
target_loads: 63 92400:71 1113600:23 1401600:82 1536600:4 1612800:83
It means max target load from the lowest freq (633Mhz) will be 63% until below 902400. at 902400 max target load is 71% until below 1113600... and so on.
CMIIW
Click to expand...
Click to collapse
i still can see the table, probably the connection from xda server is not good, its kinda patchy nowaday,
and btw, maybe you are right about the target loads. Although as i mentioned as well, that this config is lean more towards percormance, so its kinda intended from my side. But am still testing some other value as well, and i gonna try with your value as well.
as for now, my current set up is quite satisfy me.
crap, i cant even attach 2 picture in one post
otonieru said:
After further testing, i update the config to incorporate boost & better tuning of hispeed_delay for each frequencies,
please check main post
Click to expand...
Click to collapse
Can you add an image of the voltage table? The original image is not visible^^
otonieru said:
i still can see the table, probably the connection from xda server is not good, its kinda patchy nowaday,
and btw, maybe you are right about the target loads. Although as i mentioned as well, that this config is lean more towards percormance, so its kinda intended from my side. But am still testing some other value as well, and i gonna try with your value as well.
as for now, my current set up is quite satisfy me.
Click to expand...
Click to collapse
i tought this was towards battery but still keeping performance.
Try it or die said:
Can you add an image of the voltage table? The original image is not visible^^
Click to expand...
Click to collapse
Yup, it's not visible. But OP said its visible to him...
raptorddd said:
i tought this was towards battery but still keeping performance.
Click to expand...
Click to collapse
no, its the other way round as i wrote in my main post, LoL. But i guess 9-10Hrs SoT is more thwn enough wasnt it ?