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.