OvmfPkg/Include/Guid/QemuRamfb.h | 25 ++ .../Library/PlatformBootManagerLib/PlatformData.c | 44 +++ OvmfPkg/QemuRamfbDxe/QemuRamfb.c | 308 +++++++++++++++++++++ ArmVirtPkg/ArmVirtQemu.dsc | 2 + ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc | 1 + ArmVirtPkg/ArmVirtQemuKernel.dsc | 2 + OvmfPkg/OvmfPkg.dec | 1 + OvmfPkg/OvmfPkgIa32.dsc | 1 + OvmfPkg/OvmfPkgIa32.fdf | 1 + OvmfPkg/OvmfPkgIa32X64.dsc | 1 + OvmfPkg/OvmfPkgIa32X64.fdf | 1 + OvmfPkg/OvmfPkgX64.dsc | 1 + OvmfPkg/OvmfPkgX64.fdf | 1 + OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf | 34 +++ 14 files changed, 423 insertions(+) create mode 100644 OvmfPkg/Include/Guid/QemuRamfb.h create mode 100644 OvmfPkg/QemuRamfbDxe/QemuRamfb.c create mode 100644 OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf
This is the efi driver for qemu ramfb, a simple boot framebuffer. Qemu patches just have been posted to qemu-devel. Gerd Hoffmann (4): OvmfPkg: add QEMU_RAMFB_GUID OvmfPkg: add QemuRamfbDxe OvmfPkg: add QemuRamfb to platform console ArmVirtPkg: add QemuRamfbDxe OvmfPkg/Include/Guid/QemuRamfb.h | 25 ++ .../Library/PlatformBootManagerLib/PlatformData.c | 44 +++ OvmfPkg/QemuRamfbDxe/QemuRamfb.c | 308 +++++++++++++++++++++ ArmVirtPkg/ArmVirtQemu.dsc | 2 + ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc | 1 + ArmVirtPkg/ArmVirtQemuKernel.dsc | 2 + OvmfPkg/OvmfPkg.dec | 1 + OvmfPkg/OvmfPkgIa32.dsc | 1 + OvmfPkg/OvmfPkgIa32.fdf | 1 + OvmfPkg/OvmfPkgIa32X64.dsc | 1 + OvmfPkg/OvmfPkgIa32X64.fdf | 1 + OvmfPkg/OvmfPkgX64.dsc | 1 + OvmfPkg/OvmfPkgX64.fdf | 1 + OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf | 34 +++ 14 files changed, 423 insertions(+) create mode 100644 OvmfPkg/Include/Guid/QemuRamfb.h create mode 100644 OvmfPkg/QemuRamfbDxe/QemuRamfb.c create mode 100644 OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf -- 2.9.3 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
On 06/08/18 13:39, Gerd Hoffmann wrote: > This is the efi driver for qemu ramfb, a simple boot framebuffer. > Qemu patches just have been posted to qemu-devel. > > Gerd Hoffmann (4): > OvmfPkg: add QEMU_RAMFB_GUID > OvmfPkg: add QemuRamfbDxe > OvmfPkg: add QemuRamfb to platform console > ArmVirtPkg: add QemuRamfbDxe > > OvmfPkg/Include/Guid/QemuRamfb.h | 25 ++ > .../Library/PlatformBootManagerLib/PlatformData.c | 44 +++ > OvmfPkg/QemuRamfbDxe/QemuRamfb.c | 308 +++++++++++++++++++++ > ArmVirtPkg/ArmVirtQemu.dsc | 2 + > ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc | 1 + > ArmVirtPkg/ArmVirtQemuKernel.dsc | 2 + > OvmfPkg/OvmfPkg.dec | 1 + > OvmfPkg/OvmfPkgIa32.dsc | 1 + > OvmfPkg/OvmfPkgIa32.fdf | 1 + > OvmfPkg/OvmfPkgIa32X64.dsc | 1 + > OvmfPkg/OvmfPkgIa32X64.fdf | 1 + > OvmfPkg/OvmfPkgX64.dsc | 1 + > OvmfPkg/OvmfPkgX64.fdf | 1 + > OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf | 34 +++ > 14 files changed, 423 insertions(+) > create mode 100644 OvmfPkg/Include/Guid/QemuRamfb.h > create mode 100644 OvmfPkg/QemuRamfbDxe/QemuRamfb.c > create mode 100644 OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf > Some testing related questions: - What happens in the UEFI shell if you do recursive connect/disconnect cycles for all handles in the system? (Preferably initiated from serial.) - What happens if you locate the parent handle (with the VenHw node) and/or the child handle (with the GOP on it), and try to disconnect them? - Have you tested mode changes with the MODE command? Expected results: - recursive connect / disconnect should not break, as far as the entire system is concerned; the procedure should simply skip ramfb. - targeted connect / disconnect for ramfb should fail (produce an error message), but nothing should crash or stop working. - mode changes should work. I expect the first two behaviors because the driver is a platform DXE driver, not a UEFI driver that conforms to the UEFI driver model -- we don't install an EFI_DRIVER_BINDING_PROTOCOL instance, hence the driver should be "invisible" to the connect / disconnect UEFI shell commands (they should fail gracefully). Thanks, Laszlo _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Hi, > - What happens in the UEFI shell if you do recursive connect/disconnect > cycles for all handles in the system? (Preferably initiated from serial.) Seems to work fine (tried "disconnect -a" and "connect"). > - What happens if you locate the parent handle (with the VenHw node) > and/or the child handle (with the GOP on it), and try to disconnect them? How can I do that? > - Have you tested mode changes with the MODE command? Yes, works. cheers, Gerd _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
On 06/12/18 11:21, Gerd Hoffmann wrote: > Hi, > >> - What happens in the UEFI shell if you do recursive connect/disconnect >> cycles for all handles in the system? (Preferably initiated from serial.) > > Seems to work fine (tried "disconnect -a" and "connect"). Cool. > >> - What happens if you locate the parent handle (with the VenHw node) >> and/or the child handle (with the GOP on it), and try to disconnect them? > > How can I do that? Run "dh -d -v -p GraphicsOutput". The listing will include all handles (represented by hex identifiers) that carry a GOP. Each handle will also have its device path protocol instance displayed, in textual representation, so if there are multiple GOPs, you'll be able to locate the one produced by QemuRamfbDxe. The listing should also reference the parent controller handle. Knowing the hex identifiers for parent and child, experiment with the "disconnect" command. (See "help disconnect" for syntax.) >> - Have you tested mode changes with the MODE command? > > Yes, works. Nice! Thansk Laszlo _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Hi, > >> - What happens if you locate the parent handle (with the VenHw node) > >> and/or the child handle (with the GOP on it), and try to disconnect them? > > > > How can I do that? > > Run "dh -d -v -p GraphicsOutput". The listing will include all handles > (represented by hex identifiers) that carry a GOP. Each handle will also > have its device path protocol instance displayed, in textual > representation, so if there are multiple GOPs, you'll be able to locate > the one produced by QemuRamfbDxe. The listing should also reference the > parent controller handle. > > Knowing the hex identifiers for parent and child, experiment with the > "disconnect" command. (See "help disconnect" for syntax.) Shell> dh -p GraphicsOutput Handle dump by protocol 'GraphicsOutput' 44: ConsoleOut SimpleTextOut GraphicsOutput(GraphicsOutput) DevicePath(..C08C457)/AcpiAdr(0x80010300)) 6D: GraphicsOutput(GraphicsOutput) SimpleTextOut Shell> disconnect 6d Disconnect - (6D,3E643560,3E5C3A03) Result Success. Shell> disconnect 44 Disconnect - (44,3E643560,3E5C3A03) Result Success. Shell> The second disconnect makes ovmf stop using ramfb as console (serial continues to work). cheers, Gerd _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
On 06/13/18 09:40, Gerd Hoffmann wrote: > Hi, > >>>> - What happens if you locate the parent handle (with the VenHw node) >>>> and/or the child handle (with the GOP on it), and try to disconnect them? >>> >>> How can I do that? >> >> Run "dh -d -v -p GraphicsOutput". The listing will include all handles >> (represented by hex identifiers) that carry a GOP. Each handle will also >> have its device path protocol instance displayed, in textual >> representation, so if there are multiple GOPs, you'll be able to locate >> the one produced by QemuRamfbDxe. The listing should also reference the >> parent controller handle. >> >> Knowing the hex identifiers for parent and child, experiment with the >> "disconnect" command. (See "help disconnect" for syntax.) > > Shell> dh -p GraphicsOutput > Handle dump by protocol 'GraphicsOutput' > 44: ConsoleOut SimpleTextOut GraphicsOutput(GraphicsOutput) DevicePath(..C08C457)/AcpiAdr(0x80010300)) > 6D: GraphicsOutput(GraphicsOutput) SimpleTextOut > Shell> disconnect 6d > Disconnect - (6D,3E643560,3E5C3A03) Result Success. > Shell> disconnect 44 > Disconnect - (44,3E643560,3E5C3A03) Result Success. > Shell> > > The second disconnect makes ovmf stop using ramfb as console (serial continues > to work). I'll follow up under your v3 series: [edk2] [PATCH v3 0/4] Add QemuRamfbDxe driver http://mid.mail-archive.com/20180613072936.12480-1-kraxel@redhat.com Thanks, Laszlo _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
© 2016 - 2024 Red Hat, Inc.