Re: Issues attempting to use Raspberry Pi 4 serial console on mainline

[Nicolas Saenz Julienne <nsaenzjulienne@suse.de>]

Hi Nathan,

On Tue, 2020-07-21 at 15:57 -0700, Nathan Chancellor wrote:
> Hi all,
> 
> Thank you for all of the hard work that has been done on supporting
> the
> Raspberry Pi 4 upstream. It has been a great platform so far for
> testing
> various clang technologies on actual hardware.

I'm glad it's useful :)

> I am investigating a panic that occurs when running a guest under KVM
> when clang's Shadow Call Stack is enabled and it would be handy to
> grab
> the kernel panic via serial console as the device panics and I lose
> my
> ssh connection. I picked up a USB to TTL cable and I am able to get
> connected with the following config.txt options and cmdline.txt
> options:
> 
> $ head -n4 /boot/config.txt
> enable_uart=1
> kernel=Image
> os_prefix=custom-mainline-arm64/
>
> upstream_kernel=1

I'd say for rpi4 this property isn't necessary as you're creating a custom
os_prefix anyway. But it should be harmless.

That aside, the only thing I'm missing is:

arm_64bit=1

> $ cat /boot/custom-mainline-arm64/cmdline.txt
> console=ttyS1,115200 console=tty1 root=PARTUUID=45a8dd8a-02

Which device tree are you using? This is the right tty device if using the
upstream one, if using the one provided by the RPi foundation it should be
ttyS0.

> rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
> plymouth.ignore-serial-consoles

For reference I just booted linux-next with this setup:

boot partition:
	...Latest firmware files taken from the RPi firmware repo [1]...
	Image			#Copied from linux build
	bcm2711-rpi-4-b.dtb	#Copied from linux build
	config.txt
	cmdline.txt

config.txt:
	kernel=Image
	enable_uart=1
	arm_64bit=1

cmdline.txt:
	 console=tty console=ttyS1,115200 text root=/dev/nfs
	 nfsroot=10.42.0.1:/home/nico/netboot/root,vers=3 rw ip=dhcp
rootwait
	 elevator=deadline

> However, when I connect to the serial console via PuTTY, I get
> nothing
> but garbage output: https://imgur.com/a/ekFlLYq
>
> As I understand it, that is due to the mini UART not being as good as
> a
> regular PL011. On the downstream kernel, one would apply
> 'dtoverlay=disable-bt' which would free up the first PL011 to be used
> as
> the primary UART but the device tree overlays do not work on a
> mainline
> kernel. Is there an easy way to disable Bluetooth via the device
> tree?
> If not, is there any recommended or documented way to use the mini
> UART
> successfully? I have seen information around using 'core_freq=...'
> but
> the documentation says that does not work for the Raspberry Pi 4.

The issue with the mini UART is its clock, which is derived from VPU's, which
is itself controlled by RPi's firmware. Changes might happen behind the
kernel's back, and the mini UART divisors will not be updated accordingly.
This is an area the we could do better, but no one found a good solution yet.
That said, for now, when using the upstream kernel, VPU's clock should be
stable as we forbid the firmware from performing frequency scaling on that
clock.

In the future, once Maxime Rippards vc4/HDMI code is merged we will most
probably hit this issue as the core clock has to be upscaled when feeding big
screen resolutions. As you mention, a solution to this is fixing the core
frequency in config.txt, for example I tested this successfully:

core_freq=500
core_freq_min=500

Regards,
Nicolas

[1] https://github.com/raspberrypi/firmware


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel