Portable_Speed on Pi

Is it feasible to get the necessary HAL and kernel code to support Portable_Speed on the Pi? The latest firmware drops to 600MHz (unless force_turbo is set to 1 in CONFIG.TXT) and only goes up to normal speed (i.e. 700MHz on Pi, 900MHz on Pi2, 1000MHz on Pi0, 1200MHz on Pi3 or whatever speed is manually set in CONFIG.TXT) when the kernel tells the GPU it is under load.

Such control of processor speed is already present in RISC OS on the i.MX6, IGEPv5, Titanium and Pandaboard platforms and is also present in Linux on the Pi so there’s no new code to write.

Making this need more pressing is that the force_turbo command (necessary on the Pi Zero for it to run at its rated speed) appears broken on the Pi model 3 (AIUI).

Indeed. Just as the Pi2 in default mode is outperformed* by Pi’s A, B and 0 with force_turbo=1 set, so it appears the Pi3 is outdone by a suitably turbo’ed Pi2. As things stand I can see no merit in replacing a Pi2 with a 3 for RISC OS use, unless you really need wireless networking.
(*this is true IME of real-world tasks as well as benchmarks)

Yes, it’s certainly possible to get Portable_Speed working on the Pi – it’s “just” a case of using the mailbox property interface get/set clock messages to control the speed (probably in conjunction with the “get min” and “get max” messages so that we don’t have to keep a table of min/max rates for each Pi model). However we don’t have a proper way of sharing the mailboxes between multiple users (something that was originally planned for BCMSupport to provide that functionality), so to avoid conflicts with the video driver it would probably make sense to finally implement that module.

Since the Pi 1 (and Pi 2?) originally didn’t need any messing with the config file to get them to operate at the correct speed I’d mostly been ignoring the need for Portable_Speed on the Pi (overheating Pis hasn’t really been a problem, AFAIK). But now that the firmware doesn’t set the correct speed for most machines this has task has definitely moved to a higher priority on my todo list. But if someone else wants to have a go at implementing it then that’s fine too :-)

Given where we are, how simple would it be for the BCMVideo module to cope with a few things in the ‘ticker’ sync timing window, when it has nothing else to do (i.e. no screen mode changes, screen blanks etc.), so that it can listen for any mailbox requests from (e.g.) a Portable_Speed module and/or process any responses and make them visible to the Portable_Speed module – the Wimp message protocol may suffice for this. That way only BCMVideo needs to know whether mailbox is being used.

Since the Pi 1 (and Pi 2?) originally didn’t need any messing with the config file to get them to operate at the correct speed

Both Pi 2 and Pi 0 require adjustment of Config.txt to run at their nominal speeds (900 and 1000MHz respectively).

Putting the code directly in BCMVideo would work (there’s no need to mess around with Wimp messages or anything – just make BCMVideo be the one that implements the CPU clock HAL device). But in terms of keeping the code clean and leaving room for future expansion it would probably make more sense to just bite the bullet and implement the BCMSupport module. I don’t think there’s really going to be that much effort involved. A rough spec would probably be:

• SWIs to allocate and release buffers (these can just basically be wrappers for PCI_RAMAlloc/PCI_RAMFree)
• A SWI to queue a buffer, with options to either (a) call a callback on completion or (b) free the buffer on completion.
  • An option to queue a buffer and do nothing on completion probably doesn’t make much sense (if you don’t know the buffer has been processed, how can you tell when it’s safe to reuse or free the buffer?)
  • The queue SWI could also have the option to use a temporary buffer for the message (by first copying the message block from the stack or some other memory). This might allow for some slightly more optimal memory usage by the module (e.g. it sticks the messages into a simple ring buffer to avoid constantly calling PCI_RAMAlloc/PCI_RAMFree).
  • Potentially also have an option to block until the reply is received, so that code which needs a response immediately doesn’t have to implement its own sleep logic.

I’m fairly certain you can get an interrupt whenever the GPU writes a response to the mailbox, so all you need is a simple frontend for handling the SWIs and an IRQ handler which listens out for the replies and issues the callbacks. Bonus points if you make it multi-core safe ;-)

Copied over from the announcment’s thread ’cos this one is more active:
“I’m still waiting for my Pi 3 to arrive.

However, I thought I’d read over the over clocking configuration as I understand that force_turbo is not working as it used to with the Pi 3:
force_turbo

Just wondered if anyone had tried ‘arm_freq_min’ which sets the minimum frequency when not forcing turbo?"

Both Pi 2 and Pi 0 require adjustment of Config.txt to run at their nominal speeds (900 and 1000MHz respectively).

I think the key word is “originally”. As I understand it, the Pi 2 will run at 900 MHz when using older firmware (such as the version supplied with RC14). The problem is that the Pi 0 and 3 won’t boot with old firmware, and as the Pi 3 is a “mainstream” device it’s becoming much more important to sort it out.

As I understand it, the Pi 2 will run at 900 MHz when using older firmware (such as the version supplied with RC14)

My Raspberry Pi Mk2 responds to force_turbo=1 etc in CONFIG/TEXT with current firmware. It is only the Mk3 stuck in the slow lane here.

bootcode.bin  01Feb16
fixup.dat     04Mar16
start.elf     04Mar16

My Raspberry Pi Mk2 responds to force_turbo=1 etc in CONFIG/TEXT with current firmware.

Yep, but my post was about older firmware :)

Older firmware runs at the correct speed without any tweaks to CONFIG. Therefore older firmware is not an issue.

FYI I’ve now started work on the BCMSupport implementation. Primarily to see if it will help me get a working serial terminal with the Pi 3 (I need to be able to peek and poke things from the desktop to work out what they’ve done to the UART configuration), but you can expect to see a Portable_Speed implementation come out of it as well.

Excellent news. Your efforts are, as always, very much appreciated.

I guess with Portable_Speed implemented also apps like !CPUFreq would work “out of the box” on the Raspberry’s ?

Yes.

Excellent news. Your efforts are, as always, very much appreciated.

Amen to that!

but you can expect to see a Portable_Speed

I see a BCMSupport module has found its way into cvs. Does this mean explicit clocking settings in CONFIG/TXT to achieve a clock of 1200MHz will no longer be required? A local total understanding failure is the other possibility.

Does this mean explicit clocking settings in CONFIG/TXT to achieve a clock of 1200MHz will no longer be required?

Correct.

With no settings in config.txt, the firmware reports min/max speeds of 600MHz and 900MHz for the Pi 2 and 600MHz and 1200MHz for the Pi 3, which RISC OS will now use as the “slow” and “fast” speeds for Portable_Speed. For the Pi 1 it reports 700MHz for both the min and max speed, so no speed switching will be performed there. Not sure about the Pi Zero (I guess 700MHz and 1GHz?).

I’ve also hooked up the Portable_ReadSensor SWI for getting the SoC temperature

There’s also a spec document for BCMSupport in CVS

I don’t think this is working, the portable module does not seem to be able to increase the speed from 600MHz on the Raspberry Pi 3.

Using firmware :-

bootcode.bin  01Feb16
fixup.dat     24Mar16
start.elf     24Mar16

All the over-clocking lines were removed from CONFIG/TXT.

On rebooting the RPi3 the under-voltage warning appears and romark returns values associated with as clock of 600MHz.

This diagnostic :-

SYS "Portable_Speed2", 0 TO r0%
PRINT "Current CPU speed ";r0%
SYS "Portable_Speed2", 1 TO r0%,r1%
PRINT "min ";r0%;" max ";r1%

returns :-

Current CPU speed 600
min 600 max 1200

Re-enabling the avoid_warnings=2 stops the RPi3 from even starting.

Re-enabling both avoid_warnings=2 and force_turbo=1 allows the RPi3 to start returns romark values indicating 1200MHz and the dignostic above returns :-

Current CPU speed 1200
min 1200 max 1200

Neither !CPUClock nor !CPUFreq work, both
fall over with :-

*where
Address &FC1DDA68 is at offset &00000590 in module 'Portable'
<pre>
  

I am having trouble with this.

On a model B+ the call

SYS "Portable_Speed2",1 TO min%,max%

On a Pi Zero a slow/fast speed is returned of min%=700MHZ (slow) and max%=1000MHZ (fast) but I get an error ‘Abort on data transfer at &FC1DDA68 (offset &590 in module Portable)’ from the code:

SYS "Portable_Speed2",3 TO ,slow%,fast%

However if you want to try it, the necessary update to a plain RC14 SD card image has been packaged in a zip containing the rom (15:00 26-Mar-2013), the ZeroPain module, the !CPUFreq utility, updated firmware (Nov 2015 Edit: Mar-2016) and the necessary licence and readme files, the zip file can be downloaded here:
http://www.svrsig.org/software/Update3.zip
The ReadMe file contains a suggestion that you download a 2016-fixed ZeroPain from a given URL.

Contents are shown below:

On rebooting the RPi3 the under-voltage warning appears and romark returns values associated with as clock of 600MHz.

Yeah, I’m seeing that issue here. I was using some older firmware on my Pi 3 (1st March), which wasn’t showing the under-voltage warning, so by the lack of error codes being returned by the firmware I assumed the speed switching was working. But closer inspection reveals that it wasn’t (Pi 2 works fine), and updating to the latest firmware gives me the under-volt warning.

Measuring the voltage across a couple of GPIO pins shows 5.13V, so I’m not sure where this under-voltage warning is coming from – I’ll have to investigate further.

Neither !CPUClock nor !CPUFreq work, both
fall over with :-

*where

Address &FC1DDA68 is at offset &00000590 in module ‘Portable’

Sorry about that – looks like there were a couple of places where Portable_Speed2 wasn’t preserving R12 across HAL calls. Should be fixed with tomorrow’s ROM.

I am having trouble with this.

On a model B+ the call

SYS “Portable_Speed2”,1 TO min%,max%

gives both min% and max% as 700MHz hence giving the error ‘speed switching is not implemented on this platform’ with !CPUFreq.

That’s to be expected – for the Pi 1 the firmware reports that 700MHz is the only supported speed.

Ah! Snap! That’s much better – it now works on the Pi Zero – you can see the speed switching from 700MHz to and from 1000MHz, with no overclocking stuff in CONFIG.SYS at all. The download has been updated with a rom containing the fixed BCMSupport/PortableHAL files [and the ‘latest’ 1-Mar-2016 firmware] so it should now work. I’d include the non-expiring ZeroPain module but that’s not mine to include, I am advised that the rest is all in accordance with the licensing (providing the licence files are all intact, which they are).

On the Pi model 3 [with March 2016 firmware rather than Nov 2015] you can see the speed switching from 600MHz to 1200MHz.

On the Pi model 2 B you can see the speed switching between 600MHz and 900MHz.

Many thanks to Jeffrey for his work on this matter.

Measuring the voltage across a couple of GPIO pins shows 5.13V, so I’m not sure where this under-voltage warning is coming from – I’ll have to investigate further.

Looks like this was being caused by the IIC initialisation code altering the pin mux settings for some pins which are related to the old IIC bus (the one which was used on the Pi 1 rev 1.0 PCB) – on the Pi 3 it looks like they’ve reused those pins for power control/under-volt detection. After fixing that my Pi 3 is no longer showing the under-volt warning and is happily switching speeds without any config.txt settings.

I didn’t get the under volt warning on my Pi 3 (I have 1-Mar-2016 firmware) so the pin mux changes presumably post date 1-Mar-2016?

I have no idea. I was originally using firmware from March 1st as well – that wasn’t showing the under volt warning visibly but it was refusing to change CPU speed.