RISC OS on Pi2 review on Youtube

The reason I went quiet the last couple of days over the temperature control question is due to meeting some oddities. I thought I had CPUTmpMon and CPUClock working together to throttle the cpu speed when the temperature rose. However, what I realised was that when the cpu fast speed was turned down a notch, the cpu actually went down to the slowest speed. This certainly reduced the cpu temperature, but was a little more drastic than I envisaged.

I spent a long time tracing and writing debug files but couldn’t see anything that was not functioning in the way I thought it should.

As far as I can see, when the cpu is running at its fast speed, and a Portable_Speed2 SWI is issued to put the speed down to the next lower one, the cpu actually goes into the slowest speed, although the wimp thinks it is still at the fast speed. It appears to stay in this state throughout the intensive activity even although the temperature has fallen enough for the speed to be clocked up again, but once this has finished and the wimp has gone into an idle state for a while (20 – 30 s?) it will then run at the fast speed when activity increases again.

I do not know whether it is an intentional or unintentional feature of a forced fast speed change using Portable_Speed2. When CPUClock is operating manually, it is very unlikely that the cpu will be running at fast speed when the speed setting is changed and so the effect would not be observed.

What I have now found is that if I issue a Portable_Speed SWI to explicitly switch the CPU back to fast speed after the speed change then things work as I intended. The switching between fast and slow is normally done by the wimp depending on activity. I am not sure if Jeffrey can shed any light on this.

The bottom line is – I now have the two progs working together to keep the temperature of the cpu within user defined limits, by reducing the cpu speed when the temp rises above the trigger point, and increasing it again when the temperature has dropped below the lower trigger point. CPUClock itself works on both BB and PB. There are two versions of CPUTmpMon, different for OMAP3 and OMAP4, and I have modified versions of both for use in this way.

I have also been in contact with the original author of CPUTmpMon and he is OK with me distributing these modified copies.

If anyone wants to give it a whirl please let me know (mail me at chris at chris hyphen johnson dot org dot uk).