On 05/30/16 19:49, Kinney, Michael D wrote: > 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
to ...? :) > > 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 ^ Thanks a lot, Mike, this looks awesome! I hope Jürgen can use it! Cheers Laszlo >> -----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