[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openbsd-arm
Subject:    Re: Serial port baud rate on Raspi 3 B
From:       Robert Curry <tech () rwcurry ! com>
Date:       2018-02-13 23:52:53
Message-ID: edb97ff1-905b-e8d7-789f-226d01d1cf32 () rwcurry ! com
[Download RAW message or body]

On 02/13/18 11:57, Heinrich Rebehn wrote:
> Hello List,
> 
> I am trying to install current snapshot on a Raspberry 3 B. I have problems setting \
> up the serial communication needed to access the installer. I connected the serial \
> pins (6,8,10) to the serial port of my PC and set parameters to 115200/8N1. But I \
> only see garbage on the screen. While googling for a solution I found some hints \
> about the Raspi using bizarre baud rates depending on the system clock. 
> Following is my boot/config.txt with the core_freq line added by me:
> 
> arm_control=0x200
> enable_uart=1
> core_freq=250
> device_tree_address=0x100
> kernel=u-boot.bin
> 
> Of course I tried different baud rates, but to no avail. I am using minicom on a \
> intel PC running Mac OS. 
> Is this still a known issue? I found no hints about this in the OpenBSD install \
> documents for ARM. 
> Can someone please help?
> 
> -Heinrich
> 
A little searching on the Raspberry Pi Forums finds the following 
thread. Some things to try, good luck.
********************************************************************
PhilE wrote:
A limitation of UART1 is that the clock varies with the VPU core clock, 
so you need to set core_freq=250 on the default Raspbian 2016-03-18 
firmware, or if you rpi-update (or get the next Raspbian when it is 
available) then you need to add enable_uart=1 to config.txt (which will 
also set cpu_freq=250 if ttyS0 is the primary UART)

It seems that "enable_uart" has not been released in the normal channel 
yet. rpi-update may get it for you, but it might get you a lot of other 
things as well! I would expect a bump to Raspbian soon, it's been talked 
about for a while now.

MarkHaysHarris777 wrote:
Also, what specifically does the core_freq=250 affect... L2 cache? 
whatelse if any? also, is there any other technical side-affect to 
having the core_freq=250 locked down?

PhilE wrote:
Yes, setting core_freq=250 should eliminate any UART glitching. It will 
also limit the VPU compute resource, which will mainly affect the new 
high quality analogue audio output, and could slightly increase the 
lifetime of the Pi (if there is any change at all).

So I guess the answer for the moment is to keep using "core_freq=250", 
as you have already found out.

If "core_freq=250" is a problem, and you are not using Bluetooth, you 
can use:

dtoverlay=pi3-disable-bt
and that will put /dev/ttyAMA0 back on the serial port.


[prev in list] [next in list] [prev in thread] [next in thread]