Portable_Speed on Pi

My Pi 3 and Pi 0 both say they are switching CPU speed but seem (using benchmarks) to be running, actually, at an unchanged speed, whichever setting they are on. Puzzled.

For example using CPUClock and setting both high speed and low speed to the same value = 600MHz on the model 2 it shows current speed=900MHz (!CPUFreq shows 600MHz) and benchmarks give the same value as when low speed and high speed are both set to 900.
Very puzzled.

After fixing that my Pi 3 is no longer showing the under-volt warning and is happily switching speeds without any config.txt settings.

Same here now. On the RPi3 with today’s (27 Mar 2016) Pi ROM and with all over-clocking paraphernalia removed from CONFIG/TXT the spurious under-voltage warning is gone, fast/slow switching can clearly be seen with !CPUFreq and benchmarks reflect 1200MHz.

Nice, many thanks Jeffrey.

Might this have had some relevance to RPi3 issues.

My Pi 3 and Pi 0 both say they are switching CPU speed but seem (using benchmarks) to be running, actually, at an unchanged speed, whichever setting they are on. Puzzled.

I think the problem is with !CPUClock – it ‘allows’ you to set the slow speed to any of the available speeds including the fastest (so long as it is not greater than the currently set ‘fast’ speed) – whereas !CPUFreq only allows you to set the slow speed to any of the available speeds excluding the currently set ‘fast’ speed or anything faster. Then after setting the slow and fast speeds both to (say) 600MHz using !CPUClock it (corectly) reports an actual speed of 1200MHz (as it is not idle). However there is also a problem with Portable_Speed2 because it thinks that the illegal speed settings have been effective and reports both slow and fast speed as the same MHz value whereas Portable_Speed will still be switching between fast and slow as originally defined.

Explicitly setting the slow or fast speed using “Portable_Speed” gives slow benchmarks or fast benchmarks as you select.

I think the problem is with !CPUClock

What version is being used? I am pretty sure that in version 1.2, the menu selections are greyed out so you cannot make fast and slow the same. The same is true for version 2.00 (not yet released other than to testers because I am waiting for a SWI chunk allocation from ROOL). The core functionality of temperature measurement and auto cpu speed regulation is now in a module, which means the temperature monitoring and speed regulation will continue even when the wimp is not polling.

Version 2 requires RISC OS later than Jan 6th (when Willi Theiss added a new API) for complete functionality, preferably later than Mar 6th, when a couple of bugs in Portable_Speed2 were fixed by Willi. Version 2 works on OMAP3, OMAP4 and OMAP5. It doesn’t work fully on iMX6 (recent OS from R-Comp) because the Portable_ReadSensor SWI is not fully implemented, so the cpu die temperature is not available. It will, however, work as a simple CPU speed display and set fast and slow speeds. I have no idea yet about the Raspberry Pi.

If anyone wants the latest test version (on the understanding that the current SWI chunk base is a random value from the ‘user’ block), let me know. I will put it on my web site if there is enough interest. (chris at chrisjohnson dot plus dot com).

Version 1.01, the latest version from !Store.

I also note that if I add overclocking for the model B2

arm_freq=1000
gpu_freq=300
core_freq=450
sdram_freq=450

(but not force_turbo) then the speed switching via Portable_Speed appears to work but in fact the faster speed (1000MHz) is what the processor runs at, despite running a single-tasking benchmark programme which explicitly selects slow speed by SYS “Portable_Speed”,1,0. Portable_Speed and Portable_Speed2 think they are working but the processor runs flat out throughout. Removing those extra commands from CONFIG/TXT means that the model B2 correctly switches between 600 and 900MHz, confirmed by benchmarks.

Since the BCMVideo and BCMSupport changes, the screen on the Pi Zero occasionally breaks up. ROOL do have a Pi Zero (I donated one at the show).

Benchmarks updated to include speed switching on the Raspberry Pi.

I have updated the download (which converts an RC14 SD card image to the latest suitable ROM, all done under RISC OS) to include 29-Mar-2016 firmware and ROM, with no overclocking commands required, suitable for all models of Pi but, ideally, you should add a kludged ZeroPain module in place of the unkludged one, instructions provided. This update is not yet stable on the Pi model 3 as some of the applications provided with RC14 do not run on ARMv8 and will need recompiling.

If you want to use the last 2015 ROM on the Zero, then the earlier download should be used (which is explained at some length in Archive magazine 24:1, which should appear in the next week or so). It uses explicit overclocking commands to run at 1000Mhz continuously but has an ‘official’ version of ZeroPain which logs errors rather than aborts on them.

Both downloads have instructions with them.

Version 2 requires RISC OS later than Jan 6th (when Willi Theiss added a new API) for complete functionality, preferably later than Mar 6th, when a couple of bugs in Portable_Speed2 were fixed by Willi. Version 2 works on OMAP3, OMAP4 and OMAP5. It doesn’t work fully on iMX6 (recent OS from R-Comp) because the Portable_ReadSensor SWI is not fully implemented, so the cpu die temperature is not available. It will, however, work as a simple CPU speed display and set fast and slow speeds. I have no idea yet about the Raspberry Pi.

The Pi supports Portable_ReadSensor now. However the firmware has its own logic for scaling the clock speeds when temperature limits are reached or in under-voltage conditions, so automatic scaling by !CPUClock may be redundant.

Maybe it would be worth adding a flag to Portable_ReadFeatures to indicate that the firmware/OS does its own temperature-related clock scaling.

… the speed switching via Portable_Speed appears to work but in fact the faster speed (1000MHz) is what the processor runs at, despite running a single-tasking benchmark programme which explicitly selects slow speed by SYS “Portable_Speed”,1,0.

Odd. Maybe for safety reasons it ignores any requests made by the CPU if clock settings are specified in the config file.

Although you could try also specifying arm_freq_min, core_freq_min and sdram_freq_min – maybe that will allow CPU switching to work again.

Since the BCMVideo and BCMSupport changes, the screen on the Pi Zero occasionally breaks up.

“Break ups” how?

Odd. Maybe for safety reasons it ignores any requests made by the CPU if clock settings are specified in the config file.

Although you could try also specifying arm_freq_min, core_freq_min and sdram_freq_min – maybe that will allow CPU switching to work again.

I’ve found the solution – you were right – if you set arm_freq=1000 you also need arm_freq_min=600 for the CPU to switch speed. Without the arm_freq_min setting Portable_Speed thinks it can change speed but SYS “Portable_Speed”,1,0 (to set slow speed) will not work. Edit: That is it ignores SYS “Portable_Speed”,n,0 except internally within Portable_Speed and Portable_Speed2 where it tracks whether it has asked for ‘slow’ or ‘fast’ speed and what that speed would be.

How?

Every so often the screen err. breaks up – either goes blank for a fraction of a second and come back or ‘crackles’. I think this may be when there are a lot of Portable_Speed2 calls going on, e.g. from !CPUFreq. CPUFreq makes a

Perhaps I should set arm_freq_max rather than arm_freq?

I don’t think there’s an arm_freq_max (or at least not according to the wiki)

Every so often the screen err. breaks up – either goes blank for a fraction of a second and come back or ‘crackles’. I think this may be when there are a lot of Portable_Speed2 calls going on, e.g. from !CPUFreq.

Try using config_hdmi_boost – sounds like the signal strength is a bit on the weak side for your monitor. On my Pi 1 I had to set it to about 6 or 7 to get an image using the monitor I was using at the time.

You beat me to it (I edited the post you replied to while you were writing your reply)! All the other Pi models seem to work without the screen breaking up. On the Zero config_hdmi_boost=7 seems to stop the screen breaking up after the changes to BCMVideo (before that it didn’t break up).

I have been a bit sidetracked with life, so the full release of CPUClock is not quite ready. In view of this I have put a beta version on my web site. This is a fully functional version, but is beta because

+ The help files have not been completed
+ I have not finally decided how much of the module functionality to expose to the user in the GUI front end

This new version runs (TTBOMK) on OMAP3, OMAP4, OMAP5, and Titanium. As far as the iMX6 goes, the latest ROM (18th Mar) does not have all the recent additions that the others have. Therefore for the auto-control, etc, you should stick with V. 1.10 of CPUClock. This should also be used if your OS is pre-2016.

The various versions can be found at

http://www.chris-johnson.org.uk/software/cpuclock.html

I hope to have the full version 2 release ready within a few days.