[if gte mso 9]>

Re: [edk2] OVMF networking revisited

Subject: Re: [edk2] OVMF networking revisited

From: "Kinney, Michael D" <michael.d.kinney@intel.com>

To: "edk2-devel@lists.sourceforge.net" <edk2-devel@lists.sourceforge.net>

Date: 2013-04-12 00:30:40

My next suggestion is to use the –y and –Y flags to the build.exe command to generate a report and review the PCD value used to see if the they are being set to the expected value of 0xB000 and not 0x400.


The next step after that is to review the AutoGen.h files in the build output directory for the modules that are getting the incorrect 0x400 values in the OBJs to verify that the AutoGen.h has 0x400.


If you explicitly set the PCD value in your DSC file to different values, you should see that value in the –Y report file and the AutoGen.h files.  If not, then something odd happening with build tools.




From: Duane Voth [mailto:duanev@gmail.com]
Sent: Thursday, April 11, 2013 7:49 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] OVMF networking revisited


How is [it] possible [that AcpiTimerLibConstructor() runs in 32bit mode] ? AFAIR you have an X64 build.


Laszlo, I'm just reporting what gdb is demanding: "set arch i386" for the constructor (which displays 32bit flat 0xfffcxxxx addresses), and "set arch i386:x86-64" for the hang location (which displays 64bit flat 0x3e55xxxx addresses).  Since OVMF is a boot rom it has to bring the cpu up from i8086 to i386 to x86-64 modes and apparently various parts of the code run in different modes.


find Build -type f -name '*.obj' -print0 \
| xargs -0 -r -- objdump -d -- >~/tmp/disasm

less ~/tmp/disasm
Then search for \$0x408, and scroll up for the function name. In my
build there are three functions with this constant:
- UnicodeStrToAsciiStr
- LibPatchPcdSetPtr
- EhcAsyncInterruptTransfer

None of which seem relevant.


Yes, that's what I'm finding as well.  And looking at AcpiTimerLib.obj via objdump tells me that the hang code is not from AcpiTimerLib at all.


Is there any chance you have pulled in the TscTimerLib from the PerformancePkg into the X64 part of your build?


Michael, well, there is no TscTimerLib.obj in Build/OvmfX64/DEBUG_GCC46/X64 (and in fact no where in the Build directory at all), I've never built the PerformancePkg.



Curiouser and curiouser ... even the .efi files, scanned with


find Build -type f -name '*.efi' -print0 | xargs -0 -r -- objdump -d -- | grep '$0x408,'


return *only*   mov $0x408,%edx   where clearly the executing code includes    mov $0x408,%ecx  !   Where is this bit of rogue code coming from??




What prevents you from setting DEBUG_VERBOSE


With DEBUG_VERBOSE on and -debugcon file:debug.log -global isa-debugcon.iobase=0x402  added to the qemu command line, debug.log remains empty.  I've never seen any debug output from this flag nor via -debugcon.  My OVMF build line is:


$ build -D SOURCE_DEBUG_ENABLE -D FD_SIZE_2MB -D DEBUG_ON_SERIAL_PORT -p OvmfPkg/OvmfPkgX64.dsc -a X64 -t GCC46


(when I add other debug code and rebuild, I do see the changes in gdb so I'm not missing something obvious)


Yes it is very easy to rebuild OVMF and try it out with qemu+gdb which is why I'm pushing to get debug with symbols working -- my other avenue (an In circuit Test Probe on real hardware will be laborious).