Dynamic clock switching on Pi

How do I update my RC14 SD card to allow dynamic speed switching and to work on all models Zero, 1, 2 and 3?

An update zip file containing the latest firmware (BOOTCODE.BIN, FIXUP.DAT and START.ELF) a recent RISC OS ROM, the ZeroPain module (where required) and a utility to display clock speed can be downloaded. Two versions are available – one which has a high processor vector build and requires you to download a kludged version of the ZeroPain module separately if you want to permit zero page access without aborting. It also has the drawback that Aemulor will not work. The other has a low processor vector build of RISC OS and thus does not need ZeroPain at all, Aemulor (which on the Pi is a paid-for upgrade) will work, as will LanMan98 version 2.05.

Note that speed switching on the Pi model 1 is not implemented.

Simply download the zip file under RISC OS, open it using !SparkFS and follow the instructions to copy the !Boot directory in the archive over your !Boot directory on the SD card making sure the copy options are set to Force and not to Newer and that DOSFS has been seen.

High vector build – this uses 1 Mar 2016 firmware and 26-Mar-2016 ZPP ROM.

Kludged ZeroPain – with thanks to Rick Murray

Special low vector build – this uses 26-Mar-2016 firmware and 26-Mar-2016 non-ZPP ROM.

What is provided in the zip file?

A picture speaks more than words so I have included a vector graphic showing the contents in a tree-like display (produced by !Cat) here .

What if you are starting afresh with just a Zero?

You will need to wait until ROOL update the RC14 SD card image to cope with the Pi Zero – this requires testing and may take some time.

What if you don’t like the idea of a ‘kludged’ ZeroPain module and have a Pi Zero – any ideas?

There is a version of the same zip file that will work on the Pi Zero without speed switching and using a 2015 ROM (so that the ‘standard’ ZeroPain module will do all you need). It is only suitable for the Zero and will force a continuous speed of 1000MHz. Download it here – this uses November 2015 firmware and a 20-Dec-2015 ROM build, with the official ZeroPain module.

How do I know whether I am using a low vector or high vector ROM?

Use the programme below.

>LIST
   10REM >HiVector
   20hv%=1
   30ON ERROR hv%=0:IF ERR=&1E6 THEN PRINT "pre RISC OS 3.70"
   40IF hv% THEN SYS "OS_PlatformFeatures",0 TO hv%
   50IF hv% AND (1<<20) THEN PRINT "High vectors" ELSE PRINT "Low vectors"
>RUN
Low vectors
>

How do I know it is working?

Use the utility !CPUFreq – this will display the CPU speed and will switch between ‘low’ and ‘high’ if you SELECT or ADJUST click its icon bar icon. It will switch into high speed if you click the mouse anywhere else a few times, then switch back to low speed if you do nothing.

What if I don’t like the idea of tinkering with the image directory !Boot.Loader?

It is not without risk. Wait for an official ROOL release.

Simply download the zip file under RISC OS

Attempted downloads of both high- and low-vector versions of the software fails with the message ‘Application Error (Rails)’, using both NetSurf (Dev CI #3448) and Otter, under RISC OS.

The URLs are missing the protocol. They should be high and low (and ZeroPain).

According to the ReadMe file, the DOSFS module needs to be ‘seen’: *ROMModules reports it as ‘active’ – is that OK? If not, what is the procedure?

I’ve tried the low vectors version of the ROM and firmware with my Lapdock enabled Pi Model 1 and I get a garbled screen and an unusable system. I have also just tried the latest firmware only and get the same effect so I’m not sure if the lapdock can work with the current firmware?

When I get time I’ll try the Pi, san Lapdock, to see if it is Lapdock specific or not.

So currently back to RC14 firmware and updated 4th July 15 ROM.

According to the ReadMe file, the DOSFS module needs to be ‘seen’:

Solved the problem by shift-clicking over the unzipped low-vector !Boot file, as supplied, and copying the contents of the new Loader directory manually over my existing Boot.Loader files. I had to add back the ‘hdmi_group=2’ and ‘hdmi_mode=82’ lines into Config.txt to make the Pi2 work properly with my Benq monitor – others may have a similar issue. Everything seems to be working as advertised; CPUFreq shows the speed switching between 600 and 1000MHz according to load, and !Firebench shows a slight speed-up (9.48 vs. 10.12 secs for the 1600 frames).
Many thanks to Chris for his hard work!

George

I tried the following modified configuation with the LapPi but that didn’t work.

Mode 86 gives 1366 × 768 to align with the screen.

hdmi_drive=2
hdmi_group=2
hdmi_mode=86
hdmi_force_edid_audio=1
disable_overscan=1
fake_vsync_isr=1
framebuffer_swap=0
gpu_mem=64
init_emmc_clock=100000000
kernel=RISCOS.IMG

I also tried Chris’s supplied Config/txt with the same garbled screen.

Doug

Ok I’ve found the issue in that I was using a custom MDF rather than just setting the screen as Auto in the screen set up.

The MDF had EDID data and was setting the screen for 1360 × 768 as RISC OS will not do 1368 × 768.

1. hdmi_group=2
2. hdmi_mode=86
3. 1360 × 768 (70Hz)
   startmode
   mode_name:1360 × 768
   x_res:1360
   y_res: 768
   pixel_rate:78000
   h_timings:0,0,0,1360,0,0
   v_timings:0,0,0, 768,0,0
   sync_pol:1
   endmode

This worked ok on the old ROM and firmware from RC14 but will not work on the latest firmware.

So putting the screen mode back to Auto clears the garbled screen and I’m typing this using the LaPi with Chris’s Low vector ROM and Firmware.

Now just need to get my glasses out to see the LaPi screen clearly as the text is a bit small :-)

Doug

The URLs are missing the protocol.

Sorry, now corrected!

The CPUFreq icon shows a rev counter; the needle indicates the cpu frequency, which is displayed below as well. There is a red segment between approx. 1100-1200MHz (judging by eye) – is this specific to the machine it’s running on (i.e. reading some cpu VNE in the Pi2) or generic? Just wondering.

I was going to try to show speed and temperature but it’s just speed at the moment. The speed can only be ‘slow’ or ‘fast’ – the red line is a bit above the ‘fast’ speed so you can never get there!

Kludged ZeroPain – with thanks to Rick Murray

I see that there is now a new official ZeroPain (0.06) that works until OS 5.24 comes out. It also apparently provides better logging.

I see that there is now a new official ZeroPain (0.06) that works until OS 5.24 comes out. It also apparently provides better logging.

As per Jeffreys comments about needing to get a suitably shaped tuit :)

I noted the CVS entries last night. Looks like I can put a current release on the BB-xM

Note that the new ZeroPain won’t actually be in today’s ROMs – I ran out of time before I was able to update the docs and binary which get included in the ROM downloads.

Note that the new ZeroPain won’t actually be in today’s ROMs

Built here from CVS.

It also apparently provides better logging.

It certainly does but to do so is reliant on changes within the ROM. That’s all good on the Raspberry Pi with today’s ROM (06-Apr-16). With older ROMs the ZeroPain logs are as before.

That’s all good on the Raspberry Pi with today’s ROM (06-Apr-16). With older ROMs the ZeroPain logs are as before.

That would be why the two are included in the same zip download then :)
Big hint that they are intended to be used together…