From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id 5F281740034 for ; Thu, 28 Sep 2023 11:50:58 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=KHSfNTaLfzTwqksXciZRV4hDqOgKnburv2OUHykA5Uc=; c=relaxed/simple; d=groups.io; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:In-Reply-To:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Language:Content-Type:Content-Transfer-Encoding; s=20140610; t=1695901856; v=1; b=anviWD+MFMazMnHgZ+w5KcOUuJUbTJuInkI9zfnmjfzBXpOnUscKGZTKA6x9efrLOZmjwuK2 7hnNPuoiOvF+n1kGR98UgggSHhpUzGAogz24Ctv7yjlJ+/pXtahSsshC0oiLdveXgC7bCrWW2HK sbUEoEtawPQJ9EmJjxg8nM5A= X-Received: by 127.0.0.2 with SMTP id hxqYYY7687511x0mgOyL2qGh; Thu, 28 Sep 2023 04:50:56 -0700 X-Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mx.groups.io with SMTP id smtpd.web11.11435.1695901856197835128 for ; Thu, 28 Sep 2023 04:50:56 -0700 X-Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-209-qJMP45jSNyuutVFSUwGa3A-1; Thu, 28 Sep 2023 07:50:51 -0400 X-MC-Unique: qJMP45jSNyuutVFSUwGa3A-1 X-Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 20B918002B2; Thu, 28 Sep 2023 11:50:51 +0000 (UTC) X-Received: from [10.39.192.184] (unknown [10.39.192.184]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 499F3170EC; Thu, 28 Sep 2023 11:50:50 +0000 (UTC) Message-ID: Date: Thu, 28 Sep 2023 13:50:49 +0200 MIME-Version: 1.0 Subject: Re: [edk2-devel] EDK2 ArmVirtQemu behaviour with multiple UARTs To: Peter Maydell Cc: Ard Biesheuvel , Gerd Hoffmann , edk2-devel-groups-io References: <12a217d3-b11c-0a4e-ca6d-0adeccac57d3@redhat.com> From: "Laszlo Ersek" In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.5 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,lersek@redhat.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: LOPG7p7yYJaJ6Xk3mVb0EFgXx7686176AA= Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=anviWD+M; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=redhat.com (policy=none); spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io On 9/28/23 13:24, Peter Maydell wrote: > On Thu, 28 Sept 2023 at 08:54, Laszlo Ersek wrote: >> >> On 9/21/23 14:02, ardb at kernel.org (Ard Biesheuvel) wrote: >>> EDK2's DEBUG output is extremely noisy, so being able to redirect this >>> output to a different UART would be very useful. >>> >>> The stdout-path is the intended console, and so we should honour that. >>> This also means that we should parse aliases. But the console is >>> actually configurable [persistenly] via the UEFI menu, and so it would >>> be nice if we could take advantage of this flexibility. This means in >>> principle that the UARTs should be represented via different device >>> paths (which would include the base address so they are >>> distinguishable) with perhaps a magical alias which is the default and >>> is tied to whatever stdout-path points to. This way, all the logic we >>> introduce is spec compliant and reusable on physical platforms with >>> multiple UARTs. >=20 >>> What we might do is use stdout-path as well, unless a certain DT alias >>> exist perhaps? We should probably align here with other projects, >>> although this a distinction of the same nature may not exist there. >>> >> >> Alias parsing in edk2 would be a bit too complicated for my taste. :) >> >> I see the following two problems with the current state (based on >> Peter's captures, using the original UART order in the DTB, i.e., >> and >> ): >> >> (1) The DEBUG output switches from one UART to the other when we reach >> the DXE_CORE (in this case, from UART0 to UART1, but the precise numbers >> aren't the problem, the switchover is), >> >> (2) The UEFI console (which is used by the setup browser, the UEFI >> shell, grub, etc) is on UART1, while the kernel stuff is on UART0. >> >> Here's what I'd propose: >> >> - if there is only one UART in the DTB, no change >> >> - otherwise, direct all DEBUG messages to the UART found *second* via >> forward traversal in the DTB (let's call this UART1), and include the >> UART found *first* via forward traversal in the DTB (let's call this >> UART0) in the UEFI console. Furthermore, do not expose UART1 in the UEFI >> protocol database *at all* (don't install devpath protocol / SerialIo >> protocol); make it effectively hidden hardware (similarly how the x86 >> QEMU debug console, IO Port 0x402, is not exposed at all). Let the >> system think there is only one UART (UART0), and treat UART1 as a >> "bespoke", custom debug device only. This also ensures that existent >> higher level products such as libvirt, which may only handle UART0 at >> the moment, will expose the interactive console (UEFI and Linux) to the >> user, and at worst the firmware debug log will not be captured. >=20 > The 16550 version of the QEMU-specific EDK uart-location code (used when > running it under kvmtool) already honours stdout-path, Right -- I wasn't aware. I can see GetSerialConsolePortAddress() in "ArmVirtPkg/Library/Fdt16550SerialPortHookLib/EarlyFdt16550SerialPortHookLi= b.c", which is used in "ArmVirtPkg/ArmVirtKvmTool.dsc". > so I'm not sure > why we wouldn't want to be consistent with that. I'm not really a fan of > anything that depends on ordering of nodes in the DTB -- it is pretty > fragile in my experience. The DTB spec provides a mechanism to > correctly identify which UART to use, so I think that there would > need to be a really strong reason not to do it that way. OK -- I think the proposal might still work if we replaced "UART found second" with "first non-stdout-path UART", and "UART found first" with "stdout-path UART". Laszlo -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#109144): https://edk2.groups.io/g/devel/message/109144 Mute This Topic: https://groups.io/mt/101498371/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/leave/12367111/7686176/19134562= 12/xyzzy [rebecca@openfw.io] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-