On Sa, 2014-09-27 at 18:06 -0400, Gabriel L. Somlo wrote:
> Factor out logic to distinguish between Q35 and PIIX4 platforms
> into a separate header (OvmfPkg/Include/Library/PciHostBridge.h),
> then refer to these macros from all relevant source locations
> throughouth OvmfPkg.
> 
> This patch also adds a Q35-specific PIC IRQ routing initialization
> function to OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Gabriel Somlo <[email protected]>
> ---
> 
> As discussed with Laszlo and Paolo in an earlier thread, this stuff should
> hopefully be mostly uncontroversial and "the right thing to do" to support
> Q35. Doesn't fix my weird OS X / Q35 / UHCI issues, but I guess that's a
> whole different fight to be fought another day :)

It is definitively a step into the right direction, even if the puzzle
isn't completely solved yet.

> The one thing I'm a bit unsure about is PciInitializationQ35 (BdsPlatform.c);
> In PciInitializationPIIX (which used to be plain PciInitialization before
> this patch), there's a whole bunch of other devices (ide, video, network,
> etc.) being initialized by writing to registers

That is wrong.  The function should only initialize the chipset, i.e
devices 0 (northbridge) and 1 (southbridge).  Everything else is just a
shot into the dark, hoping the devices are there.  Which is the case in
a default qemu configuration, i.e. if you boot the system with just
"qemu -hda $image" and let qemu add default vga+nic.  It is possible to
configure qemu completely different though.

cheers,
  Gerd



------------------------------------------------------------------------------
Slashdot TV.  Videos for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Reply via email to