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 7FC97D80550 for ; Thu, 28 Sep 2023 07:54:41 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=r4ldQ9/abYKEwUKZrAV+fr0H6aDFhkxuR57AgDrUseE=; c=relaxed/simple; d=groups.io; h=Message-ID:Date:MIME-Version:Subject:To: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=1695887680; v=1; b=FfbbqflitVHKRVpBqkVQkdSoi/Jgn3wHBmLek/1TTQFfDjhRVlQ/WETB/j/eiERr1p5yhiri 6mwgqfwivhfPqACvaYvSFYT78nTdCnm1N3r0zN0kxQN/t1RsCyCXkyhoTkcvndIT/3+7ZTg/Ncd Vcof8v8X7ZYZiOkSBEy+UHPw= X-Received: by 127.0.0.2 with SMTP id GtkXYY7687511xUmNXJ4e5Cx; Thu, 28 Sep 2023 00:54:40 -0700 X-Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.groups.io with SMTP id smtpd.web11.8942.1695887679357936833 for ; Thu, 28 Sep 2023 00:54:39 -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-604--vVk42TiPKS68ygx4Sm9MA-1; Thu, 28 Sep 2023 03:54:35 -0400 X-MC-Unique: -vVk42TiPKS68ygx4Sm9MA-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 BDA33185A790; Thu, 28 Sep 2023 07:54:34 +0000 (UTC) X-Received: from [10.39.192.184] (unknown [10.39.192.184]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D748B170EC; Thu, 28 Sep 2023 07:54:33 +0000 (UTC) Message-ID: <12a217d3-b11c-0a4e-ca6d-0adeccac57d3@redhat.com> Date: Thu, 28 Sep 2023 09:54:32 +0200 MIME-Version: 1.0 Subject: Re: [edk2-devel] EDK2 ArmVirtQemu behaviour with multiple UARTs To: Ard Biesheuvel , Peter Maydell , Gerd Hoffmann , edk2-devel-groups-io References: 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: fwVxQGC4pdHgYoCZSsJvQVBPx7686176AA= 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=Ffbbqfli; spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=redhat.com (policy=none) On 9/21/23 14:02, ardb at kernel.org (Ard Biesheuvel) wrote: > On Thu, 21 Sept 2023 at 10:50, Peter Maydell wrote: >> >> Hi; I've been looking again at a very long standing missing feature in >> the QEMU virt board, which is that we only have one UART. One of the >> things that has stalled this in the past has been the odd behaviour of >> EDK2 if the DTB that QEMU passes it describes two UARTs. >> >> I'm going to describe the behaviour I see in more detail below, but to >> put the summary up front: >> * EDK2 puts some debug output on one UART and some on the other >> (the exact arrangement depends on ordering of the dtb nodes) >> * EDK2 doesn't look at either stdout-path or the serial* aliases, >> so its choices about how to use the UARTs differ from those >> made by the guest kernel it is booting (and it also seems to be >> iterating through the dtb in the opposite order to the kernel) >> >> The current proposal for adding a second UART is that it only happens >> if you explicitly add one on the command line (with a second "-serial >> something" option), so whatever we do won't break existing user >> setups. So we have scope for saying "if you want to use a second UART, >> you're going to want a newer EDK2 which handles it better". Exactly >> what "better" means here is up for grabs, but honouring stdout-path >> and the serial aliases would be the ideal I think. It would also be >> possible to select a particular ordering for the DTB nodes to produce >> "least-worst" behaviour from an existing EDK2 binary, but I'm not >> sure if that's worth doing. >> >> What do the EDK2 folks think about what the correct behaviour >> should be for a 2-UART setup? >> >=20 > Hi Peter, >=20 > Thanks for the elaborate analysis. >=20 > EDK2's DEBUG output is extremely noisy, so being able to redirect this > output to a different UART would be very useful. >=20 > 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 > The DEBUG output is a different matter. On physical hardware, this is > typically configured at build time, as the info is needed extremely > early and on a physical platform, the debug port generally doesn't > change. Currently, we just grab the first UART that we encounter in > the DT, but the logic used by the DEBUG code and the ordinary console > driver are mostly separate. >=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. >=20 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. For this a few custom DebugLib / SerialPortLib instances may have to be created, but that should be doable. 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 (#109141): https://edk2.groups.io/g/devel/message/109141 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-