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 5183794150E for ; Thu, 28 Sep 2023 13:20:59 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=v+UBVS0mZftv+27MlpZ4OZWx0fvjLsTCXZ2cEOAxwOs=; c=relaxed/simple; d=groups.io; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:To:Cc:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Type; s=20140610; t=1695907258; v=1; b=lY59QrMIpWTL0cjWQ/aYsT+SOXgsXtsfArkVgLWRSpZcQJw1SNJZBHW0nZNcxbNJcjbIJ+pW 2ICkQkhsBGACnBTf/4iXVb4rxlzedHx/ax0UP1SiHq/N1LzCWSptzL8+39KvnK9/ep8hhxUD5dU F6FU3fvb/wHlTauXWJZlWB8c= X-Received: by 127.0.0.2 with SMTP id a6VSYY7687511xVnl0oWXSir; Thu, 28 Sep 2023 06:20:58 -0700 X-Received: from mail-ed1-f51.google.com (mail-ed1-f51.google.com [209.85.208.51]) by mx.groups.io with SMTP id smtpd.web10.11339.1695900287488058884 for ; Thu, 28 Sep 2023 04:24:47 -0700 X-Received: by mail-ed1-f51.google.com with SMTP id 4fb4d7f45d1cf-533c5d10dc7so12270226a12.3 for ; Thu, 28 Sep 2023 04:24:47 -0700 (PDT) X-Gm-Message-State: bPiNsv2t7AwalZUgW7rOqeTsx7686176AA= X-Google-Smtp-Source: AGHT+IH/y4VNGfmju99jbmJtO7/xycmxCRsz61+NdLsgS13mvBMcJwlh76H6hQCU4AdxorIj/EVvSVrIaIBtQ3i3O7M= X-Received: by 2002:a05:6402:1490:b0:527:ab3f:4350 with SMTP id e16-20020a056402149000b00527ab3f4350mr927934edv.38.1695900285894; Thu, 28 Sep 2023 04:24:45 -0700 (PDT) MIME-Version: 1.0 References: <12a217d3-b11c-0a4e-ca6d-0adeccac57d3@redhat.com> In-Reply-To: <12a217d3-b11c-0a4e-ca6d-0adeccac57d3@redhat.com> From: Peter Maydell Date: Thu, 28 Sep 2023 12:24:27 +0100 Message-ID: Subject: Re: [edk2-devel] EDK2 ArmVirtQemu behaviour with multiple UARTs To: Laszlo Ersek Cc: Ard Biesheuvel , Gerd Hoffmann , edk2-devel-groups-io 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,peter.maydell@linaro.org List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: Content-Type: text/plain; charset="UTF-8" X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=lY59QrMI; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=linaro.org (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 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. > > 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. The 16550 version of the QEMU-specific EDK uart-location code (used when running it under kvmtool) already honours stdout-path, 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. thanks -- PMM -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#109146): https://edk2.groups.io/g/devel/message/109146 Mute This Topic: https://groups.io/mt/101498371/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=-=-=-=-=-=-=-=-=-=-=-