This thread will be dedicated to my own experimental device tree tweaks in regards to voltage and frequency. It is based on the fantastic work that you can find here: 20*C Cooler, and now with water resistance!
I decided to make a new thread so that my files will not get lost in a huge pile of posts and I have a place where I can keep all my observations in one place.
CAUTION: Everything that is deemed as "stable" is the be treated as "stable enough" for me to run my Pyra, use it for web browsing and Discord.
@hns , this is a comprehension of all the things I figured out during the last days in regards to frequencies.
Prelude
This all starts with the work of @Asaggynoodle. What he did was to add frequencies to our existing ones.
What we currently have are steps of 250MHz, starting at 250MHz, reaching up to 1500MHz.
Those are our values:
What @Asaggynoodle did, was to add frequencies in between our ones and interpolate the voltages accordingly.
This apparently led to a cooler and stable system to him.
Further, he unlocked frequencies beyond 1500MHz, up to 2GHz.
Tweaked values by Asaggynoodle:
To unlock the frequencies above 1.5GHz, a modification to pyra-thermal.sh was required.
The original post and files can be found here.
As a realistic estimate, you will not be able to run your Pyra at 2GHz. I was able to use this device tree with unlocked 1.9GHz, however my Pyra overheated after a while of web browsing and clocked down to 250MHz in order to cool down.
In the end (after a while, to be fair) it froze. Either because it overheated, or because it simply is not stable at 1.9GHz.
However, limiting the clocks to 1.8GHz seemed to be quite a stable experience for me, despite my Pyra getting super warm (spoiler alert, I have a nice fix for this).
Hunting the floor - A lot of work, success and a big disappointment
Here is the idea
I expected crashes along the way and if those occur, the plan was to gradually increase the voltages.
(This alone took me the while Saturday and a bit of Sunday.)
Those are the results.
Absolute minimum voltages for each frequency to boot 10 Pyras reliably, if only one frequency is being used in isolation:
(See attachment: CRASH_step_125_start_250_end_1500_minimumValuesSaveToBootInIsolation.zip)
As you can see, I could reduce the voltages by quite a bit for each frequency.
This gave me hope that even if I had to increase them a bit for stability reasons, the effort was worth it.
Aaaaand it did not work. Even though each of the frequencies run stable in isolation, as soon as they are being combined, things get completely unstable and no Pyra would boot.
So yeah, that was disappointing, a lot of work for no gains.
Further I found out that at 250 MHz running at 670mV does not provide substantially (probably nothing at all) more battery life compared to running 250MHz at 77mV.
I compiled the files in a device tree, jsut in case someone is brave and wants to test it. See file: CRASH_step_125_start_250_end_1500_minimumValuesSaveToBootInIsolation.zip
There is no giving up - Success after all
I put so much work into it, I did not allow it to be all for nothing. So the next logical thing to do is to put even more work into it.
I did what most scientists do, random poking around. I increased all voltages gradually, increased them individually but it all seemed to not be of much use.
However, one thing helped: Disabling 250MHz.
That was suspicious. I investigated this further and found out that it was the lower end that caused troubles.
Even if 250MHz can run below 700mV in isolation, it fails immediately if I add more frequencies at the lower end.
So I began increasing the voltages at the lower end and viola, my Pyra survived a boot cycle.
Not just that. It was stable if I used it for more than just a boot.
It is super interesting, by how much I had to increase the voltages at the lower end. Anything below 750mV (its default value) caused immediate crashes.
Stable values with tweaked voltages, 125MHz steps:
(See attachment: STABLE_step-125_start-250_end-1800.zip)
Those values should be save to use. There might be some crashes after a while, so keep a backup of your original device tree and test it on a boot SD card first.
If you Pyra boots, it should be save for a long term test.
On a positive note, pretty much all frequencies above 375MHz could keep their optimized values.
More experimentation, more frequencies
As a wise man (HNS) just told me:
Luckily I was faster and there was no force to stop my free flowing thoughts.
Why stick with 125MHz steps, if you can have 50MHz?
What I did was to use the power of interpolation and guessing to take the results from above and apply the tweaked voltages to 50MHz steps.
Aaaand it did not work. Of course it did not.
However the issue once again was the lower end and handling the lower frequencies a bit more conservatively solved the issue.
A bit more experimentation and using conservative values for the interpolated and guessed values gave me quite stable results.
Stable values with tweaked voltages, 50MHz steps:
(See attachment: STABLE_step-50_start-250_end-1800.zip)
I have no idea if this does any good or just provides more complexity.
Setting the XFCE frequency monitor to 0.25s update interval at least shows me that pretty much all the frequencies are being used.
Only above 1.4 it's all or nothing, the steps below are being utilized.
More, all for science (More because more is better. If you disagree, why go on and read more? Got you with that one!)
@johnicboom :
@EvilDragon at a later stage:
I was not really in a mood of experimenting more after I spent so much time getting this all to work.
Further I was the same opinion of EvilDragon and expected it all to not work.
However the first of the two persons helped me with LeTux, whereas the second one just pays me money.
I could not deny the first one, so I began experimenting with low frequencies.
Really low frequencies. We are talking 10 MHz here.
I started with 250MHz and went down in 50MHz steps, all the way down to 50MHz.
No boot.
Luckily I had some experience already: More frequencies at the lower end requires higher voltages.
Yes, it is absolutely non intuitive but I had to increase the voltages at 250MHz and below to get it all to a stable state.
It was just by 20mV, leading to 770mV.
So to make this clear, 250MHz boots stable at 670mV if used in isolation, requires 750mV if more frequencies, starting at 375MHz are being added and requires 77mV if frequencies below are being added.
Further, any frequency below 250MHz also requires 77mV or else the Pyra does not boot at all.
Stable values with tweaked voltages, 50MHz steps, starting at 50MHz:
(See attachment: STABLE_step-50_start-50_end-1800.zip)
Once again, using the XFCE frequency monitor panel applet and setting its update interval to 0.25s show that all values below 250MHz are being used in idle mode.
This is true when using the "ondemand" governor but even more, with my Pyra constantly running at 50MHz, when using the "conservative" governor.
Does this help idle battery life? No.
Still, it's satisfying watching my Pyra running at low frequencies.
Since yesterday I run those frequencies on my main private Pyra which I use a lot for browsing and Discord. Further I leave it on and on a charger all day to test stability at the lower end.
Until now it was all stable with just one freeze. The freeze happened under load and the frequency monitor showed 1.7GHz, so I increased the voltage for that frequency by 10mV (that is already included in the values above).
I expect more occasional freezes along the way and I probably will increase the voltage for each frequency by 10mV, just to be sure.
For now, I'll leave it as is an want to observe. My Pyra is reasonable stable with those values, way more stable than it was before aTc pushed the freeze fix for Bookworm.
Pleasenot a statement by @hns :
So if you don't feel like experimenting and watching those low values, feel free to use one of the other device trees.
Even lower, even higher
So I tried to go even lower. Maybe we could get a fake sleep like we did on the Pandora by running 10MHZ.
Nope, that starts to mess up the graphics output and eventually freezes the system.
The lowest I could get to have a somewhat stable system was 40MHz. Everything below caused instabilities and messed up graphics during the boot terminal.
Maybe one could do something about it with increased voltages, however after all the testing I went through, I did not feel like investing more.
Further, it is important to ensure stability of the system with tweaked voltages between (50MHz) 250MHz and 1800MHz.
Why not go higher, up to 2GHz?
Check out the post by Asaggynoodle, he has some hefty cooling improvements made jsut to sustain 2GHz for a bit.
My Pyra was not super stable at 1.9GHz and probably yours won't be, either.
I want to eliminate cause of sudden freezes by too high clock speeds, so I decided to leave those frequencies out for now.
Come one, be happy with 300MHz extra.
Further, I wanted a frequency range, that could savely run on a stock Pyra without any advanced cooling solution.
And please don't forget, that I inbvested way too much into this already and I need a break and test the currently stable values.
The best of both worlds - high clocks and a cool system
There was one more iussue to solve: 1.8GHz is not sustainable.
It eats through your battery and more importantly, the cooling of the Pyra won't be able to handle it for long.
Sustained 1.8GHz will result in overheating, which results in hefty throttling and downclocking to 250MHz, or worse, system freeze.
Luckily we have a solution: pyra-thermal.sh
This is a neat little script that is being called now and so often to check the CPU's temperature and to regulate the frequencies.
By default, it is used to emergency throttle the system if it reaches above 90 degree Celsius.
A simple fix to the overheating issue is to gradually reduce the max frequencies depending on the core temperature.
I once again took the modified pyra-temerature.sh from Asaggynoodle as a base and added some frequencies:
Frequency curve implemented in pyra-thermal.sh :
Everything above 85000 was already there.
The lower values represent a frequency curve that gradually reduces the maximum frequency depending on the current core temperature.
If the system is idle, we usually are below 68 degree Celsius and as aa result, we will clock up to 1.8GHz once we do anything demanding.
After not too long, we usually will clock down to 1.7GHz. That is usually sustained as max frequency pretty well during browsing or any regular use.
Lower values are only being used once we reach higher temps and do demanding stuff.
For me, that curve works wonderfully.
My Pyra stays cool and regulates itself while still allowing me to enjoy higher clocks most of the time.
I do not play games on my Pyra but I expect my thermal curve to be effective enought to clock down aggressively wnough to not overheat during gaming.
The hefty downclocking at 90 degree and above is part of the default OS, so if you games do not reach that level, they should also not reach it with my values.
Installation and tweaking
Attached to this post are multiple device tree files, compiled as dtb and in raw form as dts.
You only need the dts if you want to tweak them manually.
Also my modified pyra-thermal.sh script is attached.
If you do not want to overclock, you do not need my thermal script.
pyra-thermal.sh
In any case, it is save to use my thermal script, even if you do not want to overclock and set the value in line 8 to "1500".
You do not need to modify any of the later values, that line defines the hard limit.
Frequency and voltage via device tree
Regarding device trees, pick one of the zip files, depending on which one you want to use.
Do NOT use the one what starts with CRASH. That is only for scientific purpose, if you want to have the respective values (see above).
Frequency Permanent conservative governor
Copy the file
into
.
On our system the prerequisites for that too work are already installed, so I consider it the best option.
The file only contains one line:
Reboot to make the changes take effect.
If you want to switch back to "ondemand", simply delete the file again.
I am not sure if this has any positive effect.
At least it helps to keep the frequencies down.
It should not have any negative effect.
Installation path
Put the files into the following location:
Installation path
To test your own frequencies, you need to make modifications to the divice three and compile it.
It is quite simple, here is how it's done:
What was it good for & what comes next
This all costed a lot of time and did not provide a huge boost in battery life.
In regards to idle, I maybe gained a few minutes if I use the 50MHz version.
It's probably not worth it, considering the comment made by hns.
What comes next
Regarding higher clock speeds, I could reduce the voltages by quite a bit for all, more than 100mV per step.
I did not do any long term tests in regards to battery life in day to day usage.
Maybe the added frequencies and lower voltages will result in less battery drain under common use scenarios.
That is something I will need to test during the next days while using my Pyra.
I do not plan any scientific load tests, however I am curious if I notice a difference (that is what matters, right).
Also we need a long term stability test for each frequency under a stress test.
Currently I do not feel like doing this, so if anyone wants to make a boot SD, boot my device tree with 50MHz steps and do a load test for each of them, feel welcomed to do so.
What I will do is to use my Pyra as much as I can with the fully unlocked 50MHz-1.8GHz devie tree and see if I run into any troubles.
If I do, I'll increase the voltages for each frequency by 10mV and that will probably solve the issue.
Remember, each of the frequencies (125MHz steps) already did a boot/log in/ shut down cycle test on 10 different Pyras.
So at least outliers should that refuse to boot should be taken into account.
I also did not check the heat in regards to the lower voltages.
So if one feels like doing a heat test, go ahead.
What was it good for
Even if we do not gain much increased battery life, we still gained an unlocked device tree up to 1.8GHz and a pyra-thermal.sh script that prevents overheating.
Feel free to use it, it should be pretty save, as long as the voltages are save.
Combined with the undervolting, maybe your Pyra will even run cooler than before.
Beyond frequency and voltage
In regards to idle battery life, what is more important than frequency and voltage, is tweaking the OS.
We should see what processes require the most background activity and identify those that we can disable.
Maybe we could disable USB, Bluetooth and other system components and services, like we did on the Pandora.
If we do so, a system tray launcher for quick access to enable them will probably be sufficient to conveniently provide access to those system components.
That however is a story for an other day and an other topic.
Good bye and good luck with the new device trees.
I decided to make a new thread so that my files will not get lost in a huge pile of posts and I have a place where I can keep all my observations in one place.
CAUTION: Everything that is deemed as "stable" is the be treated as "stable enough" for me to run my Pyra, use it for web browsing and Discord.
@hns , this is a comprehension of all the things I figured out during the last days in regards to frequencies.
Prelude
This all starts with the work of @Asaggynoodle. What he did was to add frequencies to our existing ones.
What we currently have are steps of 250MHz, starting at 250MHz, reaching up to 1500MHz.
Those are our values:
Code:
Hz uV
250000 750000
500000 850000
750000 950000
1000000 1050000
1250000 1100000
1500000 1250000What @Asaggynoodle did, was to add frequencies in between our ones and interpolate the voltages accordingly.
This apparently led to a cooler and stable system to him.
Further, he unlocked frequencies beyond 1500MHz, up to 2GHz.
Tweaked values by Asaggynoodle:
Code:
Hz uV
250000 750000
375000 800000
500000 850000
625000 900000
750000 950000
875000 1000000
1000000 1050000
1125000 1075000
1250000 1100000
1400000 1200000
1500000 1250000
1600000 1300000
1700000 1350000
1800000 1350000
1900000 1350000
2000000 1450000To unlock the frequencies above 1.5GHz, a modification to pyra-thermal.sh was required.
The original post and files can be found here.
As a realistic estimate, you will not be able to run your Pyra at 2GHz. I was able to use this device tree with unlocked 1.9GHz, however my Pyra overheated after a while of web browsing and clocked down to 250MHz in order to cool down.
In the end (after a while, to be fair) it froze. Either because it overheated, or because it simply is not stable at 1.9GHz.
However, limiting the clocks to 1.8GHz seemed to be quite a stable experience for me, despite my Pyra getting super warm (spoiler alert, I have a nice fix for this).
Hunting the floor - A lot of work, success and a big disappointment
Here is the idea
- Disable all frequencies except the single one I want to tweak
- Figure out the lowest possible number at which my Pyra boots
- Do a full boot/login cycle with only that one frequency enabled
- If that succeeds without a freeze, that value is considered "stable enough"
- Do this test for 10 Pyras in total
- If one Pyra fails, increase the voltage by 10mV
- If all Pyras make it through the boot/login/shutdown cycle without freeze, consider that frequency-voltage combination "stable enough"
- Disable that one frequency and test the next one, do this for all of Asaggynoodle's frequencies.
I expected crashes along the way and if those occur, the plan was to gradually increase the voltages.
(This alone took me the while Saturday and a bit of Sunday.)
Those are the results.
Absolute minimum voltages for each frequency to boot 10 Pyras reliably, if only one frequency is being used in isolation:
Code:
&cpu0 {
operating-points = <
/* kHz uV */
250000 670000
375000 730000
500000 770000
625000 770000
750000 810000
875000 860000
1000000 920000
1125000 960000
1250000 1010000
1400000 1080000
1500000 1130000
>;
};As you can see, I could reduce the voltages by quite a bit for each frequency.
This gave me hope that even if I had to increase them a bit for stability reasons, the effort was worth it.
Aaaaand it did not work. Even though each of the frequencies run stable in isolation, as soon as they are being combined, things get completely unstable and no Pyra would boot.
So yeah, that was disappointing, a lot of work for no gains.
Further I found out that at 250 MHz running at 670mV does not provide substantially (probably nothing at all) more battery life compared to running 250MHz at 77mV.
I compiled the files in a device tree, jsut in case someone is brave and wants to test it. See file: CRASH_step_125_start_250_end_1500_minimumValuesSaveToBootInIsolation.zip
There is no giving up - Success after all
I put so much work into it, I did not allow it to be all for nothing. So the next logical thing to do is to put even more work into it.
I did what most scientists do, random poking around. I increased all voltages gradually, increased them individually but it all seemed to not be of much use.
However, one thing helped: Disabling 250MHz.
That was suspicious. I investigated this further and found out that it was the lower end that caused troubles.
Even if 250MHz can run below 700mV in isolation, it fails immediately if I add more frequencies at the lower end.
So I began increasing the voltages at the lower end and viola, my Pyra survived a boot cycle.
Not just that. It was stable if I used it for more than just a boot.
It is super interesting, by how much I had to increase the voltages at the lower end. Anything below 750mV (its default value) caused immediate crashes.
Stable values with tweaked voltages, 125MHz steps:
Code:
&cpu0 {
operating-points = <
/* kHz uV */
250000 750000
375000 750000
500000 770000
625000 770000
750000 810000
875000 860000
1000000 920000
1125000 960000
1250000 1010000
1400000 1080000
1500000 1130000
1600000 1190000
1700000 1240000
1800000 1300000
>;
};Those values should be save to use. There might be some crashes after a while, so keep a backup of your original device tree and test it on a boot SD card first.
If you Pyra boots, it should be save for a long term test.
On a positive note, pretty much all frequencies above 375MHz could keep their optimized values.
More experimentation, more frequencies
As a wise man (HNS) just told me:
Does it hurt: well, unnecessary complexity with marginal benefit may sometimes hurt
Luckily I was faster and there was no force to stop my free flowing thoughts.
Why stick with 125MHz steps, if you can have 50MHz?
What I did was to use the power of interpolation and guessing to take the results from above and apply the tweaked voltages to 50MHz steps.
Aaaand it did not work. Of course it did not.
However the issue once again was the lower end and handling the lower frequencies a bit more conservatively solved the issue.
A bit more experimentation and using conservative values for the interpolated and guessed values gave me quite stable results.
Stable values with tweaked voltages, 50MHz steps:
Code:
&cpu0 {
operating-points = <
/* kHz uV */
250000 750000
300000 760000
350000 770000
400000 770000
450000 770000
500000 770000
550000 770000
600000 770000
650000 780000
700000 790000
750000 810000
800000 830000
850000 850000
900000 870000
950000 900000
1000000 920000
1050000 940000
1100000 960000
1150000 970000
1200000 990000
1250000 1010000
1300000 1030000
1350000 1060000
1400000 1080000
1450000 1110000
1500000 1130000
1550000 1160000
1600000 1190000
1650000 1220000
1700000 1250000
1750000 1280000
1800000 1300000
>;
};I have no idea if this does any good or just provides more complexity.
Setting the XFCE frequency monitor to 0.25s update interval at least shows me that pretty much all the frequencies are being used.
Only above 1.4 it's all or nothing, the steps below are being utilized.
More, all for science (More because more is better. If you disagree, why go on and read more? Got you with that one!)
@johnicboom :
@EvilDragon at a later stage:
I was not really in a mood of experimenting more after I spent so much time getting this all to work.
Further I was the same opinion of EvilDragon and expected it all to not work.
However the first of the two persons helped me with LeTux, whereas the second one just pays me money.
I could not deny the first one, so I began experimenting with low frequencies.
Really low frequencies. We are talking 10 MHz here.
I started with 250MHz and went down in 50MHz steps, all the way down to 50MHz.
No boot.
Luckily I had some experience already: More frequencies at the lower end requires higher voltages.
Yes, it is absolutely non intuitive but I had to increase the voltages at 250MHz and below to get it all to a stable state.
It was just by 20mV, leading to 770mV.
So to make this clear, 250MHz boots stable at 670mV if used in isolation, requires 750mV if more frequencies, starting at 375MHz are being added and requires 77mV if frequencies below are being added.
Further, any frequency below 250MHz also requires 77mV or else the Pyra does not boot at all.
Stable values with tweaked voltages, 50MHz steps, starting at 50MHz:
Code:
&cpu0 {
operating-points = <
/* kHz uV */
50000 770000
100000 770000
150000 770000
200000 770000
250000 770000
300000 770000
350000 770000
400000 770000
450000 770000
500000 770000
550000 770000
600000 770000
650000 780000
700000 790000
750000 810000
800000 830000
850000 850000
900000 870000
950000 900000
1000000 920000
1050000 940000
1100000 960000
1150000 970000
1200000 990000
1250000 1010000
1300000 1030000
1350000 1060000
1400000 1080000
1450000 1110000
1500000 1130000
1550000 1160000
1600000 1190000
1650000 1220000
1700000 1250000
1750000 1280000
1800000 1300000
>;
};Once again, using the XFCE frequency monitor panel applet and setting its update interval to 0.25s show that all values below 250MHz are being used in idle mode.
This is true when using the "ondemand" governor but even more, with my Pyra constantly running at 50MHz, when using the "conservative" governor.
Does this help idle battery life? No.
Still, it's satisfying watching my Pyra running at low frequencies.
Since yesterday I run those frequencies on my main private Pyra which I use a lot for browsing and Discord. Further I leave it on and on a charger all day to test stability at the lower end.
Until now it was all stable with just one freeze. The freeze happened under load and the frequency monitor showed 1.7GHz, so I increased the voltage for that frequency by 10mV (that is already included in the values above).
I expect more occasional freezes along the way and I probably will increase the voltage for each frequency by 10mV, just to be sure.
For now, I'll leave it as is an want to observe. My Pyra is reasonable stable with those values, way more stable than it was before aTc pushed the freeze fix for Bookworm.
Pleasenot a statement by @hns :
So if you don't feel like experimenting and watching those low values, feel free to use one of the other device trees.
Even lower, even higher
So I tried to go even lower. Maybe we could get a fake sleep like we did on the Pandora by running 10MHZ.
Nope, that starts to mess up the graphics output and eventually freezes the system.
The lowest I could get to have a somewhat stable system was 40MHz. Everything below caused instabilities and messed up graphics during the boot terminal.
Maybe one could do something about it with increased voltages, however after all the testing I went through, I did not feel like investing more.
Further, it is important to ensure stability of the system with tweaked voltages between (50MHz) 250MHz and 1800MHz.
Why not go higher, up to 2GHz?
Check out the post by Asaggynoodle, he has some hefty cooling improvements made jsut to sustain 2GHz for a bit.
My Pyra was not super stable at 1.9GHz and probably yours won't be, either.
I want to eliminate cause of sudden freezes by too high clock speeds, so I decided to leave those frequencies out for now.
Come one, be happy with 300MHz extra.
Further, I wanted a frequency range, that could savely run on a stock Pyra without any advanced cooling solution.
And please don't forget, that I inbvested way too much into this already and I need a break and test the currently stable values.
The best of both worlds - high clocks and a cool system
There was one more iussue to solve: 1.8GHz is not sustainable.
It eats through your battery and more importantly, the cooling of the Pyra won't be able to handle it for long.
Sustained 1.8GHz will result in overheating, which results in hefty throttling and downclocking to 250MHz, or worse, system freeze.
Luckily we have a solution: pyra-thermal.sh
This is a neat little script that is being called now and so often to check the CPU's temperature and to regulate the frequencies.
By default, it is used to emergency throttle the system if it reaches above 90 degree Celsius.
A simple fix to the overheating issue is to gradually reduce the max frequencies depending on the core temperature.
I once again took the modified pyra-temerature.sh from Asaggynoodle as a base and added some frequencies:
Frequency curve implemented in pyra-thermal.sh :
Code:
#Check Core, from hottest to coldest
if [ ${core_temp} -gt 99000 ]
then
setMaxFreq 250
elif [ ${core_temp} -gt 97000 ]
then
setMaxFreq 500
elif [ ${core_temp} -gt 95000 ]
then
setMaxFreq 750
elif [ ${core_temp} -gt 93000 ]
then
setMaxFreq 1000
elif [ ${core_temp} -gt 91000 ]
then
setMaxFreq 1250
elif [ ${core_temp} -gt 85000 ]
then
setMaxFreq 1500
elif [ ${core_temp} -gt 81000 ]
then
setMaxFreq 1600
elif [ ${core_temp} -gt 76000 ]
then
setMaxFreq 1650
elif [ ${core_temp} -gt 72000 ]
then
setMaxFreq 1700
elif [ ${core_temp} -gt 68000 ]
then
setMaxFreq 1750
fiEverything above 85000 was already there.
The lower values represent a frequency curve that gradually reduces the maximum frequency depending on the current core temperature.
If the system is idle, we usually are below 68 degree Celsius and as aa result, we will clock up to 1.8GHz once we do anything demanding.
After not too long, we usually will clock down to 1.7GHz. That is usually sustained as max frequency pretty well during browsing or any regular use.
Lower values are only being used once we reach higher temps and do demanding stuff.
For me, that curve works wonderfully.
My Pyra stays cool and regulates itself while still allowing me to enjoy higher clocks most of the time.
I do not play games on my Pyra but I expect my thermal curve to be effective enought to clock down aggressively wnough to not overheat during gaming.
The hefty downclocking at 90 degree and above is part of the default OS, so if you games do not reach that level, they should also not reach it with my values.
Installation and tweaking
Attached to this post are multiple device tree files, compiled as dtb and in raw form as dts.
You only need the dts if you want to tweak them manually.
Also my modified pyra-thermal.sh script is attached.
If you do not want to overclock, you do not need my thermal script.
pyra-thermal.sh
In any case, it is save to use my thermal script, even if you do not want to overclock and set the value in line 8 to "1500".
Code:
maxFreq=1800Frequency and voltage via device tree
Regarding device trees, pick one of the zip files, depending on which one you want to use.
Do NOT use the one what starts with CRASH. That is only for scientific purpose, if you want to have the respective values (see above).
Frequency Permanent conservative governor
Copy the file
Code:
cpufrequtils
Code:
/etc/default/cpufrequtilsOn our system the prerequisites for that too work are already installed, so I consider it the best option.
The file only contains one line:
Code:
GOVERNOR="conservative"If you want to switch back to "ondemand", simply delete the file again.
I am not sure if this has any positive effect.
At least it helps to keep the frequencies down.
It should not have any negative effect.
Installation path
Put the files into the following location:
Code:
/usr/share/pyra/scripts/pyra-thermal.sh
/boot/dtb/linux-image-5.6.19-daveiii-pyradef-aufs/omap5-letux-cortex15-v5.3+pyra-v5.3.dtbInstallation path
To test your own frequencies, you need to make modifications to the divice three and compile it.
It is quite simple, here is how it's done:
Code:
apt-get install git build-essential flex bison libyaml-dev
git clone https://dev.pyra-handheld.com/packages/pyra-kernel # or other repo
cd pyra-kernel
# git checkout <<branch>> # Use the default one for now
# modify arch/arm/boot/dts/omap5-letux-cortex15-v5.3+pyra-v5.3.dts # or other files that have 'omap' or 'pyra' in their name
make pyra_defconfig dtbs
locate new dtb files in arch/arm/boot/dtb and copy to boot directory (ideally on a separate system on SD so you don't overwrite your working one)What was it good for & what comes next
This all costed a lot of time and did not provide a huge boost in battery life.
In regards to idle, I maybe gained a few minutes if I use the 50MHz version.
It's probably not worth it, considering the comment made by hns.
What comes next
Regarding higher clock speeds, I could reduce the voltages by quite a bit for all, more than 100mV per step.
I did not do any long term tests in regards to battery life in day to day usage.
Maybe the added frequencies and lower voltages will result in less battery drain under common use scenarios.
That is something I will need to test during the next days while using my Pyra.
I do not plan any scientific load tests, however I am curious if I notice a difference (that is what matters, right).
Also we need a long term stability test for each frequency under a stress test.
Currently I do not feel like doing this, so if anyone wants to make a boot SD, boot my device tree with 50MHz steps and do a load test for each of them, feel welcomed to do so.
What I will do is to use my Pyra as much as I can with the fully unlocked 50MHz-1.8GHz devie tree and see if I run into any troubles.
If I do, I'll increase the voltages for each frequency by 10mV and that will probably solve the issue.
Remember, each of the frequencies (125MHz steps) already did a boot/log in/ shut down cycle test on 10 different Pyras.
So at least outliers should that refuse to boot should be taken into account.
I also did not check the heat in regards to the lower voltages.
So if one feels like doing a heat test, go ahead.
What was it good for
Even if we do not gain much increased battery life, we still gained an unlocked device tree up to 1.8GHz and a pyra-thermal.sh script that prevents overheating.
Feel free to use it, it should be pretty save, as long as the voltages are save.
Combined with the undervolting, maybe your Pyra will even run cooler than before.
Beyond frequency and voltage
In regards to idle battery life, what is more important than frequency and voltage, is tweaking the OS.
We should see what processes require the most background activity and identify those that we can disable.
Maybe we could disable USB, Bluetooth and other system components and services, like we did on the Pandora.
If we do so, a system tray launcher for quick access to enable them will probably be sufficient to conveniently provide access to those system components.
That however is a story for an other day and an other topic.
Good bye and good luck with the new device trees.
Last edited:
