On 10/3/23 01:05, Laszlo Ersek wrote: > On 10/2/23 03:51, Laszlo Ersek wrote: >> On 9/21/23 12:50, peter.maydell at linaro.org (Peter Maydell) wrote: >> >>> If you want to play around with this, I have some WIP patches at >>> https://git.linaro.org/people/pmaydell/qemu-arm.git uart-edk-investigation >>> (content wise they should be fine, but I haven't cleaned them up into >>> a coherent set of distinct patches yet, so they're a bit messy.) >>> A run of QEMU with both UARTs which sends all output to files looks like: >>> >>> ./build/arm-clang/qemu-system-aarch64 -display none -vga none \ >>> -machine >>> virt,acpi=on,virtualization=on,mte=on,gic-version=max,iommu=smmuv3 \ >>> -smp 2 -m 1024 -cpu max,pauth-impdef=on \ >>> -bios ~/linaro/edk2/QEMU_EFI_DEBUG.fd \ >>> -drive >>> file=/home/petmay01/avocado/data/cache/by_location/0154b7cd3a4f5e135299060c8cabbeec10b70b6d/alpine-standard-3.17.2-aarch64.iso,format=raw >>> \ >>> -device virtio-rng-pci,rng=rng0 \ >>> -object rng-random,id=rng0,filename=/dev/urandom \ >>> -chardev file,id=chr0,path=/tmp/uart0-rev.txt \ >>> -chardev file,id=chr1,path=/tmp/uart1-rev.txt \ >>> -serial chardev:chr0 -serial chardev:chr1 >>> >>> (adjust -serial options to taste) >> >> Is the "uart-edk-investigation" branch still the most recent one for >> this? (I've not checked it yet, but coming close.) > > I checked out your branch and built it at commit "virt: Reverse order of UART > dtb nodes". > > I included my edk2 patches in my edk2 binary. > > The QEMU command line is > > /opt/qemu-installed-optimized/bin/qemu-system-aarch64 \ > -device virtio-gpu-pci \ > -machine virt,acpi=on,virtualization=on,mte=on,gic-version=max,iommu=smmuv3 > \ > -smp 2 \ > -m 1024 \ > -cpu max,pauth-impdef=on \ > -drive > if=pflash,file=/home/virt-images/arm/QEMU_EFI.fd.padded,format=raw,readonly=on > \ > -drive > if=pflash,file=/home/virt-images/arm/QEMU_VARS.fd.padded,format=raw,snapshot=on > \ > -drive > if=none,file=/home/lacos/tmp/alpine-standard-3.18.4-aarch64.iso,format=raw,readonly=on,id=alpine > \ > -device virtio-scsi-pci,id=vscsi \ > -device scsi-cd,drive=alpine,bus=vscsi.0,bootindex=1 \ > -device virtio-rng-pci,rng=rng0 \ > -object rng-random,id=rng0,filename=/dev/urandom \ > -device qemu-xhci,id=xhci \ > -device usb-kbd,bus=xhci.0 \ > -chardev stdio,mux=on,id=monitor-and-console \ > -mon chardev=monitor-and-console,mode=readline \ > -serial chardev:monitor-and-console \ > -chardev file,id=debug-log,path=/home/lacos/tmp/debug.txt \ > -serial chardev:debug-log > > With this command line, I have three windows to watch: > > (1) a graphical guest display window (virtio-gpu-pci), supposed to serve the > following purposes: > (1.1) multiplexed output from the UEFI console, > (1.2) Linux virtual console (in character mode) > > (2) the terminal where I start the command from, supposed to serve (mux / > C-a) the following purposes: > (2.1) the QEMU monitor, > (2.2) the guest serial port that is *supposed* to serve the following > purposes: > (2.2.1) direct SerialPortLib usage from edk2 modules, > (2.2.2) the UEFI console, > (2.2.3) the Linux boot log and a serial login prompt > > (3) a separate terminal where I run "tail -F debug.txt", intending to see: > (3.1) the edk2 DEBUG log > > Also I intend to provide input via: > (4) USB-3 keyboard when focusing the graphical window (1) > (5) QEMU monitor commands in the terminal where I start QEMU (2) > (6) serial input to the guest in the terminal where I start QEMU (2) > > Results: > > * edk2 writes the message > > UEFI firmware (version built at 03:38:24 on Oct 2 2023) > > to window (2), with direct SerialPortLib usage. > > * the edk2 DEBUG log goes solely to the file "debug.txt" / window (3), not > messing up the UEFI console (i.e., windows (1) and (2)) > > * the edk2 DEBUG log contains the following two lines: > > PlatformPeim: PL011 UART (console) @ 0x9000000 > PlatformPeim: PL011 UART (debug) @ 0x9040000 > > * the UEFI console output is properly multiplexed to windows (1) and (2), and > the UEFI console properly takes input from both (4) and (6). This covers both > the edk2 Boot Manager, and Grub from the alpine ISO. > > * in Grub, I replace alpine's default kernel option "quiet" with the two > options "ignore_loglevel efi=debug". (Because grub uses the UEFI console, it > properly takes input from both (4) and (6).) > > * I see the guest kernel's EFI Stub's messages on the UEFI console > (multiplexed to windows (1) and (2)) > > * I see the kernel boot log in window (2) -- that is, on the proper serial > port. This includes both kernel debug messages, and userspace boot log > messages > > * Finally I get the following printout: > > Welcome to Alpine Linux 3.18 > Kernel 6.1.55-0-lts on an aarch64 (TTY_LINE) > > in *all three* windows. Notably, the TTY_LINE value is the following: > > - in window (1) -- virtio-gpu-pci --, it is "/dev/tty1" > > - in window (2) (the "console" serial port) it is "/dev/ttyAMA0" > > - in window (3) (that is, the "debug.txt" file) it is "/dev/ttyAMA1" > > * Linux takes keyboard input in both windows (1) and (2) via (4) and (6) > respectively; (3) is not testable (and is not expected to take input) because > "-chardev file" is only good for output. > > So this is *total success*; the only (positive) surprise is that Linux > provides a login prompt on /dev/ttyAMA1 as well. > > * Rebuilding QEMU at the *parent* patch -- namely "add to acpi table" --, > that is, with patch "virt: Reverse order of UART dtb nodes" *popped*, all of > the above results remain identical. > > * dropping the "debug-log" chardev, and the serial port that references it, > from the QEMU cmdline, there is one difference (and those results generally > match the current upstream status): the edk2 DEBUG log is merged into the > UEFI console output as the latter is multiplexed to the sole serial port -- > making a mess for the reader. And of course Linux cannot offer a login prompt > on "/dev/ttyAMA1". > > I say we want this! > > I have one patch under review ("[edk2-devel] [PATCH 1/1] > ArmVirtPkg/FdtPL011SerialPortLib: initialize implicitly"), which is > independent, but contextually a pre-requisite for my "armvirt-dual-serial" > branch. Once that patch is merged, I'll post this branch. And I suggest going > forward with the QEMU-side patches as well. > > --*-- > > ... Just for kicks, I also tested the following change to the QEMU command > line: > > @@ -19,6 +19,7 @@ > -device usb-kbd,bus=xhci.0 \ > -chardev stdio,mux=on,id=monitor-and-console \ > -mon chardev=monitor-and-console,mode=readline \ > - -serial chardev:monitor-and-console \ > + -device virtio-serial-pci,id=vserial \ > + -device virtconsole,bus=vserial.0,chardev=monitor-and-console \ > -chardev file,id=debug-log,path=/home/lacos/tmp/debug.txt \ > -serial chardev:debug-log > > The behavior is not immediately intuitive, but it's correct after all. The > *sole* PL011 UART -- now in "debug.txt" in window (3) -- unifies several > purposes in edk2: UEFI console IO (including edk2 Boot manager and Grub), > direct SerialPortLib output, and DEBUG messages. The virtio-gpu-pci window > (1) functions undisturbed (UEFI console). The virtio serial console in window > (2) properly works as a "head" of the UEFI console. > > Even with the virtio serial console, I think that having *two* PL011 serial > ports will be beneficial. With virtio-serial plus *one* PL011, we can have > undisturbed non-graphical UEFI console, but there still isn't an undisturbed > DEBUG log -- the sole PL011 still includes both UEFI console (multiplexed) > and DEBUG. If we add in the second PL011, then the DEBUG log is pristine as > well, same as with isa-debugcon under x86. > > Furthermore, a disadvantage of virtio-serial plus *one* PL011 is that once I > boot Linux, the kernel log + userspace log goes to the PL011. That's a bit of > a UX disruption, because in this setup, we tend to look at the virtio-serial > console, due to the PL011 still being a mixture of UEFI console + DEBUG. So > the Linux boot log appears "elsewhere", and even the login prompt does not > appear on virtio-serial (probably because in this build of Alpine, no > virtio-serial driver is included; I guess anyway).
Based on Gerd's message <https://edk2.groups.io/g/devel/message/108958> though, it seems both of these issues can be mitigated: the login prompt on /dev/hvc0 should appear if the kernel / modules are built properly, and the kernel messages can be kept on virtio-serial with "console=hvc0". ... I've actually tried testing that now, too, with this build of Alpine. It seems to work, although the Linux boot log (kernel messages vs. userspace) doesn't seem to "settle" on virtio-serial versus the one PL011, for a ways into the Linux boot process. This would require more analysis (probably Linux kernel analysis), but my laptop battery is at 6%, and either way it's orthogonal to implementing two PL011 UARTs in qemu and edk2. Cheers Laszlo > > So either way, to mirror the x86 experience most closely (where we have > undisturbed UEFI console on the ISA serial port *and/or* on virtio serial; > *plus* undisturbed DEBUG output on isa-debugcon), we need two PL011 UARTs on > aarch64. With one PL011 plus virtio-serial, the UEFI console is cleaned up > (on virtio-serial), but the sole PL011 still contains a mixure of DEBUG and > UEFI console -- and that's the only way we get a (somewhat garbled) DEBUG log > in that setup. > > Thanks, > Laszlo > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#109269): https://edk2.groups.io/g/devel/message/109269 Mute This Topic: https://groups.io/mt/101498371/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
