It strikes me as a bit of a faff if the unit continually ramps the cpu freq down then back up again until it starts cooking. Would it be better if it tried to find a happy medium for the workload in use? I guess completely untrained or long term stateless code will have to start with a ramp down from top, but it could then start raising the cpu freq by stages until the temp starts jumping up then back off by one. If it can be trained and stores state in a config file or something more persistent, then maybe it can do a better estimate for the workload and back off as soon as it notices you're doing something with a similar load to what it previously noted, and go from there. I guess to be really effective, this approach should be tackled after you've added more steps to the frequencies the chip will accept.
Does anyone know which Device tree the Pyra boots with? There is about 10 Pyra related dtb's in the boot folder.. I see the EVM ones are probably the Ti evaluation board.. but I'm not sure which one is currently used, or how to find that out. I've tried searching all the configs and files, but no dice. Any pointers would be awesome!
@aTc would know for sure, it's been a while since I looked into it. I did some modifications in the past, including hacking back in some of the lower CPU speeds when they locked it to only 1GHz or 1.5GHz, but that was 4-5 years ago
@aTc would know for sure, it's been a while since I looked into it. I did some modifications in the past, including hacking back in some of the lower CPU speeds when they locked it to only 1GHz or 1.5GHz, but that was 4-5 years ago
I'd appreciate it if he could point me in the correct direction.
I'd decompiled a couple of them, and I figured out how the clocks are setup and derived, so that's the easy part. I just need to figure out which file is pointed to, and maybe WHAT is point to it.. is there like a config file in the boot loader or something that tells it which dtb to use?
Yes, I guess it's specfied in the bootloader. If the Pyra is akin to the Pandora in that respect, look for a file called autoboot.txt in either the boot folder or the system root
Sometimes is in /boot/uEnv.txt or even /boot/boot.scr (that's a text file but passed through mkimage to headers or something, usually still readable).
I don't know how the system in the Pyra is set up.
I'd appreciate it if he could point me in the correct direction.
I'd decompiled a couple of them, and I figured out how the clocks are setup and derived, so that's the easy part. I just need to figure out which file is pointed to, and maybe WHAT is point to it.. is there like a config file in the boot loader or something that tells it which dtb to use?
The devicetree is selected by u-boot. It reads the version info from some resistors on the main and cpu boards, then selects the right dtb for that hardware.
It shows the detected version on the serial output, in my case :
HW Revision: CPU: v5.3 Mainboard: v5.2
Which it then turns into omap5-letux-cortex15-v5.3+pyra-v5.2.dtb
I have a slightly older mainboard, but all the production models out there should be v5.3/v5.3, so the dtb used for everyone else is omap5-letux-cortex15-v5.3+pyra-v5.3.dtb
The devicetree is selected by u-boot. It reads the version info from some resistors on the main and cpu boards, then selects the right dtb for that hardware.
It shows the detected version on the serial output, in my case :
HW Revision: CPU: v5.3 Mainboard: v5.2
Which it then turns into omap5-letux-cortex15-v5.3+pyra-v5.2.dtb
I have a slightly older mainboard, but all the production models out there should be v5.3/v5.3, so the dtb used for everyone else is omap5-letux-cortex15-v5.3+pyra-v5.3.dtb
VERY interesting to see the clock frequency nesting at these new frequencies.. 375Mhz and 625Mhz are slotted quite a bit, when normally they would have called for a higher frequency. All the voltage steps are scaled too, so the half steps split the vCore between the others for power savings.
Overclocking is now back on the menu. I didn't add 1.7Ghz yet, because I wanted to see if it would crash/freeze at anything higher than 1.5Ghz. Though 1.6Ghz works and is used on intensive load, I ran a YouTube stream in the background for about 25 minutes to see how the On-Demand governerner works with this many options, and it does a very good job.
I'm going to add 1125Mhz and 1.7Ghz to round out the table.
Edit: I'm also interested in bumping the clocks for the DDR, as well as the SGX544. I think they work off of a internal multiplier setup though using the ti,clocks struct.. I'll have to read the Technical reference manual for the chip to figure that one out.. but I recall people many years ago on XDA overclocking the SGX544 a good chunk. Anything to help the OpenGL situation in my eyes is welcome. Plus, with such a large fab node these chips are on, unless the silicon quality is garbage, I'd think there should be some meat on the bone regarding clock gains..
One interesting flexibility I've noticed over doing this on the Pandora, is I have control over the voltages on each step and ti,clocks which will allow us to have VERY refined control over most components as far as tunability. I haven't even played with lowering voltages yet, perhaps this automotive chip is just left at a higher Vcc for long term stability.. unless someone has tested, there could be 100+mV of offset to be had. Most 45nm Intel chips I've had usually had 100-200mV of undervolting overhead, who knows if that's here.. that could be a game changer if we have stability.
Well, were back at "stock" clocks now. No instability or problems to report, I'm using 1.35vCore to achieve that.. max voltage for the chip is 1.5vCore. which makes sense as that's roughly enough voltage steps to hit 2Ghz.
I'd like to start backing down the core voltages across all the freq steps by 25mV until something starts breaking. I have a strong feeling my vCore steps are very liberal with the power associated to the corresponding freq.
I haven't added in fans yet, and everything is still passive. So I'd say the results are pretty good so far. Once I get the fan situation sorted, I'll see what the cieling is for clock speed. I'm currently testing power consumption and sound with an external eeprom programmer I had laying around that have the voltages needed. Easy plug and play solution.
I played Faster Than Light (Box86 with GL4ES through Ubuntu i386 Steam) and Open arena for over an hour with no problems.
I think once I do a little more extensive testing I'll open a new thread for folks to download and run the "unlocked" clock version. Then they can report issues, crashes, thermals, etc. What's nice, is that even though most Pyras will never be capable of running these speeds without cooling mods; you can have clocks be manipulated by the Pyra Thermal script.. so technically, you could modify the clock to scale up to a "turbo boost" speed for a few seconds then throttle back down for normal use. Might be useful for launching apps, or loading up something, and not have to do any sort of cooling mod. There's not a snowballs chance, they will be playing any hardcore application at 1.7Ghz or whatever, but for 5-10 seconds I'd think it could be fine.
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.
Certainly unrealistic as this requires a hefty boost in vCore to attain.. which makes the temperatures unmanageable outside of short term clock boost, especially on a stock Pyra.. but holy crap does this thing load fast at 2Ghz. I think 1.7-1.8Ghz is the sweet spot, and I believe I can run those clocks on a lower voltage. Web pages and tabs are close to instantly opening. This will require an extraordinary cooling system, but I have an idea about that.
1500Mhz-1900Mhz are ALL stable at 1.35v on the core voltage.. which means the lower end of this range can probably run at 1.25v or 1.3v. 2Ghz requires a bump up to 1.45v, and 1.4v would cause instability at boot.
The Sunon fans have resided in my Pyra, but are no longer installed. The blowers are simply too loud in my opinion. The Axials are pretty quiet, but I haven't figured out a axial setup yet. I have an idea to combat the airflow and the sound problem, but it will require some "rework" and modeling to make work. As I don't have any STL files for the case, I'll have to make it manually, but it's not impossible to do, stay tuned as I think if this works it will likely be a breakthrough for cooling.
The reason why this process takes so long is that I try to use and test each step in clocks so I know what works and doesn't work without taking huge shots in the dark. Also, essentially all of the testing so far is still on a Passively cooled Pyra, albiet with a beefed up heatsink and thermal material setup.
The Sunon fans have resided in my Pyra, but are no longer installed. The blowers are simply too loud in my opinion. The Axials are pretty quiet, but I haven't figured out a axial setup yet. I have an idea to combat the airflow and the sound problem, but it will require some "rework" and modeling to make work. As I don't have any STL files for the case, I'll have to make it manually, but it's not impossible to do, stay tuned as I think if this works it will likely be a breakthrough for cooling.
I did! They have some very interesting options! I've considered having a custom heatsink made that fills all the airgaps in the case.. but I can't do anything with that level of precision at this point without a model to go off of. Otherwise I'd have to create a mold with some kind of material and measure off that to translate into solid works.
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.
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.
