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 5D411941454 for ; Tue, 10 Oct 2023 07:44:02 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=nXuw/O5nrxAFu9IrA3qwkzvt8M6R3IrNmI+1cu9oPJc=; 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=1696923841; v=1; b=TDpw+hsOJjVP7Io1B1B3L2IPRHLv1JyaBZ/sg3GecX0xkbkSPBZA21FX30NMepaeczftE7fn Gy4ryJVq+4o4xGdNhGdCBYRj9meBiakWjri61oqSU6hhn0wOhQDyrHHWG3D/PrWL7pZXvYRNvSN DYxDfNVByrk5CwSd1XNtxCts= X-Received: by 127.0.0.2 with SMTP id 7VvXYY7687511xFxHToyhTfr; Tue, 10 Oct 2023 00:44:01 -0700 X-Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by mx.groups.io with SMTP id smtpd.web11.85533.1696923839867681520 for ; Tue, 10 Oct 2023 00:44:00 -0700 X-Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id D9318CE1CAF for ; Tue, 10 Oct 2023 07:43:55 +0000 (UTC) X-Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1F66CC433C8 for ; Tue, 10 Oct 2023 07:43:55 +0000 (UTC) X-Received: by mail-lf1-f49.google.com with SMTP id 2adb3069b0e04-5056ca2b6d1so6473550e87.1 for ; Tue, 10 Oct 2023 00:43:55 -0700 (PDT) X-Gm-Message-State: 7IV7LkJpygEivarHPr0Ilrrox7686176AA= X-Google-Smtp-Source: AGHT+IGKOyCI6rFszbirZmljDNQyHT7xXFZ6sdqkpo3cExm/tHS6ceMt0SEeydgFsnh3UWbx4q2xwt5i2mslneD6QqY= X-Received: by 2002:a19:520c:0:b0:502:a964:84b1 with SMTP id m12-20020a19520c000000b00502a96484b1mr10735385lfb.25.1696923833248; Tue, 10 Oct 2023 00:43:53 -0700 (PDT) MIME-Version: 1.0 References: <20231008153912.175941-1-lersek@redhat.com> In-Reply-To: <20231008153912.175941-1-lersek@redhat.com> From: "Ard Biesheuvel" Date: Tue, 10 Oct 2023 09:43:41 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [PATCH 0/9] ArmVirtPkg: support two PL011 UARTs To: Laszlo Ersek Cc: devel@edk2.groups.io, Ard Biesheuvel , Gerd Hoffmann , Julien Grall , Leif Lindholm , Peter Maydell , Sami Mujawar 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,ardb@kernel.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=TDpw+hsO; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.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 Sun, 8 Oct 2023 at 17:39, Laszlo Ersek wrote: > > This ArmVirtPkg series can be fetched from: > > repo: https://pagure.io/lersek/edk2.git > branch: armvirt-dual-serial @ 65ee08413595 > > The series does the following: > > - It centralizes (and cleans up) two FDT parsing actions, namely looking > up all serial ports, and looking up the /chosen "stdout-path" serial > port, in a new library class and instance. > > - It rebases Fdt16550SerialPortHookLib, EarlyFdtPL011SerialPortLib and > PlatformPeiLib to the new library. > > - If QEMU specifies just one PL011 UART, then this patch set is > unobservable from the outside. > > - If QEMU specifies (at least) two PL011 UARTs, then we distinguish a > "chosen" one, and a (first) "non-chosen" one: > > - Both EarlyFdtPL011SerialPortLib, and (PlatformPeiLib + > FdtPL011SerialPortLib), target the "chosen" PL011. The consequence > of this is that (a) direct SerialPortLib traffic, (b) the dependent > SerialIo (SerialDxe) protocol traffic, and (c) the dependent UEFI > console traffic, all occcur on the same PL011, and do so regardless > of the firmware phase. Furthermore, (d) the Linux serial console > traffic is directed to the same PL011 as well. In total, the > "chosen" PL011 UART becomes "the console", covering both firmware > and Linux. > > - Three new DebugLib instances -- namely Flash, RAM, and DXE Runtime > instances of "DebugLibFdtPL011Uart" -- target the (first) > "non-chosen" PL011. The consequence is that DebugLib output is > hermetically separated from the above-mentioned console, mirroring > the isa-debugcon situation with x86 OVMF. > > Peter's QEMU patch set that this series interoperates with is at: > > repo: https://git.linaro.org/people/pmaydell/qemu-arm.git > branch: uart-edk-investigation @ 66bff4241bf8 > > See the larger background, and my detailed test results -- using > "ArmVirtQemu.dsc" -- in the following thread: > > EDK2 ArmVirtQemu behaviour with multiple UARTs > http://mid.mail-archive.com/CAFEAcA_P5aOTQnM2ARYgR5WvKouvndMbX95XNmDsS0KTxMkMMw@mail.gmail.com > https://listman.redhat.com/archives/edk2-devel-archive/2023-September/068241.html > https://edk2.groups.io/g/devel/message/108941 > > For my testing, I rebased Peter's set on more recent QEMU commit > 36e9aab3c569. Also, importantly, Peter's last patch 66bff4241bf8 ("virt: > Reverse order of UART dtb nodes", 2023-09-21) is *indifferent* regarding > my test results (which shows that the ordering of the two PL011 UARTs in > the DTB does not matter, with this edk2 series applied). See more on > that in the above-noted thread. > > "ArmVirtKvmTool.dsc" and "ArmVirtXen.dsc" are not supposed to be visibly > affected by this series; I test-built them, and checked the library > resolutions before/after in their build report files (no change). > Runtime regression testing with these platforms would be welcome. > > I also test-built "ArmVirtCloudHv.dsc" and "ArmVirtQemuKernel.dsc". > Those *are* supposed to receive the same feature, but I couldn't / > didn't boot them, respectively. > > I've formatted the patches with "--find-copies-harder", because (a) that > makes for an easier reading, and (b) leaves the patches applicable from > the list. The base commit is noted at the end of this message. > > Cc: Ard Biesheuvel > Cc: Gerd Hoffmann > Cc: Julien Grall > Cc: Leif Lindholm > Cc: Peter Maydell > Cc: Sami Mujawar > Hello Laszlo, Thanks for looking into this - a cleanup was overdue here. I will take a look in more detail later, but one thing that occurred to me when reading this overview is that having a separate DEBUG serial port would permit us to a) remove it from the DT b) add a runtime mapping for it c) keep using it after ExitBootServices This could be useful for debugging issues with the variable store etc. Not saying this is something to address in this series, but I'd like to hear your take on this. -- Ard. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#109475): https://edk2.groups.io/g/devel/message/109475 Mute This Topic: https://groups.io/mt/101834880/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=-=-=-=-=-=-=-=-=-=-=-