Subject: Re: [edk2] Xen OVMF early discussions
From: Bei Guan <firstname.lastname@example.org>
To: Andrei Warkentin <email@example.com>
Date: 2011-05-13 17:20:54
As Jordan mentioned, this is a recent update. Do "svn update" to get
On Thu, May 12, 2011 at 9:55 AM, Bei Guan <firstname.lastname@example.org> wrote:
> Hi Andrei,
> 2011/5/12 Andrei Warkentin <email@example.com>
>> On Wed, May 11, 2011 at 1:30 PM, Jordan Justen <firstname.lastname@example.org> wrote:
>> > On Wed, May 11, 2011 at 00:15, Andrei Warkentin <email@example.com>
>> > wrote:
>> >> Looks like it was trying to read the EDID
>> >> (http://en.wikipedia.org/wiki/Extended_display_identification_data)
>> >> while initializing the video.
>> > The latest OVMF is using OvmfPkg/QemuVideoDxe and it doesn't read EDID.
>> I quickly tested with latest OVMF (+patch) and it still hangs. Though
>> not in the video driver. In fact, it would appear that the video
>> didn't get detected :(.
> From our boot trace message, OVMF on Xen uses the
> OptionRomPkg/CirrusLogic5430Dxe driver, notOvmfPkg/QemuVideoDxe as OVMF on
> QEMU. Doesn't the CirrusLogic5430Dxe driver support OVMF on Xen? And maybe
> we need to change something of this driver.
the latest. You should probably instrument the
QemuVideoDxe driver and see what it is (and isn't) doing.
I had a different base, but I'm guessing yes. No, shouldn't...>
>> gdb) bt
>> #0 0x01ecc8da in CoreCheckEvent (UserEvent=0xfc5f10) at
>> #1 0x01ecc96b in CoreWaitForEvent (NumberOfEvents=1,
>> UserEvents=0x1ec0ea0, UserIndex=0x1ec0e9c)
>> at /home/fjnh84/src/edk2/MdeModulePkg/Core/Dxe/Event/Event.c:621
>> #2 0x01dc7317 in PlatformBdsPolicyBehavior
>> (DriverOptionList=0x1ec0ef8, BootOptionList=0x1ec0ef0,
>> ProcessCapsules=0x1daf7db <BdsProcessCapsules>,
>> BaseMemoryTest=0x1daf3e8 <BdsMemoryTest>)
>> #3 0x01dae9b1 in BdsEntry (This=0x1dd2bb0)
>> #4 0x01ec1e68 in DxeMain (HobStart=0x1cb9010) at
>> #5 0x01ec1254 in _ModuleEntryPoint (HobStart=0xd20000)
>> #6 0xc2c2c2c2 in ?? ()
>> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
>> The backtrace basically shows it sitting waiting for user input...
>> I'm getting tired of manually doing add-symbol-files, so I started
>> working on a gdb script to do it automatically. Progress is a bit
>> slower than I wanted it to be because of the awkwardness of the GDB
>> Python bindings (esp in older versions of gdb)
>> It's just simpler to link in the
>> ArmPkg/Library/DebugPeCoffExtraActionLib instead of the Null one, and
>> grep for add-symbol-file strings. With the caveat that there is a bug
>> in that Library that doesn't account for the case where there is no
>> debugging data (there is one driver like that... unsure what it is...
>> maybe the binary-only Shell or Fat32? I didn't dig deep enough).
> Do you mean the following driver in the boot trace message. I get all the
> other driver names except this one all the time. I hopeit will not affect
> our project.
> Loading driver 961578FE-B6B7-44C3-AF35-6BC705CD2B1F
> InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B 3EB07DA8
> Loading driver at 0x0003E4E4000 EntryPoint=0x0003E4E4427
Sorry, typo, pasted the wrong thing.
>> In fact the stuff in ArmPkg/Library/DebugPeCoffExtraActionLib is
>> generic enough that it should be moved out of ArmPkg... Thoughts?
>> Bei: This should make your life easier - apply patch and change DSC to
>> use ArmPkg/Library/DebugPeCoffExtraActionLib/DebugPeCoffExtraActionLib.inf
>> instead of DebugAgentLibNull.inf. Now you can dump the output of xm
>> create domname -c into a file, grep out the add-symbol-file lines
>> into a separate file, then make gdb read it by running "source
>> filename" at gdb prompt.
> I think it should replace BasePeCoffExtraActionLibNull.inf, not
> DebugAgentLibNull.inf. And when I replace it, I can do the add-symbol-file
> as you say. It's really very convenient and it save me much time. Thanks a
> lot. :)