phk@phk.freebsd.dk said:

Plan B would be to avoid the 10=>54 PLL chip by reprogramming the software
that sets up the internal PLLs to run off 10 MHz rather than 54MHz.  That may
not be possible.  It depends on how the clocking inside the ARM chip is setup.

If you are lucky, you won't need to change the kernel.  If you are half-lucky,
you have to make a few tweaks to the kernel software and rebuild.

In case anybody isn't familiar with ARM SOC chips, they typically have a layer
of muxes between the external pins and the internal I/O devices.  I don't know
if the chip used in the Pi-4 works this way.  Quite likely.

It's a chinese menu sort of deal, only more complicated.  If you get the beef
from column A, you can't get the chicken from column B.

The basic idea is that there are more I/O devices on the chip than there are
pins.  After reset, all the pins are setup as GPIO input so they don't
accidentally drive an input pin.  There is a mux in front of each input signal
to an I/O device that picks the signal from one of several pins.  There is a
mux on the output side of each pin that selects from an output of several I/O
devices.

The system designer has to find a combination of mux settings that works for
the application.  Leftover pins can be used as GPIO.  And the clocking is
tangled up in there.

--
These are my opinions.  I hate spam.

Hal Murray writes:

One of the big problems with the RPi family is that only a skeleton
datasheet has been made available - because: Qualcom magic sauce
recipe or similar verbiage..

I've heard a lot of gripes about precisely the clock circuits being
underdocumented, but I have deliberately stayed well clear of the
details.

--
Poul-Henning Kamp      | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG        | TCP/IP since RFC 956
FreeBSD committer      | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

On Thu, Feb 4, 2021 at 4:09 PM Hal Murray hmurray@megapathdsl.net wrote:

While true for many pins, usually quite a few are not muxed.  Those
deemed necessary for all designs or with specialized drivers.  So
typically there will be no mux for power pins, dram interface, xtal
inputs, and high speed differential data, like USB3, PCIe, SGMII, MIPI
CSI or DSI.  Or perhaps muxing between different high speed serial
interfaces.

It seems to be very common for ARM SoC chips to be designed to be
clocked by either an XTAL and a built in oscillator, or via an
external clock generator connected to the same pin.  But, I've never
seen a SoC where this pin could be muxed.

I've not seen one where the input clock frequency had much of a range.
It might be 24-26 MHz, but never 10 - 52 MHz.  At least documented.
But the clock is invariably an input to a programmable PLL or PLLs,
and those PLLs are likely programmable with a rather wider range of
multipliers and dividers than required for the limited documented
input frequency range.

One might have better luck with a chip from Ti or NXP, since, unlike
Broadcom, they have documentation on how their clocks and PLLs work.

Trent Piepho writes:

Usually if you read very closely, you will find a wide range is OK
but a footnote to the effect that they only warrant USB will work at
the following specific frequencies.

--
Poul-Henning Kamp      | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG        | TCP/IP since RFC 956
FreeBSD committer      | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

Hi

A lot depends on the intended application of the chip. For
a general purpose MCU that could go into a wide range
of things and that has very few peripherals,  1 to 40 MHz
might be just fine.  There are chips out there with much
wider clock input ranges.

Toss in USB and that locks in a clock tree output. Pile on
various Video formats and they need this or that specific
output frequency. Various speeds of Ethernet need this or
that. Fancy audio may adds in its needs. These are outputs
from the clock system rather than inputs, but they do impact
what inputs will work.

A general purpose device may still allow a range of inputs
and then play games to get the needed outputs. An on chip
VCO and a variety of dividers feeding a PLL are one common
setup. There may be multiple sets of this and that onboard.

The issue becomes that only very specific individual frequencies
in the specified range will work. Many of those specific frequencies
may be quite strange looking ….

On a purpose built device ( = one intended use) it is not
uncommon to see them saving die space on the clock tree.
You have one target input that it will accept. If you are lucky,
it might accept 2X  and 4X that frequency. I suspect that this
approach also makes the part a bit easier to test / validate.

None of this is to say that the RPi will not work at (say)
50 MHz in. It is very likely that it will.  It is a pretty good bet
that a whole bunch of peripherals will have issues if you do.

Bob