Inability to dynamically set core clock with recent firmware

[hoglet]

Hello all,

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:
https://github.com/hoglet67/RGBtoHDMI/wiki

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();

We then use the Core Clock (PLLC) as a clock source with one of the GPClock, which gives us a pixel sampling clock of ~96MHz.

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!

regards

Dave

[dom]

Sounds interesting. Probably worth moving this to https://github.com/raspberrypi/firmware/issues as it sounds like a firmware issue
(need to work out if this is a regression, or whether this can be done a different way).

Can you provide files needed to reproduce the problem? (prebuilt arm kernel image is fine)
Explain what the observed issue is (I assume that frequency no longer changes with newer firmware).

[hoglet]

Sounds interesting. Probably worth moving this to https://github.com/raspberrypi/firmware/issues as it sounds like a firmware issue
(need to work out if this is a regression, or whether this can be done a different way).

Can you provide files needed to reproduce the problem? (prebuilt arm kernel image is fine)
Explain what the observed issue is (I assume that frequency no longer changes with newer firmware).

I've create an issue for this:
https://github.com/raspberrypi/firmware/issues/1022

The observed issue is that that core clock remains unchanged in frequency.

I'll try to make a smaller test case, as the kernel that's part of out release will not get as far as the clock setting if there is no video signal detected.

Dave

[f5oeo]

Very interesting project.

See that you use core clock to set PLLC frequency. It is a possible way, however you could also use an other method in order to set a master PLL frequency (using Clock and PLL registers). Advantage is the frequency granularity (precise offset) for your 96MHZ will be far better.

I use this method in https://github.com/F5OEO/librpitx
It uses PLLA for now : you could inspect a short part : https://github.com/F5OEO/librpitx/blob/ ... o.cpp#L329

Evariste

[hoglet]

See that you use core clock to set PLLC frequency. It is a possible way, however you could also use an other method in order to set a master PLL frequency (using Clock and PLL registers). Advantage is the frequency granularity (precise offset) for your 96MHZ will be far better.

I use this method in https://github.com/F5OEO/librpitx
It uses PLLA for now : you could inspect a short part : https://github.com/F5OEO/librpitx/blob/ ... o.cpp#L329

I agree It would be nice to be able to use a different PLL. I've tried, but not had any success yet. For example, I found the PLLA GP clock source seems to be fixed at 500MHz, and can't be changed through the GPU mailbox.

I'll have a good look at your code, which is interesting as it seems to be programming the PLL registers directly. Did you find some documentation for programming the PLLs, or did you work it all out yourself?

This blog post was interesting:
https://www.tablix.org/~avian/blog/arch ... n_bcm2835/

We have another problem to be solved. We would like to be able to "genlock" the HDMI VSYNC to the source's VSYNC. To do this we need to be able to make small changes to the HDMI Clock Frequency (PLLH), like vcgencmd hdmi_adjust_clock does. But we need to be able to do this from bare metal. Again, not found a way to do this yet.

Any further suggestions gratefully received.

Many thanks,

Dave

[f5oeo]

Hi Dave,

Yes all PLL registers are done manually. The blog you mention is a good starting but use devive tree to set parameters of PLL.
I mainly based my work on the clock driver (understand the overall clock architecture and adapt it to userland).
I think to have a good understanding of it but never write a documentation to describe it. Some registers are still obscure because they are part of closed source (driver author could not answer my questions because of that).

However, we could easily set PLL frequency without using mailbox interface. I will be glad to assist you if you like. I could also contribute directly on the project, but it will be surely more easy to do it with the CPLD board (instead of coding it blind).

Evariste

PS: references to the driver clock source are in the gpio.h of librpitx project.

[hoglet]

Hi Evariste,

Thanks for the offer of help, actually just looking at your code was very helpful.

The bit I a previously missed was the need for a special "password" when writing to the clock manager registers:
https://github.com/F5OEO/librpitx/blob/ ... o.cpp#L139

Actually, today I've made much progress on this, and I'm now programming the PLLH directly, so that I can frequency lock the HDMI Vsync to the incoming video signal. This is working very well.

At some point I will probably switch over to using PLLA as the sampling clock.

There was one thing you said earlier that I don't understand:

See that you use core clock to set PLLC frequency. It is a possible way, however you could also use an other method in order to set a master PLL frequency (using Clock and PLL registers). Advantage is the frequency granularity (precise offset) for your 96MHZ will be far better.

Can you explain why using PLLC as I'm currently doing is not giving very good frequency granularity? From the measurements I have made, the sampling clock seems to be very accurate, and there is no visible phase shift across a line (64us).

Are you suggesting using PLLA is somehow better?

Dave