From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B4232C433E2 for ; Wed, 22 Jul 2020 13:27:10 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 821FB20674 for ; Wed, 22 Jul 2020 13:27:10 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Nm+63vj9" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 821FB20674 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To:Date:To:From: Subject:Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=8xfK5eDbpvpgH9/hpCCr3r9PZWJ3udIHPmMqY9+GXR4=; b=Nm+63vj9a+fXZFKSXUgUr8jEj UoBy0cnboFsG6kpZURq906PwPzwE5eWUwDLJtyEpO1TSLG6u4ybLtszV54IbtKaFC2ruySO3jDeXh Ez1Tns58DTv9TywBrD4mjF6oI+SReOL7dfzYZVhGJ//pD4qEa6nYHHHhgqV6Gc0XA4gZq9JsuRQTL bvI+Px4wqlsSj+vvjIMgZfwnJVqIgO5Qw2gz6GJgd9rI5IpcX24irgK425bbcXjwtRzHvfjU/9Uhn D4XAEp1B8RUsI4SlrbWTpWBmqND6Y8rsYW9L6b9pCuUgTaJyqisP3gofFAQAEgBVHeQgCAvjs/MQe u9SxdWfjA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jyEkl-0005C5-Ls; Wed, 22 Jul 2020 13:25:47 +0000 Received: from mx2.suse.de ([195.135.220.15]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jyEki-0005BU-I0; Wed, 22 Jul 2020 13:25:45 +0000 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 9082CAC61; Wed, 22 Jul 2020 13:25:46 +0000 (UTC) Message-ID: <63244277a1c8989f87906746742141eba01d8bb5.camel@suse.de> Subject: Re: Issues attempting to use Raspberry Pi 4 serial console on mainline From: Nicolas Saenz Julienne To: Nathan Chancellor , linux-rpi-kernel@lists.infradead.org Date: Wed, 22 Jul 2020 15:25:37 +0200 In-Reply-To: <20200721225724.GA1005852@ubuntu-n2-xlarge-x86> References: <20200721225724.GA1005852@ubuntu-n2-xlarge-x86> User-Agent: Evolution 3.36.3-0ubuntu1 MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200722_092544_803501_AA96A852 X-CRM114-Status: GOOD ( 27.18 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: clang-built-linux@googlegroups.com, bcm-kernel-feedback-list@broadcom.com, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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