Re: [SeaBIOS] Moving BIOS tables from SeaBIOS to QEMU
On 02/26/13 19:30, Laszlo Ersek wrote: On 02/26/13 10:03, Gerd Hoffmann wrote: Can tianocore grab acpi tables from coreboot? Not that I know of. (... It may have been a rhetorical question.) Wasn't rhetorical. Generating the apci tables in both ovmf and seabios doesn't make that much sense, better would be to have that in one place. Option one is to let qemu provide them, then both ovmf and seabios can grab them via fw_cfg. Option two is to use coreboot underneath, then let both seabios and ovmf grab the tables from coreboot. Which of course requires that ovmf can use the tables provided by coreboot. Seabios can do that today. /me looked around a bit in the coreboot source code. Looks like they simply copyed over the dsdt from seabios as-is, which doesn't fly due to the pci _crs method referencing ssdt's BDAT. From the quick look it seems they do *not* generate the dsdt dynamically, only the other tables (simliar to seabios). So switching to coreboot probably doesn't help to remove the dsdt patching code we have in seabios. When running on Xen, an area is searched for the RSDP, and linked tables (prepared by Xen's hvmloader I think) are installed by OVMF. Ok, so doing something simliar when running on coreboot should be possible without major headache. When running on qemu, static tables are used. I strived to adapt them as much as I could to qemu hardware. Some tables (recognized by header) are copied modified dynamically before installation: MADT, SSDT. Getting a precise picture of qemu hardware in the form of ACPI tables (over fw_cfg) would not only allow OVMF to pass on better tables to OSPM; OVMF could *maybe* use them itself. qemu 1.4+ places the dsdt into fw_cfg. But again, that is the one which references BDAT, so using it as-is in ovmf isn't going to fly ... cheers, Gerd ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Moving BIOS tables from SeaBIOS to QEMU
On 02/27/13 10:19, Gerd Hoffmann wrote: On 02/26/13 19:30, Laszlo Ersek wrote: On 02/26/13 10:03, Gerd Hoffmann wrote: Can tianocore grab acpi tables from coreboot? Not that I know of. (... It may have been a rhetorical question.) Wasn't rhetorical. Generating the apci tables in both ovmf and seabios doesn't make that much sense, better would be to have that in one place. Option one is to let qemu provide them, then both ovmf and seabios can grab them via fw_cfg. Option two is to use coreboot underneath, then let both seabios and ovmf grab the tables from coreboot. Which of course requires that ovmf can use the tables provided by coreboot. Seabios can do that today. /me looked around a bit in the coreboot source code. Looks like they simply copyed over the dsdt from seabios as-is, which doesn't fly due to the pci _crs method referencing ssdt's BDAT. From the quick look it seems they do *not* generate the dsdt dynamically, only the other tables (simliar to seabios). So switching to coreboot probably doesn't help to remove the dsdt patching code we have in seabios. When running on Xen, an area is searched for the RSDP, and linked tables (prepared by Xen's hvmloader I think) are installed by OVMF. Ok, so doing something simliar when running on coreboot should be possible without major headache. When running on qemu, static tables are used. I strived to adapt them as much as I could to qemu hardware. Some tables (recognized by header) are copied modified dynamically before installation: MADT, SSDT. Getting a precise picture of qemu hardware in the form of ACPI tables (over fw_cfg) would not only allow OVMF to pass on better tables to OSPM; OVMF could *maybe* use them itself. qemu 1.4+ places the dsdt into fw_cfg. But again, that is the one which references BDAT, so using it as-is in ovmf isn't going to fly ... As far as I understood Kevin suggested to - remove the BDAT (FWDT in OVMF) and the related DSDT logic, - prepare the byte-code of the CRS dynamically from a template (t could be a Name instead of a Method) and patch the ranges before installation. Laszlo ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Moving BIOS tables from SeaBIOS to QEMU
On Wed, Feb 27, 2013 at 03:09:25PM +0100, Laszlo Ersek wrote: On 02/27/13 10:19, Gerd Hoffmann wrote: On 02/26/13 19:30, Laszlo Ersek wrote: On 02/26/13 10:03, Gerd Hoffmann wrote: Can tianocore grab acpi tables from coreboot? Not that I know of. (... It may have been a rhetorical question.) Wasn't rhetorical. Generating the apci tables in both ovmf and seabios doesn't make that much sense, better would be to have that in one place. Option one is to let qemu provide them, then both ovmf and seabios can grab them via fw_cfg. Option two is to use coreboot underneath, then let both seabios and ovmf grab the tables from coreboot. Which of course requires that ovmf can use the tables provided by coreboot. Seabios can do that today. /me looked around a bit in the coreboot source code. Looks like they simply copyed over the dsdt from seabios as-is, which doesn't fly due to the pci _crs method referencing ssdt's BDAT. From the quick look it seems they do *not* generate the dsdt dynamically, only the other tables (simliar to seabios). So switching to coreboot probably doesn't help to remove the dsdt patching code we have in seabios. When running on Xen, an area is searched for the RSDP, and linked tables (prepared by Xen's hvmloader I think) are installed by OVMF. Ok, so doing something simliar when running on coreboot should be possible without major headache. When running on qemu, static tables are used. I strived to adapt them as much as I could to qemu hardware. Some tables (recognized by header) are copied modified dynamically before installation: MADT, SSDT. Getting a precise picture of qemu hardware in the form of ACPI tables (over fw_cfg) would not only allow OVMF to pass on better tables to OSPM; OVMF could *maybe* use them itself. qemu 1.4+ places the dsdt into fw_cfg. But again, that is the one which references BDAT, so using it as-is in ovmf isn't going to fly ... As far as I understood Kevin suggested to - remove the BDAT (FWDT in OVMF) and the related DSDT logic, - prepare the byte-code of the CRS dynamically from a template (t could be a Name instead of a Method) and patch the ranges before installation. My suggestion was to replace BDAT with a dynamically generated P0S (and P[01][SLE][LH]?) in an SSDT (by updating ssdt-sups.dsl). -Kevin ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
[SeaBIOS] RFC: Primary VGA
When we start adding root ports and bridges to systems we need some concept of a primary VGA device.The differentiation of the primary device is that it's the default one that responds to the Legacy VGA address ranges. PCs often have a BIOS selection for this. Seabios already seems to have some concept of this and looks for a VGA class device for which the parent devices all have VGA routing enabled. This seems to work today if QEMU initializes VGA routing for the path it considers the primary. The first question is whether this bridge path pre-configuration is what we want to keep as the way QEMU communicates the primary VGA device to Seabios? Obviously we could switch to some kind of fwcfg interface, but I tend to think what we have is sufficient. If it is sufficient, then I think we need to rebuild that path on system reset and we need some way to specify which device to use. One option would be some kind of per PCIDevice property, perhaps primary_vga. A downside is that users can abuse it by trying to set it for more than one device. Maybe a better approach would be to add a machine property for it, -machine primary_vga=$id. We'll also need some reasonable way to pick a default if unspecified. Does anyone have any thoughts on managing this? Thanks, Alex ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
[SeaBIOS] SeaBIOS v1.7.2.1 stable release
A new stable release of SeaBIOS (version 1.7.2.1) has been tagged. This release contains bug fixes, including several fixes for build problems. The release is available via git: git clone git://git.seabios.org/seabios -b 1.7.2-stable -Kevin Kevin O'Connor (4): Update tools/acpi_extract.py to handle iasl 20130117 release. Fix Makefile - don't reference out/ directly, instead use $(OUT). build: Don't require $(OUT) to be a sub-directory of the main directory. Verify CC is valid during build tests. Alex Williamson (3): seabios q35: Enable all PIRQn IRQs at startup seabios q35: Add new PCI slot to irq routing function seabios: Add a dummy PCI slot to irq mapping function Avik Sil (1): USB-EHCI: Fix null pointer assignment Makefile | 10 +- src/Kconfig |2 +- src/pciinit.c | 47 ++- src/usb-ehci.c|2 +- tools/acpi_extract.py |4 ++-- tools/test-build.sh | 23 +++ 6 files changed, 66 insertions(+), 22 deletions(-) ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] RFC: Primary VGA
On Wed, Feb 27, 2013 at 02:16:23PM -0700, Alex Williamson wrote: When we start adding root ports and bridges to systems we need some concept of a primary VGA device.The differentiation of the primary device is that it's the default one that responds to the Legacy VGA address ranges. PCs often have a BIOS selection for this. Seabios already seems to have some concept of this and looks for a VGA class device for which the parent devices all have VGA routing enabled. This seems to work today if QEMU initializes VGA routing for the path it considers the primary. The first question is whether this bridge path pre-configuration is what we want to keep as the way QEMU communicates the primary VGA device to Seabios? Obviously we could switch to some kind of fwcfg interface, but I tend to think what we have is sufficient. SeaBIOS uses the VGA PCI routing information to determine which option rom to run. However, it doesn't actually initialize the VGA PCI routing in it's PCI initialization code (pciinit.c). This isn't an issue for the default QEMU setup because QEMU does not place the VGA card behind a bus. However, should QEMU support multiple VGA cards and/or VGA cards behind a bus, then the PCI init code would likely need to handle VGA setup. (I suppose QEMU could setup the bus forwarding of the legacy VGA ranges, but it would seem ugly to have SeaBIOS do most of the PCI init while QEMU did this small part.) -Kevin ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] RFC: Primary VGA
On Wed, 2013-02-27 at 20:11 -0500, Kevin O'Connor wrote: On Wed, Feb 27, 2013 at 02:16:23PM -0700, Alex Williamson wrote: When we start adding root ports and bridges to systems we need some concept of a primary VGA device.The differentiation of the primary device is that it's the default one that responds to the Legacy VGA address ranges. PCs often have a BIOS selection for this. Seabios already seems to have some concept of this and looks for a VGA class device for which the parent devices all have VGA routing enabled. This seems to work today if QEMU initializes VGA routing for the path it considers the primary. The first question is whether this bridge path pre-configuration is what we want to keep as the way QEMU communicates the primary VGA device to Seabios? Obviously we could switch to some kind of fwcfg interface, but I tend to think what we have is sufficient. SeaBIOS uses the VGA PCI routing information to determine which option rom to run. However, it doesn't actually initialize the VGA PCI routing in it's PCI initialization code (pciinit.c). This isn't an issue for the default QEMU setup because QEMU does not place the VGA card behind a bus. However, should QEMU support multiple VGA cards and/or VGA cards behind a bus, then the PCI init code would likely need to handle VGA setup. (I suppose QEMU could setup the bus forwarding of the legacy VGA ranges, but it would seem ugly to have SeaBIOS do most of the PCI init while QEMU did this small part.) Supporting VGA behind root ports is inevitable, modern topologies demand it and I've got rough working code to enable it for assigned devices. Once we have root ports, there's no reason bridges shouldn't also be supported and maybe we can even deprecate the QEMU -vga option in favor if a regular -device option. It does make some sense that SeaBIOS initializes PCI, so should be responsible for this programming. Should we just start with a bus ordered search for the first PCI VGA class device we find and enable routing for that device? If we do that, perhaps we can defer the question of whether QEMU can specify an alternate primary device. Thanks, Alex ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Moving BIOS tables from SeaBIOS to QEMU
Gerd Hoffmann wrote: gets. It sounds like there will soon be need for a more generic PCI resource allocator, which is another thing that coreboot already has. --verbose please. Alex Williamson wrote: It does make some sense that SeaBIOS initializes PCI, so should be responsible for this programming. That. //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Moving BIOS tables from SeaBIOS to QEMU
Gerd Hoffmann wrote: Option one is to let qemu provide them, then both ovmf and seabios can grab them via fw_cfg. Option two is to use coreboot underneath I don't think one should exclude the other, I think it would make great sense to combine them. So have coreboot on QEMU read some hardware description from QEMU and use that either as input to a table generator, or even have the read data be the tables themselves. It might or might not be easier and/or make more sense to generate tables in coreboot rather than in QEMU - that's unclear so far. From the quick look it seems they do *not* generate the dsdt dynamically, only the other tables (simliar to seabios). So switching to coreboot probably doesn't help to remove the dsdt patching code we have in seabios. Is there something inherent to the AML generator code in coreboot which makes it suck for the purpose of also generating a DSDT? //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] RFC: Primary VGA
On Wed, Feb 27, 2013 at 02:16:23PM -0700, Alex Williamson wrote: When we start adding root ports and bridges to systems we need some concept of a primary VGA device.The differentiation of the primary device is that it's the default one that responds to the Legacy VGA address ranges. PCs often have a BIOS selection for this. Seabios already seems to have some concept of this and looks for a VGA class device for which the parent devices all have VGA routing enabled. This seems to work today if QEMU initializes VGA routing for the path it considers the primary. The first question is whether this bridge path pre-configuration is what we want to keep as the way QEMU communicates the primary VGA device to Seabios? Obviously we could switch to some kind of fwcfg interface, but I tend to think what we have is sufficient. If it is sufficient, then I think we need to rebuild that path on system reset and we need some way to specify which device to use. One option would be some kind of per PCIDevice property, perhaps primary_vga. A downside is that users can abuse it by trying to set it for more than one device. Maybe a better approach would be to add a machine property for it, -machine primary_vga=$id. Yes. And a command to change it when we support hotplug in the future? We'll also need some reasonable way to pick a default if unspecified. Does anyone have any thoughts on managing this? Thanks, Alex ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
