Knocking back the speed?

Hi,

It is nearly 30C in my bedroom. As a person who works in a refrigerated factory, this is stifling. In addition to this, my eeePC and Beagle are both running rather warm.

My eeePC I can handle, it runs around 65C but if I feel it getting too hot (and damn, those SSDs warm up like you wouldn’t believe – and here I thought it would be the x86 that melts the casing!), I can run “eeectl” and hijack the fan controller to max it to 100%. That keeps it cool.

The Beagle, on the other hand, gets close to 60C in RISC OS while doing nothing. I believe it is further complicated by being a POP so may be more susceptible to thermal issues (consider how a bimetallic switch works!). A fan isn’t really practicable, and I don’t think a heatsink would be a lot of use as it would sit on the memory.

Thus my question – is it possible to artificially knock back the speed of the OMAP to hopefully work on slower = cooler ?

…just looked around. Would Portable_Speed be what I’m looking for? I’ll try this on Saturday.

Thus my question – is it possible to artificially knock back the speed of the OMAP to hopefully work on slower = cooler ?

I’ve still not figured out whether the u-boot settings delivered through uEnv get overridden by the RO image. IIRC speed is defaulted to auto, which presumably means the OS can then pass through changes.

From observation of the temperature monitored by CPUTemp simply blowing across the package drops the temperature from 63C to 57C so any small fan would probably do. I have a 17mm unit for fitting in the LTO3 tape case. 25mm units are easy to find. Discussions elsewhere have centred on how to find a small enough heatsink if you go that route – maybe a voltage regulator heatsink would do.

I do not know exactly, but I think the SmartFlex driver set the speed on the required performance. Who just turned my computer standing around and not the temperature rises. That is why Jeffreys tool to set the speed not works. A problem for my A4xM. On the Pandora and my BB C4 can I set the clock yet.
The fan in the ARMini is from the manufacturer of the case built in suction. Turn around to blow bring an improvement.
Unfortunately, different fans were used. I run my 12V fan at 5V. Enough and is pretty quiet.

Temperatures around 60 degrees may sound (and feel) hot, but the OMAP is actually rated to operate at (internal) temperatures of up to around 100 degrees – so apart from the possibility of burning your finger when touching the chip there’s nothing much to worry about with how things are at the moment.

I’ve still not figured out whether the u-boot settings delivered through uEnv get overridden by the RO image.

RISC OS completely ignores whatever speed settings u-boot specifies.

RISC OS does several things to control the speed of the CPU:

• There’s the CPU clock driver sitting in the HAL. This allows the Portable module to change the clock speed between a number of preset settings (referred to as "OPP"s in TI’s docs). Each OPP defines a clock speed and core voltage. Although the hardware is capable of using arbitrary clock speeds and voltages, TI’s docs suggest that sticking to the standard OPPs is the best in terms of reducing heat/power drain. On BB-xM the clock driver also makes use of SmartReflex, which allows the hardware to fine-tune the core voltage in real time, typically resulting in a lower voltage being used than that specified by the OPP.
• In terms of how this all hooks into RISC OS, Portable_Speed, which is the original speed control SWI that was used by the A4, is used to select between preselected “fast” and “slow” speeds. Portable_Speed2 is a new SWI which allows the available speeds to be enumerated, and selection of which speed is the fast one and which is the slow one. By default the fastest speed (1GHz for xM, 600/720MHz for BB) is chosen as the “fast” one and the slowest speed (300MHz for xM, 125MHz? for BB) is chosen as the “slow” one. The main user of Portable_Speed is the Wimp, which will switch the CPU to the slow speed if it thinks the machine is idle. I think it’s still using the same logic that was around at the time of the A4, so it’s possible it’s a bit broken now, but last time I checked it was working OK.
• The Portable module also provides wait-for-idle functionality (Portable_Idle), which allows the CPU to be put to sleep until the next interrupt. Portable_Idle is a new SWI that was added for the Stork, and due to the cancellation of the project it probably isn’t being used in all the places that it could be. However the Wimp does know how to use it, as well as a couple of other places (e.g. OS_Byte 19 & OS_ReadC), so if you’re sat idling in the desktop the machine should spend most of its time with the CPU halted.
• My old “opp.bas” BASIC program which Raik mentions has been deprecated for some time, since the Portable module now expects to be in full control of the CPU clock. The way the Wimp and other bits of the OS switch between slow & fast speeds means that any speed the user’s set manually will get overridden pretty quickly.
• If you want to force the CPU to run at a particular speed, the recommended way is to use Portable_Speed2 to set the slow & fast speeds to the desired values. There’s nothing in the OS that will override these settings, and neither do I intend to add anything that will do so.

Of course it’s worth pointing out that controlling the CPU speed is only one part of the story – pretty much every part of the SoC can be powered up and down or switched to different power levels as required, but at the moment there’s no framework within RISC OS to control any of this. E.g. I suspect we’d be able to get some significant heat/power reduction if we were able to switch the VDD2 domain (which handles the main bus/interconnect) to a lower OPP. But since so many things are dependent on the VDD2 power/clocks it will require a fair amount of work to get the OS to switch it to a different OPP without everything going tits-up.

From http://www.ti.com/lit/ds/symlink/omap4460.pdf (Pandaboard ES)
For reliability and operability concerns, the absolute maximum junction temperature of OMAP4460 has to be below 125ºC and the maximum average junction temperature has to be below 110ºC.

For the Beagleboard processor I can find something like a maximum junction temperature of 90ºC when not overclocked (OPP1 – OPP4).

Of course it’s worth pointing out that controlling the CPU speed is only one part of the story – pretty much every part of the SoC can be powered up and down or switched to different power levels as required, but at the moment there’s no framework within RISC OS to control any of this. E.g. I suspect we’d be able to get some significant heat/power reduction if we were able to switch the VDD2 domain (which handles the main bus/interconnect) to a lower OPP. But since so many things are dependent on the VDD2 power/clocks it will require a fair amount of work to get the OS to switch it to a different OPP without everything going tits-up.

Useful info, worth a hobby electronics twiddle (ignoring the rather old electronic engineering education)
Go and work at a beer festival for a couple of weeks or read a bit, interesting choice.

(Pandaboard ES) For reliability and operability concerns, the absolute maximum junction temperature of OMAP4460 has to be below 125ºC and the maximum average junction temperature has to be below 110ºC.

But see table ‘Recommended Operating Conditions’ in the linked manual on page 128, Note (7) ‘Maximum supported junction temperature in functional operating condition is 110°C. That does not mean that 110°C of junction temperature is supported continuously.’
And don’t forget these values are for a naked OMAP4460. At the pandaboard (and as far as I know at the beagleboard) there is the memory-chip on top of the OMAP. So the max. temperature should be less than 110°.

there is the memory-chip on top of the OMAP.

That was my main concern. Not so much “how hot can the OMAP get” but rather how much heat (and temperature cycling) can the POP arrangement cope with without risking potential physical degradation due to thermal size changes.

As I said, think of a bimetallic strip…

I am about to embark on heatsinking for my PandaBoard ES as, given the current inclement weather here in London, it is beginning to run a bit too hot.

The temperature monitoring software is telling me that we’re aroung the 77-78 degree mark right now – generally things start to get a bit unstable above 75…

…Running the OMAP at 1.5GHz might also contribute ;-)

I fitted one of those small aluminium heatsinks to my BB-xM. While it did make an improvement I still saw temperatures well in excess of 70 degree. Either a more elaborate setup like a heat pipe is needed or a small fan. Would’ve preferred to do without! I wonder why my more powerful Tegra 2 tablet gets away without :-(

A large fan at 5 V works better. A large fan at 5 V and small aluminium heatsink are keeping my Pandaboard between 35 and 50 °C with almost no sound.

For amusement, I have knocked together a small app that will show the values of the cpu fast and slow settings, and the current speed of the cpu as it is switched between the two values. It also allows you to reduce the fast setting. It is not yet on my web site – there is still a bit of polishing to do, but if anyone would like a copy to try let me know (chris at chrisjohnson dot plus dot com) and I will send you a zip file.

I should have added that I was hoping to extract some details from Jeffrey’s excellent description above to include in the help file (with attribution). I hope Jeffrey has no objection.

I hope Jeffrey has no objection.

Fine by me. I look forward to seeing the finished plugin!

When I wrote the speed switching code I did add a (debug-only) feature to the Portable module to measure how much time was spent in the fast & slow states, how much time is spent waiting in Portable_Idle, etc. I wonder if it would be worth finding a way of making those features available in non-debug builds of the module, as it would be a cleaner/more accurate way of getting stats via other means.

I think the only thing that’s stopping it from being enabled is that we still need to implement/ratify a method for controlling access to HAL timers. Although it’s not mentioned in the thread, I think that after chatting with Ben about it over email we came to the agreement that using service calls to claim/release timers was the most appropriate way of doing things.

The CPUClock app seems to have been working fine on various flavours of BeagleBoard. The Panda ROM doesn’t have the Portable_Speed2 SWI fully implemented yet, so it isn’t much use on that at the moment.