On Thu, 2013-02-07 at 20:48 -0500, Kevin O'Connor wrote:
So, at this point, I think still pending is: Kconfig changes, pmtimer, UmbStart/UmbEnd, and unaligned PCIR.
I've pushed these remaining changes, rebased and slightly retested, to my git tree. The pmtimer support still needs testing for Xen and Coreboot. And it wouldn't hurt to test find_resume_vector() either.
The pmtimer thing is just an optimisation, as is the pedantry about PCIR tables — when they don't work, I don't want it to be just *my* fault ;)
UmbStart/UmbEnd can wait until OVMF catches up, I agree — although in that case we ought to point people at a simple patch for OVMF that just disables the LegacyRegion->Lock completely. Like the one I sent you the other night. I note we aren't giving *any* build instructions at the moment; you dropped my README.CSM without merging it into README?
The real problem with the current tree is the Kconfig changes. What you've committed still doesn't let me enable the virtio-blk driver when I've configured it to build as CSM. And in fact I don't understand why you force those to be disabled for the coreboot case either, if you can be booted from coreboot under qemu.
See the final two patches in my git tree... I wouldn't mind getting these merged so that they're part of the *base* for your subsequent Kconfig changes.
commit 1c78b74a62a178050c1e9763b0943725a32ec060 Author: David Woodhouse David.Woodhouse@intel.com Date: Fri Feb 8 08:52:32 2013 +0000
Clean up Kconfig options for CSM
It makes no sense to turn CONFIG_OPTIONROMS on or off because we call directly into callrom() anyway. Likewise CONFIG_OPTIONROMS_DEPLOYED is never going to make any difference.
Also force CONFIG_BOOT to be enabled; we definitely need that to work.
Signed-off-by: David Woodhouse David.Woodhouse@intel.com
commit 3a98c83e12c719dfb5e2f6fd195068b23ac3b78a Author: David Woodhouse David.Woodhouse@intel.com Date: Fri Feb 8 08:11:18 2013 +0000
Enable virtio devices for CSM build
These shouldn't depend purely on CONFIG_QEMU, as CSM can be used under Qemu too. In fact, can't we boot via Coreboot under Qemu also? Why restrict these hardware drivers at all?
Signed-off-by: David Woodhouse David.Woodhouse@intel.com
diff --git a/src/Kconfig b/src/Kconfig index aa0e49e..459708c 100644 --- a/src/Kconfig +++ b/src/Kconfig @@ -124,25 +124,25 @@ menu "Hardware support" help Support for AHCI disk code. config VIRTIO_BLK - depends on DRIVES && QEMU + depends on DRIVES && !COREBOOT bool "virtio-blk controllers" default y help Support boot from virtio-blk storage. config VIRTIO_SCSI - depends on DRIVES && QEMU + depends on DRIVES && !COREBOOT bool "virtio-scsi controllers" default y help Support boot from virtio-scsi storage. config ESP_SCSI - depends on DRIVES && QEMU + depends on DRIVES && !COREBOOT bool "AMD PCscsi controllers" default y help Support boot from AMD PCscsi storage. config LSI_SCSI - depends on DRIVES && QEMU + depends on DRIVES && !COREBOOT bool "lsi53c895a scsi controllers" default y help @@ -287,7 +287,7 @@ menu "BIOS interfaces" help Support PnP BIOS entry point. config OPTIONROMS - bool "Option ROMS" + bool "Option ROMS" if !CSM default y help Support finding and running option roms during POST. @@ -300,7 +300,7 @@ menu "BIOS interfaces" be accepted by other firmwares. config OPTIONROMS_DEPLOYED depends on OPTIONROMS - bool "Option roms are already at 0xc0000-0xf0000" + bool "Option roms are already at 0xc0000-0xf0000" if !CSM default n help Select this if option ROMs are already copied to @@ -313,7 +313,7 @@ menu "BIOS interfaces" help Support Post Memory Manager (PMM) entry point. config BOOT - bool "Boot interface" + bool "Boot interface" if !CSM default y help Support int 19/18 system bootup support.