Portable_Speed on Pi
Pages: 1 2
Chris Hall (132) 3554 posts |
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). |
George T. Greenfield (154) 748 posts |
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. |
Jeffrey Lee (213) 6048 posts |
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 :-) |
Chris Hall (132) 3554 posts |
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. |
George T. Greenfield (154) 748 posts |
Both Pi 2 and Pi 0 require adjustment of Config.txt to run at their nominal speeds (900 and 1000MHz respectively). |
Jeffrey Lee (213) 6048 posts |
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:
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 ;-) |
Anthony Vaughan Bartram (2454) 457 posts |
Copied over from the announcment’s thread ’cos this one is more active: 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: Just wondered if anyone had tried ‘arm_freq_min’ which sets the minimum frequency when not forcing turbo?" |
Chris Mahoney (1684) 2165 posts |
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. |
David Pitt (102) 743 posts |
My Raspberry Pi Mk2 responds to bootcode.bin 01Feb16 fixup.dat 04Mar16 start.elf 04Mar16 |
Chris Mahoney (1684) 2165 posts |
Yep, but my post was about older firmware :) |
Chris Hall (132) 3554 posts |
Older firmware runs at the correct speed without any tweaks to CONFIG. Therefore older firmware is not an issue. |
Jeffrey Lee (213) 6048 posts |
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. |
Chris Hall (132) 3554 posts |
Excellent news. Your efforts are, as always, very much appreciated. |
Kuemmel (439) 384 posts |
I guess with Portable_Speed implemented also apps like !CPUFreq would work “out of the box” on the Raspberry’s ? |
Jeffrey Lee (213) 6048 posts |
Yes. |
George T. Greenfield (154) 748 posts |
Amen to that! |
David Pitt (102) 743 posts |
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. |
Jeffrey Lee (213) 6048 posts |
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 |
David Pitt (102) 743 posts |
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 Re-enabling both Current CPU speed 1200 min 1200 max 1200 Neither *where Address &FC1DDA68 is at offset &00000590 in module 'Portable' <pre> |
Chris Hall (132) 3554 posts |
I am having trouble with this. On a model B+ the call
gives both min% and max% as 700MHz (edit: and I now realise that this is what you intended) hence giving the error ‘speed switching is not implemented on this platform’ with !CPUFreq (edit: which is what it should do). 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:
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: Contents are shown below: |
Jeffrey Lee (213) 6048 posts |
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 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. That’s to be expected – for the Pi 1 the firmware reports that 700MHz is the only supported speed. |
Chris Hall (132) 3554 posts |
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. |
Jeffrey Lee (213) 6048 posts |
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. |
Chris Hall (132) 3554 posts |
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? |
Jeffrey Lee (213) 6048 posts |
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. |
Pages: 1 2