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 B4F5994195E for ; Thu, 21 Sep 2023 12:03:02 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=lejyS17pgdJlMl1MenBIo3XnOC3tEk2vgGTrF2sXjFc=; 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=1695297781; v=1; b=hAxRSqv3KlWsYYVsk6WYtdO5MUaJ8ehP8AEV45IoDHUZFp2cnreia9hXsGmDODRH73MQFGGM nZxeKK7bZbtrGusjK5pMsPH1CGa2wK22RMKEt+0sJ3EaccVBX1ZGxXiIoW/SE0qyH2qrDJ4mGxu jqcJYArNECSlnhnCm02a7sW8= X-Received: by 127.0.0.2 with SMTP id OtTfYY7687511xBQVd5oUQM7; Thu, 21 Sep 2023 05:03:01 -0700 X-Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by mx.groups.io with SMTP id smtpd.web11.14917.1695297780485187668 for ; Thu, 21 Sep 2023 05:03:00 -0700 X-Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 6E652B8203E for ; Thu, 21 Sep 2023 12:02:58 +0000 (UTC) X-Received: by smtp.kernel.org (Postfix) with ESMTPSA id 06FA8C4AF7F for ; Thu, 21 Sep 2023 12:02:57 +0000 (UTC) X-Received: by mail-lf1-f53.google.com with SMTP id 2adb3069b0e04-502a4f33440so1618138e87.1 for ; Thu, 21 Sep 2023 05:02:56 -0700 (PDT) X-Gm-Message-State: bxAkQddtoM5Sxtena5TRvGyvx7686176AA= X-Google-Smtp-Source: AGHT+IGJphnsDO/V4bxyK7pG7FfcOYufXP7FFVUmC6pS7esnWfGUsjR8Wy0u3MoXi8utAw5zAsbjZGHYkNWN9FadFlY= X-Received: by 2002:a2e:7a0d:0:b0:2bf:f84e:c1ec with SMTP id v13-20020a2e7a0d000000b002bff84ec1ecmr4959712ljc.13.1695297775232; Thu, 21 Sep 2023 05:02:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Ard Biesheuvel" Date: Thu, 21 Sep 2023 12:02:43 +0000 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] EDK2 ArmVirtQemu behaviour with multiple UARTs To: Peter Maydell Cc: QEMU Developers , devel@edk2.groups.io, Leif Lindholm , Ard Biesheuvel , 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=hAxRSqv3; 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 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? > Hi Peter, Thanks for the elaborate analysis. 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. 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. 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. -- Ard. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#108941): https://edk2.groups.io/g/devel/message/108941 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] -=-=-=-=-=-=-=-=-=-=-=-