On Wed, Feb 13, 2013 at 01:13:45PM +0100, Laszlo Ersek wrote:
On 02/13/13 06:19, Kevin O'Connor wrote:
I think it's possible to get it working with CONFIG_QEMU_HARDWARE with something like the patch below.
Are two builds necessary with this change? One with CSM && QEMU_HARDWARE (which will build a CSM-ized bios.bin that logs to the debug port, and a vgabios.bin that doesn't), and another with QEMU (implying QEMU_HARDWARE, from which build the bios.bin is to be ignored for CSM purposes, and the vgabios.bin is to be installed, because it logs to the debug port)?
If building for CSM, it's a separate build anyway - one for bios.bin for QEMU and one for bios.bin for CSM (and another for bios.bin.elf for coreboot if desired). It only makes sense to build the vgabios under QEMU as the virtual vga hardware is not really like any real hardware (and the goal is for the CSM bios.bin to be to run on real hardware).
Also, the current SeaVGABIOS code is checking for "!COREBOOT" in its Kconfig file - that should be changed to "QEMU". With that fixed this will be even less of a concern. (It really only makes sense to build a cirrus/bochs vgabios for QEMU - which would always have the debug port available.)
Yes, I think it would eliminate the non-debugport-logging vgabios.bin from the first (== CSM && QEMU_HARDWARE) build above.
... However, I think the (CSM && QEMU_HARDWARE) bios.bin would still not log to the debug port. The (GET_GLOBAL(PlatformRunningOn) & PF_QEMU) part would evaluate to false, for two reasons: first, qemu_ramsize_preinit() will not set the flag when !CONFIG_QEMU (which is implied by CONFIG_CSM); second, qemu_ramsize_preinit() is never even invoked in the CSM build.
It would be incorrect to call qemu_ramsize_preinit in a CSM boot as the ramsize needs to come from UEFI in that situation (and not directly from QEMU). I think the high-level plan in this case is to detect that the code is running under QEMU by inspecting the SMBIOS tables passed in from UEFI and then set the flag.
-Kevin