Re: Raspberry Pi 3?

"John Wiseman" <john.wiseman@...>

The problem is that on the Pi3 the GPU clock frequency can vary, unless it
is locked to 250 MHz, then reducing performance.

There is a load of stuff about this on the PI forums.

73, John

Sent: 10 March 2016 12:23
Subject: Re: [UniversalDigitalRadio] Raspberry Pi 3?


On Mar 10, 2016, at 1:04 AM, 'John Wiseman' john.wiseman@...
[UniversalDigitalRadio] <> wrote:


I think you’ve missed my point. The Pi3 now has /dev/ttyS0 where
/dev/ttyAMS0 used to be without adding any overlays. But by default its

speed will vary with the GPU clock, and will start out about 40% slower.
I’m not sure where you’re getting this from. The Mini-UART is clocked off of
the “core” clock. The GPU is default off of this PLL. The firmware sets this
speed to 250MHz on the RPi 2, and, presumably, 450MHz on the RPi 3. There’s
a divider on the Mini-UART to produce whatever speed you want.

I fully understand that the AMBA UART is being used for bluetooth and the
Mini-UART is being used for the serial pins on the header now. My point is
that you can simulate this change by merely using the device overlay on a
RPi 2. It’s the same peripheral.

I only peripherally understand what you’re trying to say about the clocks.
The RPi 1/2 define the “core” PLL as fixed to 250MHz. It won’t change during
operation AFAIK. So that’s not a concern.

I think what you’re trying to point out is that 250MHz is around 40% slower
than 450MHz. That’s fine but the of_serial driver pays attention to the
device tree to figure out what speed its clock is at and sets up its
dividers accordingly. Check out in bcm2708_common.dtsi around line 205 where
it sets its clock. This refers to the clock definition around line 359. This
is where the UART device gets its frequency to figure out what its divisor
has to be. There’s a “fixed factor” clock in there that multiplies clk_core
by two because the ns16550’s divisor is multiplied by 16, where the
Mini-UART is divided by 8 (see
ls.pdf on Page 11 and some discussion of this fact at This is a
correction for that fact. If one were to change the clock-frequency setting
of clk_core, the UART will do the right thing. This doesn’t even require a
kernel recompile.

can get get round this by throttling the GPU or by disabling Bluetooth and
putting /dev/ttyAMS0 back where it was.
Or by accurately telling the device what frequency its clock is at. If worst
comes to worst, it’s should be a one-liner device tree overlay. The
of_serial driver supports a clock-frequency setting that will force it to
use whatever we tell it.

But as far as I can see, you can’t have the serial port, full performance
and Bluetooth. You’ll have to choose which to sacrifice.
I’ll know for sure tomorrow, but I’m pretty sure you can have your cake and
eat it too.


Jeremy McDermond (NH6Z)

Join to automatically receive all group messages.