Wow, just wow
Thanks a lot for your awesome work.
I will probably contact you via PM as I'd like to find out if there's a feasible way to include the better heating method into the next units we assemble.
Having additional speed steps and other optimizations to lower the battery usage of the Pyra was something I asked for years ago - but one cared.
So it's good to finally have some units out with users, I will try to continue delivery as fast as possible.
Sorry for the delayed update, I had some issues with logging in to my forum account (thanks Microsoft!), but ED was able to get me sorted! Thanks ED!
Anyways, I've been cheating lately... And decided to "go big or go home" with the cooler. I just really wanted to test out the functionality of the Pyra at 2Ghz... So I installed a "big daddy" version of the SUNON fans I tested out earlier.
I printed out this fan housing, and used the bottom screw hole as a mounting point for the whole thing, it isn't perfect, but nothing really is when you're eyeballing with calipers!
The fan housing is actually angled at the top portion to direct the air flow into the ventilation holes I made in the bottom of the Pyra into the heatsink directly.
I also want to release this for anyone who is daring to try it out..
WORD OF WARNING, I take ZERO responsibility with how running this on your Pyra turns out.
As it will probably result in lots of crashes, and needing to reflash your installation if you can't swap the dtb file out if it doesn't work for you.
This is a completely unlocked device tree file for booting your Pyra with all the clock frequency steps from 250Mhz to 2Ghz. Each step has a tuned voltage for it as well, all steps are stable for my Pyra, but doesn't mean it will be for you.
This device tree is only recommended for those of you who have experience with modifying the Pyra-thermal script, as that will dictate the speed which your Pyra runs at. If you change the Pyra-thermal script to max 2Ghz, and your device crashes, overheats, or no longer boots, you will need to boot from another media (from SD install, or from eMMC if you're using a SD card install image like me). I would not use this if you don't have a backup installation on your SD card or eMMC to swap out the dtb file if it fails in your system, as you won't be able to boot up the device to do it from a single install...
All you have to do to install the attached unlocked device tree is this:
Unzip the file, you will be left with a single file named omap5-letux-cortex15-v5.3+pyra-v5.3.dtb DO NOT RENAME THIS FILE unless you know WHY you are renaming it and have a preproduction Pyra that needs a different version device tree.
Navigate to /boot/dtb/linux-image-5.6.19-daveiii-pyradef-aufs in your Pyra's OS install, and back up the file with the SAME name as the one you are replacing.
Copy this to another folder. Don't lose this, as you will need it if things go wrong, otherwise you will need to reinstall your OS.
Place the unlocked omap5-letux-cortex15-v5.3+pyra-v5.3.dtb you downloaded into /boot/dtb/linux-image-5.6.19-daveiii-pyradef-aufs
Reboot. Profit.
If your device reboots, you should now have all the extra frequency steps, but the Pyra-thermal.sh script will dictate which one to limit to. You must modify this file (change the max frequency higher) if you want it to scale outside of normal frequencies.
If your device no longer boots after a hard reset, you will need to copy the backed up (you did back this up right?!!) omap5-letux-cortex15-v5.3+pyra-v5.3.dtb and place it back in the folder above, and overwrite the unlocked file.
To modify the Pyra-thermal.sh script, you will need to navigate to /usr/share/pyra/scripts
You can then add or edit entries for thermal scaling for the frequencies you want, and the maximum frequency which your pyra can run at.... No, unless you've modified the cooling, you probably can't run 2Ghz I assure you... I hardly can!
This is very much user dependent how you want to tune your device, so I'll leave this up to you to play with.
As always, make sure to create a backup if things to awry. But there is no compiling here, just edit, save and reboot, or restart the daemon.
I've included my current Pyra-thermal.sh to see what I've changed, (this will 99% not work for you, or be what you want..) but it's a good example of modifications.
YESSSS! Of course! Thank you so much for giving it a shot, I'm glad to hear it works for you! Please let me know how it goes for you! I hope more people become interested in testing this out as it's quite a simple install all things considered.
I'll likely make updates and improvements as time passes, and based on feedback from those who test it. So please check back from time to time to check out if there's anything updated too.
I also want to release this for anyone who is daring to try it out..
WORD OF WARNING, I take ZERO responsibility with how running this on your Pyra turns out.
As it will probably result in lots of crashes, and needing to reflash your installation if you can't swap the dtb file out if it doesn't work for you.
This is a completely unlocked device tree file for booting your Pyra with all the clock frequency steps from 250Mhz to 2Ghz. Each step has a tuned voltage for it as well, all steps are stable for my Pyra, but doesn't mean it will be for you.
This device tree is only recommended for those of you who have experience with modifying the Pyra-thermal script, as that will dictate the speed which your Pyra runs at. If you change the Pyra-thermal script to max 2Ghz, and your device crashes, overheats, or no longer boots, you will need to boot from another media (from SD install, or from eMMC if you're using a SD card install image like me). I would not use this if you don't have a backup installation on your SD card or eMMC to swap out the dtb file if it fails in your system, as you won't be able to boot up the device to do it from a single install...
All you have to do to install the attached unlocked device tree is this:
Unzip the file, you will be left with a single file named omap5-letux-cortex15-v5.3+pyra-v5.3.dtb DO NOT RENAME THIS FILE unless you know WHY you are renaming it and have a preproduction Pyra that needs a different version device tree.
Navigate to /boot/dtb/linux-image-5.6.19-daveiii-pyradef-aufs in your Pyra's OS install, and back up the file with the SAME name as the one you are replacing.
Copy this to another folder. Don't lose this, as you will need it if things go wrong, otherwise you will need to reinstall your OS.
Place the unlocked omap5-letux-cortex15-v5.3+pyra-v5.3.dtb you downloaded into /boot/dtb/linux-image-5.6.19-daveiii-pyradef-aufs
Reboot. Profit.
If your device reboots, you should now have all the extra frequency steps, but the Pyra-thermal.sh script will dictate which one to limit to. You must modify this file (change the max frequency higher) if you want it to scale outside of normal frequencies.
If your device no longer boots after a hard reset, you will need to copy the backed up (you did back this up right?!!) omap5-letux-cortex15-v5.3+pyra-v5.3.dtb and place it back in the folder above, and overwrite the unlocked file.
To modify the Pyra-thermal.sh script, you will need to navigate to /usr/share/pyra/scripts
You can then add or edit entries for thermal scaling for the frequencies you want, and the maximum frequency which your pyra can run at.... No, unless you've modified the cooling, you probably can't run 2Ghz I assure you... I hardly can!
This is very much user dependent how you want to tune your device, so I'll leave this up to you to play with.
As always, make sure to create a backup if things to awry. But there is no compiling here, just edit, save and reboot, or restart the daemon.
I've included my current Pyra-thermal.sh to see what I've changed, (this will 99% not work for you, or be what you want..) but it's a good example of modifications.
Hey, I would love to get this into our new testing OS.
So from what I understand, all the frequencies have tweaked voltages. So Is it possible to get a version of the device tree that is capped to 1.5 GHz?
I'd love to provide something that is probably stable for most people but still will improve power draw.
I guess it was too much scrolling/searching?
I like granular frequency selection; so you can select the highest value stable for your Pyra.
Is 50MHz the smallest step we can use? Maybe smaller iterations in the top/max frequency would be nice, while we have larger steps at the bottom.
Taken literally, because 50 miliherz is too fine a step, and I doubt the hardware can be so fine tuned.
But you meant 50 MHz, of course.
I have no experience with a Pyra. My intuition would be that a 50MHz would not give user distiguishable results in performance, battery life or even stability. Other factors, like system load or ambient temperature could be more influential than a 2,5% change in frequency.
But I'm not sure. Also such a long scroll seems uncomfortable. Not a show stopper, just awkward. If another GUI lets the user just type the number or select from a 2 level menu tree or slide a ruler, or something easier, it might be better.
But I just wanted to add that I guess the operating points are read from a dtb, and dtbs allow overlays to be loaded at boot time, so one could offer several boot options to have more or less fine grained frequency selections available.
Not sure it's worth the effort, just noting the possibility.
I don't feel strongly for any solution, specially without a Pyra to test them, do as you please.
Taken literally, because 50 miliherz is too fine a step, and I doubt the hardware can be so fine tuned.
But you meant 50 MHz, of course.
I have no experience with a Pyra. My intuition would be that a 50MHz would not give user distiguishable results in performance, battery life or even stability. Other factors, like system load or ambient temperature could be more influential than a 2,5% change in frequency.
But I'm not sure. Also such a long scroll seems uncomfortable. Not a show stopper, just awkward. If another GUI lets the user just type the number or select from a 2 level menu tree or slide a ruler, or something easier, it might be better.
But I just wanted to add that I guess the operating points are read from a dtb, and dtbs allow overlays to be loaded at boot time, so one could offer several boot options to have more or less fine grained frequency selections available.
Not sure it's worth the effort, just noting the possibility.
I don't feel strongly for any solution, specially without a Pyra to test them, do as you please.
I am not talking about manual settings but about with what the governor can work with.
Yes, we are talking about MHz here.
So if we have more steps, we have more fine grained scaling.
I have no experience if that matters or if 125 MHz steps are enough.
Do not worry about the UI. We can make a proper one later. This is just to demonstrate which frequencies are available and that it actually works.
I will now go back to 125 steps and see what happens if I reduce the voltages.
It seems like I can reduce the voltages by a tiny bit for each frequency while maintaining a stable system.
Any idea how I can do a stress test for each frequency?
Just set the frequency manually and let it run for a bit?
Not sure if that is enough
I will do that approach with the 125 MHz steps OS.
First I'll poke around and see how low I can get.
After that I'll test the values on a bunch of Pyras. I have 36 ones here that do boot, so if I want to be serious, I can get quite a nice test sample to make sure they run stable
After that, I may or may not tweak the whole thing to run at 50 MHz steps and get the voltages by simple interpolation.
I do not expect much but maybe a little
Unfortunately I can confirm that this is a thing
Another funky thing I discovered is that playing with the voltages gave me some extremely whacky results. I think the variables in hex are allocated to something else in memory somehow. For example, one voltage modification hid all but 3 frequencies.. even though they are still in the file.. another attempt swapped the joystick to the mouse on the right. Another time didn't boot at all from the SD card and I had to manually backup the old dtb from the eMMC install.
I'm thinking that only larger step values (1300000 and not 1325000) are available.. but I'm not 100% sure.
I can set voltages to 750000, 740000 and 730000 for 250MHz. However, I can not do 735000. If I do those tiny steps, the frequencies are simply not available in the list and will not be utilized by the governor.
So apparently the smallest steps we can take is 50000 uV.
On the positive side, this at least makes the whole thing manageable. It's still a lot of MHz values to tweak, however there are only a couple of values viable for each step (3, maybe 4 at max I would estimate).
Further, if we want to get the values into the OS, we need to leave some buffer anyways, so probably the bigger steps won't hurt.
Anyways, we have to take what we have at hand and from my limited testing so far it seems like we can slightly tweak the voltages and reduce it for each frequency by 1000 or 2000 uV.
This process will take quite a while to finish but I am motivated
If anyone could tell me how to test his properly, feel free to leave a comment.
Is it enough to manually set the frequency or do I need to run a stress test for a few mins to make sure each voltage is stable?
I don't know. I suspect an stress test is needed. If the stress test fails, then discard the settings. If it passes, then still test usual daylife usage for three days or so ? But I don't know what would be good for an stress test.
There might not be a single answer, because each user may use their device differently and then need different settings. But I guess we want somethign that gives soem cofnidence nobody will find problems, hence the stress test.
Disable all frequencies except the single one I want to tweak
Figure out the lowest possible number at which it is stable
Once figured out, do a full boot/login cycle with only that one frequency
If successful, do a full boot cycle for 10 Pyras in total
If all Pyras make it through the boot/login/shutdown cycle without freeze, disable that frequency and move on to the next
This takes painfully long for 250 MHz but I finally made it to the end.
Once all values are figured out, I guess I'll throw my device tree into the wild and let people play around with it. If there are any more freezes, I'll up the values a tiny bit.
This will probably the best way to do this.
Okay, this sucks. I spent the whole day to figure out the minimum voltage at which each frequency boots stable.
It all fell apart once I tested multiple frequencies together.
It seems like when multiple frequencies are at play, the restrictions are much tighter.
Even though when each frequency/voltage on its own is stable, if multiple are available, things will freeze once again.
With single frequencies only, I was able to reduce the voltages by a little over 100 mV per frequency.
This will probably be way less significant in the end considering how unstable it all is.
EDIT:
Seems like I was a little too aggressive at the lower end.
It was mainly one specific Pyra that had issues.
I tweaked the values a little and added a few mV at the lower frequencies. That at least allows all my test Pyras to boot.
So there is hope after all.
Multiple frequencies however seem to be way more fragile than single ones.
For now I have working values for the 125 MHz steps.
My calculated values for 50 MHz steps cause immediate freeze. So I have to check that by hand once more.
However, for a start we should be good with 125 MHz steps, even though I want to provide 50 MHz steps in the end.
@johnicboom asked me to check for frequencies below 250 MHz and it seems 200 MHz does work.
However as long as in idle the OS still constantly runs at >250 MHz, we'd rather tweak the OS instead of lowering the frequencies.
Okay, this sucks. I spent the whole day to figure out the minimum voltage at which each frequency boots stable.
It all fell apart once I tested multiple frequencies together.
It seems like when multiple frequencies are at play, the restrictions are much tighter.
Even though when each frequency/voltage on its own is stable, if multiple are available, things will freeze once again.
With single frequencies only, I was able to reduce the voltages by a little over 100 mV per frequency.
This will probably be way less significant in the end considering how unstable it all is.
EDIT:
Seems like I was a little too aggressive at the lower end.
It was mainly one specific Pyra that had issues.
I tweaked the values a little and added a few mV at the lower frequencies. That at least allows all my test Pyras to boot.
So there is hope after all.
Multiple frequencies however seem to be way more fragile than single ones.
For now I have working values for the 125 MHz steps.
My calculated values for 50 MHz steps cause immediate freeze. So I have to check that by hand once more.
However, for a start we should be good with 125 MHz steps, even though I want to provide 50 MHz steps in the end.
@johnicboom asked me to check for frequencies below 250 MHz and it seems 200 MHz does work.
However as long as in idle the OS still constantly runs at >250 MHz, we'd rather tweak the OS instead of lowering the frequencies.
I can imagine the voltage requirements are higher when under full load. A boot sequence might be enough for testing this, but you might want to have a short load-test to have the CPU/RAM/Disk to be utilized at the same time if a boot isn't doing this already.
When finding a stable value you might want to increase it with 1 step higher to have a buffer for those kind of situations.
I can also imagine going to a higher frequency can be done quickly causing a short voltage drop and freezing the system. So if it's possible to increase the voltage a second before switching the frequency, you might be able to mitigate that situation.
I can also imagine if you log per Pyra when it locks up at the lowest frequency, you might be able to predict the voltage curve for all other frequencies. As I imagine there will be predictable curve.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
