Laszlo,

I have used the UART based source level debug using QEMU on Windows with UDK 
Debugger
Tool and WinDbg.  I configure QEMU to redirect UART to TCPIP port on the same 
system 
that is running QEMU.  This is the fastest debug environment for UDK Debugger 
Tool
I have used because the UART to TCPIP is all memory based on same system.  I 
use 
TeraTerm as serial terminal console into the QEMU monitor and EDK II firmware.

The OVMF build commands I use to enable source debug and UART are:

  build -a IA32        -n 5 -t VS2015x86 -p OvmfPkg\OvmfPkgIa32.dsc    -D 
SMM_REQUIRE -D DEBUG_ON_SERIAL_PORT -D SOURCE_DEBUG_ENABLE
  build -a IA32 -a X64 -n 5 -t VS2015x86 -p OvmfPkg\OvmfPkgIa32X64.dsc -D 
SMM_REQUIRE -D DEBUG_ON_SERIAL_PORT -D SOURCE_DEBUG_ENABLE
  build -a X64         -n 5 -t VS2015x86 -p OvmfPkg\OvmfPkgX64.dsc     -D 
SMM_REQUIRE -D DEBUG_ON_SERIAL_PORT -D SOURCE_DEBUG_ENABLE

An example command script for 32-bit OVMF I use to launch QEMU, UDK Debugger 
Tool, 
WinDbg, and 2 TeraTerm consoles is shown below.  Specific flags to QEMU can be 
adjusted as
needed.  The TeraTerm consoles are launched first.  They will try for a couple 
seconds
before failing.  It is important 

  set QEMU_PATH=C:\Program Files\Qemu
  set EDKII_BUILD_OUTPUT=%WORKSPACE%\Build\OvmfIa32\DEBUG_VS2015x86

  start "Monitor"  /B "c:\Program Files (x86)\teraterm\ttermpro.exe" 
localhost:20717 /nossh
  start "Debugger" /B "C:\Program Files (x86)\Intel\Intel(R) UEFI Development 
Kit Debugger Tool\eXdi.exe" /LaunchWinDbg
  start "Console"  /B "c:\Program Files (x86)\teraterm\ttermpro.exe" 
localhost:20715 /nossh

  start "QEMU" /B "%QEMU_PATH%\qemu-system-i386w.exe"   -machine 
q35,smm=on,accel=tcg -net none -cpu Nehalem -global ICH9-LPC.disable_s3=1 ^
  -drive 
if=pflash,format=raw,unit=0,file=%EDKII_BUILD_OUTPUT%\FV\OVMF_CODE.fd,readonly=on
 ^
  -drive if=pflash,format=raw,unit=1,file=%EDKII_BUILD_OUTPUT%\FV\OVMF_VARS.fd ^
  -monitor tcp:localhost:20717,server ^
  -serial tcp:localhost:20716,server ^
  -smp 8 ^

Best regards,

Mike





> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo 
> Ersek
> Sent: Monday, May 30, 2016 9:19 AM
> To: Juergen Rall <r...@sybera.de>
> Cc: edk2-de...@ml01.01.org
> Subject: Re: [edk2] UDK2015 Source Line Debugging
> 
> On 05/30/16 10:00, Juergen Rall wrote:
> >> Anyway, I have tried the UDK Debugger once before, between two QEMU
> >> virtual machines whose serial ports I connected. Unfortunately the setup
> >> didn't work for me, the initial handshake never seemed to complete
> >> between the debug agent and the debugger.
> >>
> >> For debugging OVMF (and perhaps debugging out-of-tree code running on
> >> it), in a QEMU virtual machine, you can find a write-up here:
> >> <https://edk2.bluestop.org/w/tianocore/debugging-with-gdb/>.
> >>
> >> Laszlo
> >>
> >
> > I want to debug a EDK2 emulation environment with WINDBG.
> 
> Would Nt32Pkg work for you?
> 
> > As mentioned, the EDK2 OVMF emulation works fine on Windows 10, but when I
> > try to connect via com0com to WINDBG, initial handshake fails. Its a Windows
> > environment, so I can't use GDB.
> 
> I never tried such a setup, but if it involves QEMU's serial port
> emulation (and I think it does), then in my experience that serial port
> emulation is not true enough to a physical UART's timings and other
> properties for the UDK debug agent protocol to work.
> 
> Thanks
> Laszlo
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Reply via email to