Re: Raspberry Pi 3?

Jeremy McDermond <mcdermj@...>
 

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

Jeremy,

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 https://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf on Page 11 and some discussion of this fact at http://comments.gmane.org/gmane.linux.drivers.devicetree/134707). 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.

You
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.


73,
John

Jeremy McDermond (NH6Z)
nh6z@...

Join main@nw-digital-radio.groups.io to automatically receive all group messages.