First a little bit of background... I'm working on a project called RGBtoHDMI that uses a Pi Zero as a video format converter to convert RGB Video (from the Acorn BBC Micro) to HDMI:
The project is at a fairly advanced stage and about 10 working prototypes exist.
You can find more information here:
This is a bare metal project, mostly C with a bit of assembler.
We need to generate a very accurate pixel sampling clock from the Pi that is at the same frequency as the BBC micro's video clock, and with minimal jitter. Actually, it's slightly more complicated than that, as the BBC Micro has 12MHz and 16MHz video modes, so we end up wanting a nominal 96MHz clock.
This clock needs to deal with any variations in the BBC micro's video clock. So if that is 700ppm faster, then we need a clock of 96.0672MHz. We calculate the required sampling clock by measuring the interval between two VSync pulses, and from this determine the clock error (in ppm) between the Beeb and the Pi.
We then use the mailbox interface to set the core core clocks to 384MHz +/- this error:
Code: Select all
// Switch to new core clock speed RPI_PropertyInit(); RPI_PropertyAddTag( TAG_SET_CLOCK_RATE, CORE_CLK_ID, new_clock, 1); RPI_PropertyProcess();
The code is in github here:
https://github.com/hoglet67/RGBtoHDMI/b ... dmi.c#L306
So finally to the point of this post....
It seems that the ability so change the Core clock dynamically in this manner stopped withing with this (and all subsequent) version of firmware:
https://github.com/raspberrypi/firmware ... fe9358557
The comment says "Rework the frequency/voltage scaling logic"
Can anyone help me understand what's going on here, and whether there is a workaround?
Otherwise, we will be stuck on the older firmware for ever!