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

Reply via email to