SeaBIOS

seabios@seabios.org

5 participants
3802 discussions

[PATCH] hw/usb-xhci.c: Code refactoring to not override initializers in `speed_from_xhci[16]`
by Paul Menzel 26 Oct '13

26 Oct '13

Date: Thu, 3 Oct 2013 11:55:48 +0200 Using Debian clang version 3.4-1 (trunk) (based on LLVM 3.4) to build SeaBIOS, the switch `-Winitializer-overrides` results in the following warnings. $ CC=clang make […] Compile checking out/src/hw/usb-xhci.o clang: warning: argument unused during compilation: '-mpreferred-stack-boundary=2' clang: warning: argument unused during compilation: '-minline-all-stringops' clang: warning: argument unused during compilation: '-fno-delete-null-pointer-checks' src/hw/usb-xhci.c:281:13: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides] [ 1 ] = USB_FULLSPEED, ^~~~~~~~~~~~~ src/hw/usb.h:68:24: note: expanded from macro 'USB_FULLSPEED' ^ src/hw/usb-xhci.c:280:20: note: previous initialization is here [ 0 ... 15 ] = -1, ^~ src/hw/usb-xhci.c:282:13: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides] [ 2 ] = USB_LOWSPEED, ^~~~~~~~~~~~ src/hw/usb.h:69:24: note: expanded from macro 'USB_LOWSPEED' ^ src/hw/usb-xhci.c:280:20: note: previous initialization is here [ 0 ... 15 ] = -1, ^~ src/hw/usb-xhci.c:283:13: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides] [ 3 ] = USB_HIGHSPEED, ^~~~~~~~~~~~~ src/hw/usb.h:70:24: note: expanded from macro 'USB_HIGHSPEED' ^ src/hw/usb-xhci.c:280:20: note: previous initialization is here [ 0 ... 15 ] = -1, ^~ src/hw/usb-xhci.c:284:13: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides] [ 4 ] = USB_SUPERSPEED, ^~~~~~~~~~~~~~ src/hw/usb.h:71:24: note: expanded from macro 'USB_SUPERSPEED' ^ src/hw/usb-xhci.c:280:20: note: previous initialization is here [ 0 ... 15 ] = -1, ^~ Refactor the code a little to get rid of the warnings. Signed-off-by: Paul Menzel <paulepanter(a)users.sourceforge.net> --- src/hw/usb-xhci.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/hw/usb-xhci.c b/src/hw/usb-xhci.c index 83eddc9..66ce3c4 100644 --- a/src/hw/usb-xhci.c +++ b/src/hw/usb-xhci.c @@ -277,11 +277,12 @@ static const char *speed_name[16] = { }; static const int speed_from_xhci[16] = { - [ 0 ... 15 ] = -1, + [ 0 ] = -1, [ 1 ] = USB_FULLSPEED, [ 2 ] = USB_LOWSPEED, [ 3 ] = USB_HIGHSPEED, [ 4 ] = USB_SUPERSPEED, + [ 5 ... 15 ] = -1, }; static const int speed_to_xhci[] = { -- 1.8.4.rc3

2 1

[PATCH] ACPI DSDT: Make control method `IQCR` serialized
by Paul Menzel 26 Oct '13

26 Oct '13

Date: Thu, 3 Oct 2013 11:30:52 +0200 The ASL Optimizing Compiler version 20130823-32 [Sep 11 2013] issues the following warning. $ make […] Compiling IASL out/src/fw/acpi-dsdt.hex out/src/fw/acpi-dsdt.dsl.i 360: Method(IQCR, 1, NotSerialized) { Remark 2120 - ^ Control Method should be made Serialized (due to creation of named objects within) […] ASL Input: out/src/fw/acpi-dsdt.dsl.i - 475 lines, 19181 bytes, 316 keywords AML Output: out/src/fw/acpi-dsdt.aml - 4407 bytes, 159 named objects, 157 executable opcodes Listing File: out/src/fw/acpi-dsdt.lst - 143715 bytes Hex Dump: out/src/fw/acpi-dsdt.hex - 41661 bytes Compilation complete. 0 Errors, 0 Warnings, 1 Remarks, 246 Optimizations […] After changing the parameter from `NotSerialized` to `Serialized`, the remark is indeed gone and there is no size change. The remark was added in ACPICA version 20130517 [1] and gives the following explanation. If a thread blocks within the method for any reason, and another thread enters the method, the method will fail because an attempt will be made to create the same (named) object twice. In this case, issue a remark that the method should be marked serialized. ACPICA BZ 909. [1] https://github.com/acpica/acpica/commit/ba84d0fc18ba910a47a3f71c68a43543c06… Signed-off-by: Paul Menzel <paulepanter(a)users.sourceforge.net> --- src/fw/acpi-dsdt.dsl | 2 +- src/fw/q35-acpi-dsdt.dsl | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/fw/acpi-dsdt.dsl b/src/fw/acpi-dsdt.dsl index 158f6b4..56243c3 100644 --- a/src/fw/acpi-dsdt.dsl +++ b/src/fw/acpi-dsdt.dsl @@ -235,7 +235,7 @@ DefinitionBlock ( } Return (0x0B) } - Method(IQCR, 1, NotSerialized) { + Method(IQCR, 1, Serialized) { // _CRS method - get current settings Name(PRR0, ResourceTemplate() { Interrupt(, Level, ActiveHigh, Shared) { 0 } diff --git a/src/fw/q35-acpi-dsdt.dsl b/src/fw/q35-acpi-dsdt.dsl index c031d83..5dec541 100644 --- a/src/fw/q35-acpi-dsdt.dsl +++ b/src/fw/q35-acpi-dsdt.dsl @@ -331,7 +331,7 @@ DefinitionBlock ( } Return (0x0B) } - Method(IQCR, 1, NotSerialized) { + Method(IQCR, 1, Serialized) { // _CRS method - get current settings Name(PRR0, ResourceTemplate() { Interrupt(, Level, ActiveHigh, Shared) { 0 } -- 1.8.4.rc3

2 1

Re: [SeaBIOS] Booting from SeaBIOS as payload to Coreboot to GRUB2
by Kevin O'Connor 26 Oct '13

26 Oct '13

On Mon, Oct 21, 2013 at 02:21:25PM +0000, Stojsavljevic, Zoran wrote: > Hello Kevin, > > I did what you have suggested to me. Here is what I have done in Coreboot (disabled all Option ROM except VGA one): > [*] Run VGA Option ROMs > [ ] Run non-VGA Option ROMs > [ ] Run Option ROMs on PCI devices > [ ]Option ROM execution type (Native mode) ---> > [ ] Enable PCIe Common Clock > [ ] Enable PCIe ASPM > > And in SeaBIOS: > > HW features option: > [ ] Hardware init during option ROM execution > > BIOS interfaces > [*] Option ROMS > > If I disable Option ROM VGA in Coreboot , my GRUB VGA screen does not come up. If I disable Option ROMS in SeaBIOS, my KBD starts making problems with well known messages: All Option ROMs should be disabled in Coreboot. If SeaBIOS can't initialize your vga rom, it should be fixed. (As a guess, either something is incorrect with the hardware, or there is a "vgahook" override in coreboot that isn't in seabios.) I can't say this is the root of your issue, but double initializing an option rom is definitely not correct and has been known to cause problems in the past. The fact that you can boot using grub1 would make this less likely to be the root cause. -Kevin

1 0

[RFC PATCH] Add _PXM to CPU objects for NUMA hot-plug
by Vasilis Liaskovitis 25 Oct '13

25 Oct '13

This patch adds a _PXM object to seabios CPU objects. The _PXM value is derived from CPU SRAT entries, so build_ssdt needs to be called after build_srat for this to work. The motivation for this patch is a CPU hot-unplug/hot-plug bug observed when using seabios and a 3.11 linux guest kernel on a multi-NUMA node qemu/kvm VM. The linux guest kernel parses the SRAT CPU entries at boot time and stores them in the array __apicid_to_node. When a CPU is hot-removed, the linux guest kernel resets the removed CPU's __apicid_to_node entry to NO_NUMA_NODE (kernel commit c4c60524). When the removed cpu is hot-added again, the linux kernel looks up the hot-added cpu object's _PXM value instead of somehow re-using the SRAT entry info (acpi_map_cpu2node calls acpi_get_node which calls acpi_get_pxm). If the _PXM value is not found, the CPU is assumed to be on node 0, and it is hot-plugged in the wrong NUMA node. Which is the preferred OSPM way of looking up a CPU's proximity info at hotplug time? Is it the CPU object's _PXM value, or the already-parsed CPU SRAT entry? Or maybe both ways are valid? This issue may require a kernel fix alternatively or additionally to the seabios fix: The kernel can save the originally parsed SRAT entry info somewhere before it resets it at hot-remove time, and use that info on hot-plug time if the _PXM value is missing for the hot-plugged CPU BIOS object. This way CPU hot-plug works well against a BIOS with no CPU _PXM info. Any comments / thoughts are welcome. --- src/fw/acpi.c | 8 +++++++- src/fw/ssdt-proc.dsl | 2 ++ 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/src/fw/acpi.c b/src/fw/acpi.c index 8de24c9..85c04fd 100644 --- a/src/fw/acpi.c +++ b/src/fw/acpi.c @@ -23,6 +23,7 @@ #include "src/fw/acpi-dsdt.hex" u32 acpi_pm1a_cnt VARFSEG; +struct srat_processor_affinity *cpu; static void build_header(struct acpi_table_header *h, u32 sig, int len, u8 rev) @@ -244,6 +245,7 @@ encodeLen(u8 *ssdt_ptr, int length, int bytes) #define PROC_OFFSET_CPUHEX (*ssdt_proc_name - *ssdt_proc_start + 2) #define PROC_OFFSET_CPUID1 (*ssdt_proc_name - *ssdt_proc_start + 4) #define PROC_OFFSET_CPUID2 (*ssdt_proc_id - *ssdt_proc_start) +#define PROC_OFFSET_CPUPXM (*ssdt_proc_pxm - *ssdt_proc_start) #define PROC_SIZEOF (*ssdt_proc_end - *ssdt_proc_start) #define PROC_AML (ssdp_proc_aml + *ssdt_proc_start) @@ -372,6 +374,7 @@ build_ssdt(void) *(ssdt_ptr++) = '_'; // build Processor object for each processor + struct srat_processor_affinity *core = cpu; int i; for (i=0; i<acpi_cpus; i++) { memcpy(ssdt_ptr, PROC_AML, PROC_SIZEOF); @@ -379,7 +382,9 @@ build_ssdt(void) ssdt_ptr[PROC_OFFSET_CPUHEX+1] = getHex(i); ssdt_ptr[PROC_OFFSET_CPUID1] = i; ssdt_ptr[PROC_OFFSET_CPUID2] = i; + ssdt_ptr[PROC_OFFSET_CPUPXM] = core->proximity_lo; ssdt_ptr += PROC_SIZEOF; + core++; } // build "Method(NTFY, 2) {If (LEqual(Arg0, 0x00)) {Notify(CP00, Arg1)} ...}" @@ -497,6 +502,7 @@ build_srat(void) int i; u64 curnode; + cpu = core; for (i = 0; i < max_cpu; ++i) { core->type = SRAT_PROCESSOR; core->length = sizeof(*core); @@ -620,10 +626,10 @@ acpi_setup(void) struct fadt_descriptor_rev1 *fadt = build_fadt(pci); ACPI_INIT_TABLE(fadt); - ACPI_INIT_TABLE(build_ssdt()); ACPI_INIT_TABLE(build_madt()); ACPI_INIT_TABLE(build_hpet()); ACPI_INIT_TABLE(build_srat()); + ACPI_INIT_TABLE(build_ssdt()); if (pci->device == PCI_DEVICE_ID_INTEL_ICH9_LPC) ACPI_INIT_TABLE(build_mcfg_q35()); diff --git a/src/fw/ssdt-proc.dsl b/src/fw/ssdt-proc.dsl index 407d61e..373cdd7 100644 --- a/src/fw/ssdt-proc.dsl +++ b/src/fw/ssdt-proc.dsl @@ -32,6 +32,8 @@ DefinitionBlock ("ssdt-proc.aml", "SSDT", 0x01, "BXPC", "BXSSDT", 0x1) * also updating the C code. */ Name(_HID, "ACPI0007") + ACPI_EXTRACT_NAME_BYTE_CONST ssdt_proc_pxm + Name(_PXM, 0xBB) External(CPMA, MethodObj) External(CPST, MethodObj) External(CPEJ, MethodObj) -- 1.7.10.4

1 0

[PATCH] vgahooks: add SM720 VGA BIOS hooks for WIN Enterprises MB-60470
by Jonathan A. Kollasch 20 Oct '13

20 Oct '13

Signed-off-by: Jonathan A. Kollasch <jakllsch(a)kollasch.net> --- src/system.c | 1 + src/util.h | 1 + src/vgahooks.c | 66 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++- 3 files changed, 67 insertions(+), 1 deletion(-) diff --git a/src/system.c b/src/system.c index 3daf49b..5d10cc8 100644 --- a/src/system.c +++ b/src/system.c @@ -349,6 +349,7 @@ handle_15(struct bregs *regs) case 0x52: handle_1552(regs); break; case 0x53: handle_1553(regs); break; case 0x5f: handle_155f(regs); break; + case 0x7f: handle_157f(regs); break; case 0x83: handle_1583(regs); break; case 0x86: handle_1586(regs); break; case 0x87: handle_1587(regs); break; diff --git a/src/util.h b/src/util.h index d51e30f..c9d463d 100644 --- a/src/util.h +++ b/src/util.h @@ -218,6 +218,7 @@ void lpt_setup(void); // vgahooks.c void handle_155f(struct bregs *regs); +void handle_157f(struct bregs *regs); void vgahook_setup(struct pci_device *pci); diff --git a/src/vgahooks.c b/src/vgahooks.c index dc3085e..6a4acfe 100644 --- a/src/vgahooks.c +++ b/src/vgahooks.c @@ -12,10 +12,11 @@ #include "hw/pci_regs.h" // PCI_VENDOR_ID #include "output.h" // dprintf #include "string.h" // strcmp -#include "util.h" // handle_155f +#include "util.h" // handle_155f, handle_157f #define VH_VIA 1 #define VH_INTEL 2 +#define VH_SMI 3 int VGAHookHandlerType VARFSEG; @@ -25,6 +26,11 @@ handle_155fXX(struct bregs *regs) set_code_unimplemented(regs, RET_EUNSUPPORTED); } +static void +handle_157fXX(struct bregs *regs) +{ + set_code_unimplemented(regs, RET_EUNSUPPORTED); +} /**************************************************************** * Via hooks @@ -248,6 +254,46 @@ getac_setup(struct pci_device *pci) { } +/**************************************************************** + * Silicon Motion hooks + ****************************************************************/ + +u8 SmiBootDisplay VARFSEG; // 1: LCD, 2: CRT, 3: Both */ + +static void +smi_157f02(struct bregs *regs) +{ + /* Boot Display Device Override */ + regs->ax = 0x007f; + regs->bl = GET_GLOBAL(SmiBootDisplay); + set_success(regs); +} + +static void +smi_157f14(struct bregs *regs) +{ + /* ReduceOn support default status */ + regs->ax = 0x007f; + regs->bl = 0x00; + set_success(regs); +} + +static void +smi_157f(struct bregs *regs) +{ + switch (regs->al) { + case 0x02: smi_157f02(regs); break; + case 0x14: smi_157f14(regs); break; + default: handle_157fXX(regs); break; + } +} + +static void +winent_mb6047_setup(struct pci_device *pci) +{ + VGAHookHandlerType = VH_SMI; + SmiBootDisplay = 0x02; +} /**************************************************************** * Entry and setup @@ -270,6 +316,22 @@ handle_155f(struct bregs *regs) } } +// Main 16bit entry point +void +handle_157f(struct bregs *regs) +{ + if (!CONFIG_VGAHOOKS) { + handle_157fXX(regs); + return; + } + + int htype = GET_GLOBAL(VGAHookHandlerType); + switch (htype) { + case VH_SMI: smi_157f(regs); break; + default: handle_157fXX(regs); break; + } +} + // Setup void vgahook_setup(struct pci_device *pci) @@ -283,6 +345,8 @@ vgahook_setup(struct pci_device *pci) getac_setup(pci); else if (strcmp(CBvendor, "RODA") == 0 && strcmp(CBpart, "RK886EX") == 0) roda_setup(pci); + else if (strcmp(CBvendor, "Win Enterprise") == 0 && strcmp(CBpart, "MB6047") == 0) + winent_mb6047_setup(pci); else if (pci->vendor == PCI_VENDOR_ID_VIA) via_setup(pci); else if (pci->vendor == PCI_VENDOR_ID_INTEL) -- 1.8.0.1

2 3

Re: [SeaBIOS] Booting from SeaBIOS as payload to Coreboot to GRUB2
by Kevin O'Connor 20 Oct '13

20 Oct '13

On Thu, Oct 17, 2013 at 03:54:55PM +0000, Stojsavljevic, Zoran wrote: > Hello to SeaBIOS community, > > I have problem to boot from SeaBIOS to GRUB2. Do not know why these problems happened, so I am attaching .log file for your inspection. > > The sequence of events is: IVB FSP -> Coreboot -> SeaBIOS -> GRUB2 -> Kernel 3.x.y > > I also got the info that maybe I need to change some settings on the Southbridge for my INTEL IVB. There's a bunch of registers in the Southbridge that coreboot can configure how the IDE/SATA buses are exposed. Thing is, the Southbridge driver has to support it. > > Any thoughts/ideas/suggestions? It looks like you have both coreboot and seabios configured to run option roms. This has been known to cause problems in the past - I'd disable that. Other than that, I don't see anything in the log that indicates a clear root cause. Did this machine boot under any circumstances for you? -Kevin

1 0

Booting from SeaBIOS as payload to Coreboot to GRUB2
by Stojsavljevic, Zoran 17 Oct '13

17 Oct '13

Hello to SeaBIOS community, I have problem to boot from SeaBIOS to GRUB2. Do not know why these problems happened, so I am attaching .log file for your inspection. The sequence of events is: IVB FSP -> Coreboot -> SeaBIOS -> GRUB2 -> Kernel 3.x.y I also got the info that maybe I need to change some settings on the Southbridge for my INTEL IVB. There's a bunch of registers in the Southbridge that coreboot can configure how the IDE/SATA buses are exposed. Thing is, the Southbridge driver has to support it. Any thoughts/ideas/suggestions? Thank you, Zoran _______ Most of The Time you should be "intel inside" to be capable to think "out of the box". Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052

1 0

[PATCH v2] map 64-bit PCI BARs at location provided by emulator
by Igor Mammedov 15 Oct '13

15 Oct '13

Currently 64-bit PCI BARs are unconditionally mapped by BIOS right over 4G + RamSizeOver4G location, which doesn't allow to reserve extra space before 64-bit PCI window. For memory hotplug an extra RAM space might be reserved after present 64-bit RAM end and BIOS should map 64-bit PCI BARs after it. Introduce "etc/pcimem64-start" romfile to provide BIOS a hint where it should start mapping of 64-bit PCI BARs. If romfile is missing, BIOS reverts to legacy behavior and starts mapping right after high memory. Signed-off-by: Igor Mammedov <imammedo(a)redhat.com> --- v2: * place 64-bit window behind high RAM end if "etc/pcimem64-start" points below it. --- src/fw/pciinit.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c index b29db99..798309b 100644 --- a/src/fw/pciinit.c +++ b/src/fw/pciinit.c @@ -18,6 +18,8 @@ #include "paravirt.h" // RamSize #include "string.h" // memset #include "util.h" // pci_setup +#include "byteorder.h" // le64_to_cpu +#include "romfile.h" // romfile_loadint #define PCI_DEVICE_MEM_MIN 0x1000 #define PCI_BRIDGE_IO_MIN 0x1000 @@ -764,6 +766,15 @@ static void pci_bios_map_devices(struct pci_bus *busses) { if (pci_bios_init_root_regions(busses)) { struct pci_region r64_mem, r64_pref; + u64 ram64_end = 0x100000000ULL + RamSizeOver4G; + u64 base64 = le64_to_cpu(romfile_loadint("etc/pcimem64-start", + ram64_end)); + if (base64 < ram64_end) { + dprintf(1, "ignorig etc/pcimem64-start [0x%llx] below present RAM, " + "placing 64-bit PCI window behind RAM end: %llx", + base64, ram64_end); + base64 = ram64_end; + } r64_mem.list.first = NULL; r64_pref.list.first = NULL; pci_region_migrate_64bit_entries(&busses[0].r[PCI_REGION_TYPE_MEM], @@ -779,7 +790,7 @@ static void pci_bios_map_devices(struct pci_bus *busses) u64 align_mem = pci_region_align(&r64_mem); u64 align_pref = pci_region_align(&r64_pref); - r64_mem.base = ALIGN(0x100000000LL + RamSizeOver4G, align_mem); + r64_mem.base = ALIGN(base64, align_mem); r64_pref.base = ALIGN(r64_mem.base + sum_mem, align_pref); pcimem64_start = r64_mem.base; pcimem64_end = r64_pref.base + sum_pref; -- 1.8.3.1

4 29

[PATCH] map 64-bit PCI BARs at location provided by emulator
by Igor Mammedov 15 Oct '13

15 Oct '13

Currently 64-bit PCI BARs are unconditionally mapped by BIOS right over 4G + RamSizeOver4G location, which doesn't allow to reserve extra space before 64-bit PCI window. For memory hotplug an extra RAM space might be reserved after present 64-bit RAM end and BIOS should map 64-bit PCI BARs after it. Introduce "etc/pcimem64-minimum-addres" romfile to provide BIOS a hint where it should start mapping of 64-bit PCI BARs. If romfile is missing BIOS reverts to legacy behavior and starts mapping right after high memory. Signed-off-by: Igor Mammedov <imammedo(a)redhat.com> v3: * rename "etc/pcimem64-start" to "etc/pcimem64-minimum-addres" v2: * place 64-bit window behind high RAM end if "etc/pcimem64-start" points below it. --- src/fw/pciinit.c | 13 ++++++++++++- 1 files changed, 12 insertions(+), 1 deletions(-) diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c index b29db99..64a37c3 100644 --- a/src/fw/pciinit.c +++ b/src/fw/pciinit.c @@ -18,6 +18,8 @@ #include "paravirt.h" // RamSize #include "string.h" // memset #include "util.h" // pci_setup +#include "byteorder.h" // le64_to_cpu +#include "romfile.h" // romfile_loadint #define PCI_DEVICE_MEM_MIN 0x1000 #define PCI_BRIDGE_IO_MIN 0x1000 @@ -764,6 +766,15 @@ static void pci_bios_map_devices(struct pci_bus *busses) { if (pci_bios_init_root_regions(busses)) { struct pci_region r64_mem, r64_pref; + u64 ram64_end = 0x100000000ULL + RamSizeOver4G; + u64 base64 = le64_to_cpu(romfile_loadint("etc/pcimem64-minimum-address", + ram64_end)); + if (base64 < ram64_end) { + dprintf(1, "ignorig etc/pcimem64-minimum-address [0x%llx] below " + "present RAM, placing 64-bit PCI window behind RAM end: " + "0x%llx", base64, ram64_end); + base64 = ram64_end; + } r64_mem.list.first = NULL; r64_pref.list.first = NULL; pci_region_migrate_64bit_entries(&busses[0].r[PCI_REGION_TYPE_MEM], @@ -779,7 +790,7 @@ static void pci_bios_map_devices(struct pci_bus *busses) u64 align_mem = pci_region_align(&r64_mem); u64 align_pref = pci_region_align(&r64_pref); - r64_mem.base = ALIGN(0x100000000LL + RamSizeOver4G, align_mem); + r64_mem.base = ALIGN(base64, align_mem); r64_pref.base = ALIGN(r64_mem.base + sum_mem, align_pref); pcimem64_start = r64_mem.base; pcimem64_end = r64_pref.base + sum_pref; -- 1.7.1

1 0

QEMU detect and PCI Configuration Space
by SeaBIOS 15 Oct '13

15 Oct '13

Dear all, I am reading the source code of SeaBIOS. In QEMU detection part (qemu_detect()), I notice the method to detect QEMU is the same as detect other PCI devices through PCI Configuration Space (I/O port: 0xcf8 and 0xcfc). Does QEMU emulate the PCI Configuration Space? Any help or comments will be appreciated. Thank you Best, Min Li

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS