SeaBIOS August 2012

seabios@seabios.org

28 participants
80 discussions

by Avi Kivity

ipxe contains the following snippet: /* Copy ROM to image source PMM block */ pushw %es xorw %ax, %ax movw %ax, %es movl %esi, %edi xorl %esi, %esi movzbl romheader_size, %ecx shll $9, %ecx addr32 rep movsb /* PMM presence implies flat real mode */ Which copies an image to %edi, with %edi >= 0x10000. This is in accordance with the PMM spec: "3.2.4 Accessing Extended Memory This section specifies how clients should access extended memory blocks allocated by the PMM. When control is passed to an option ROM from a BIOS that supports PMM, the processor will be in big real mode, and Gate A20 will be disabled (segment wrap turned off). This allows access to extended memory blocks using real mode addressing. In big real mode, access to memory above 1MB can be accomplished by using a 32-bit extended index register (EDI, etc.) and setting the segment register to 0000h. The following code example assumes that the pmmAllocate function was just called to allocate a block of extended memory, and DX:AX returned the 32-bit buffer address. ; Assume here that DX:AX contains the 32-bit address of our allocated buffer. ; Clear the DS segment register. push 0000h pop ds ; Put the DX:AX 32-bit buffer address into EDI. mov di, dx ; Get the upper word. shl edi, 16 ; Shift it to upper EDI. mov di, ax ; Get the lower word. ; Example: clear the first four bytes of the extended memory buffer. mov [edi], 00000000h ; DS:EDI is used as the memory pointer. In a similar way, the other segment registers and 32-bit index registers can be used for extended memory accessing." So far so good. But the Intel SDM says (20.1.1): "The IA-32 processors beginning with the Intel386 processor can generate 32-bit offsets using an address override prefix; however, in real-address mode, the value of a 32-bit offset may not exceed FFFFH without causing an exception. For full compatibility with Intel 286 real-address mode, pseudo-protection faults (interrupt 12 or 13) occur if a 32-bit offset is generated outside the range 0 through FFFFH." Which is exactly what happens here. My understanding of big real mode is that to achieve a segment limit != 0xffff, you must go into 32-bit protected mode, load a segment with a larger limit, and return into real mode without touching the segment. The next load of the segment will reset the limit to 0xffff. Due to bugs in both qemu tcg and kvm, limit checks are not enforced in real mode, but once this bugs are fixed, the code above will break. The PMM spec also has this to say (1.3): "Big Real Mode Big Real Mode is a modified version of the processor’s real mode with the segment limits changed from 1MB to 4GB. Big real mode allows the BIOS or an Option ROM to read and write extended memory without the overhead of protected mode. The BIOS puts the processor in big real mode during POST to allow simplified access to extended memory. The processor will be in big real mode while the PMM Services are callable." This is more in line with the Intel spec, and means that the modification to %es must be avoided (and that seabios needs changes to either work in big real mode, or to put the processor back into big real mode after returning from a PMM service. The whole thing is very unfortunate, as kvm is very slow while in big real mode, on certain processors. -- error compiling committee.c: too many arguments to function

9 years, 10 months

Re: [SeaBIOS] WinXP 32 installation failure with new SeaBIOS in QEMU

by Avi Kivity

On 08/19/2012 12:27 PM, Avi Kivity wrote: > On 08/17/2012 08:53 AM, Gerd Hoffmann wrote: >> Hi, >> >>> It might be instruction emulator bug in KVM. >>> Attached is the trace. >> >> qemu-2047 [000] d..2 261.999076: kvm_entry: vcpu 0 >> qemu-2047 [000] ...1 261.999077: kvm_emulate_insn: >> f0000:6201:fb (real) >> qemu-2047 [000] d..2 261.999078: kvm_entry: vcpu 0 >> ##### CPU 3 buffer started #### >> qemu-2047 [003] ...1 411.367592: kvm_emulate_insn: >> 20000:26c:cb (prot16) >> qemu-2047 [003] ...1 411.367593: kvm_inj_exception: #GP >> (0x844) >> qemu-2047 [003] d..2 411.367594: kvm_entry: vcpu 0 >> >> This looks suspious. vcpu migration issue? Or just something missing >> in the trace? >> > > Looks like tracing with a too-small buffer size. I generally trace using > > trace-cmd record -e kvm -b 100000 > > and with fingers crossed. > > The RET FAR instruction failure (which trace-cmd report decodes) is > probably not the original failure. In fact it is, we mis-emulated stack operations when SS.B=0 but the address size was 32-bits, and there are bits set in the top 16 bits of ESP. Why ESP has bits set in the top 16 bits is another question. Is seabios polluting those bits? -- error compiling committee.c: too many arguments to function

9 years, 10 months

The cbfs header for a payloads dest addr is a u64, use ntohll instead of ntohl

by Dave Frodin

All, I found an issue with seabios when it is attempting to download and execute a payload that has been added to a coreboot rom image img/ directory. The cbfs header has a destination address of "u64 load_addr". The code that reads the destination address out of the header is using ntohl which only works on u32, so the address that the cbfstool puts in the header, 0x00000000000100000 gets converted to 0x00000000. I couldn't find where there was 64 bit version of the ntohl ftn/macro so I copied one out of coreboot. Feel free to change where/how the ntohll gets implemented. Thanks, Dave Frodin P.S. Thanks to whomever came up with the img/payload method of adding payloads. It's slick. diff --git a/src/coreboot.c b/src/coreboot.c index e116a14..4efec9c 100644 --- a/src/coreboot.c +++ b/src/coreboot.c @@ -470,6 +470,17 @@ struct cbfs_payload { struct cbfs_payload_segment segments[1]; }; +#define ntohll(x) \ + ((u64)( \ + (((u64)(x) & (u64)0x00000000000000ffULL) << 56) | \ + (((u64)(x) & (u64)0x000000000000ff00ULL) << 40) | \ + (((u64)(x) & (u64)0x0000000000ff0000ULL) << 24) | \ + (((u64)(x) & (u64)0x00000000ff000000ULL) << 8) | \ + (((u64)(x) & (u64)0x000000ff00000000ULL) >> 8) | \ + (((u64)(x) & (u64)0x0000ff0000000000ULL) >> 24) | \ + (((u64)(x) & (u64)0x00ff000000000000ULL) >> 40) | \ + (((u64)(x) & (u64)0xff00000000000000ULL) >> 56) )) + void cbfs_run_payload(struct cbfs_file *file) { @@ -480,7 +491,7 @@ cbfs_run_payload(struct cbfs_file *file) struct cbfs_payload_segment *seg = pay->segments; for (;;) { void *src = (void*)pay + ntohl(seg->offset); - void *dest = (void*)ntohl((u32)seg->load_addr); + void *dest = (void*)ntohll((u64)seg->load_addr); u32 src_len = ntohl(seg->len); u32 dest_len = ntohl(seg->mem_len); switch (seg->type) {

9 years, 10 months

[PULL 0/1] update qemu seabios / seabios release?

by Gerd Hoffmann

Hi, This pull updates seabios in qemu to the latest bits from seabios master, so the upcoming 1.2 qemu release gets all the new shiny stuff added recently. I'd like to have a new seabios release for inclusion into qemu 1.2 which is planned for September 1st. So how about this plan: - merge seabios snapshot now (this pull req), so it gets testing in the qemu testing & release candidates phase - put seabios into bugfixing freeze too (now or in a few days), fix any issues poping up in testing. - roll out seabios release by end of august, so it can be included into qemu 1.2 Anthony? Kevin? Fine are you ok with this? qemu release schedule is here: http://wiki.qemu.org/Planning/1.2 cheers, Gerd Gerd Hoffmann (1): update seabios to latest master pc-bios/bios.bin | Bin 131072 -> 131072 bytes roms/seabios | 2 +- 2 files changed, 1 insertions(+), 1 deletions(-) The following changes since commit 0b8db8fe15d17a529a5ea90614c11e9f031dfee8: slirp: fix build on mingw32 (2012-08-06 19:31:55 -0500) are available in the git repository at: git://git.kraxel.org/qemu seabios-5a02306 Gerd Hoffmann (1): update seabios to latest master pc-bios/bios.bin | Bin 131072 -> 131072 bytes roms/seabios | 2 +- 2 files changed, 1 insertions(+), 1 deletions(-)

9 years, 10 months

[PATCH v2 0/2] Add IPMI SMBIOS/ACPI support

by minyard＠acm.org

I went ahead and kept the structure passing because I've added ACPI support. After thinking about it a while, I think if you have to pass anything to SMBIOS (like "IPMI is present") you might as well pass the whole structure, and making things fixed in the BIOS that can change in the hardware doesn't seem like a good idea. Note that the acpi-element code might make building the SSDT table a little cleaner, if that is interesting.

9 years, 10 months

[PATCH] add acpi pmtimer support

by Gerd Hoffmann

This patch makes seabios use the acpi pmtimer instead of tsc for timekeeping. The pmtimer has a fixed frequency and doesn't need calibration, thus it doesn't suffer from calibration errors due to a loaded host machine. Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> --- src/clock.c | 29 +++++++++++++++++++++++++++++ src/pciinit.c | 5 +++++ src/util.h | 1 + 3 files changed, 35 insertions(+), 0 deletions(-) diff --git a/src/clock.c b/src/clock.c index 69e9f17..59f269b 100644 --- a/src/clock.c +++ b/src/clock.c @@ -129,11 +129,40 @@ emulate_tsc(void) return ret; } +u16 pmtimer_ioport VAR16VISIBLE; +u32 pmtimer_wraps VARLOW; +u32 pmtimer_last VARLOW; + +void pmtimer_init(u16 ioport, u32 khz) +{ + dprintf(1, "Using pmtimer, ioport 0x%x, freq %d kHz\n", ioport, khz); + SET_GLOBAL(pmtimer_ioport, ioport); + SET_GLOBAL(cpu_khz, khz); +} + +static u64 pmtimer_get(void) +{ + u16 ioport = GET_GLOBAL(pmtimer_ioport); + u32 wraps = GET_LOW(pmtimer_wraps); + u32 pmtimer = inl(ioport); + + if (pmtimer < GET_LOW(pmtimer_last)) { + wraps++; + SET_LOW(pmtimer_wraps, wraps); + } + SET_LOW(pmtimer_last, pmtimer); + + dprintf(9, "pmtimer: %u:%u\n", wraps, pmtimer); + return (u64)wraps << 24 | pmtimer; +} + static u64 get_tsc(void) { if (unlikely(GET_GLOBAL(no_tsc))) return emulate_tsc(); + if (GET_GLOBAL(pmtimer_ioport)) + return pmtimer_get(); return rdtscll(); } diff --git a/src/pciinit.c b/src/pciinit.c index 68f302a..31115ee 100644 --- a/src/pciinit.c +++ b/src/pciinit.c @@ -180,6 +180,9 @@ static const struct pci_device_id pci_class_tbl[] = { PCI_DEVICE_END, }; +/* PM Timer ticks per second (HZ) */ +#define PM_TIMER_FREQUENCY 3579545 + /* PIIX4 Power Management device (for ACPI) */ static void piix4_pm_init(struct pci_device *pci, void *arg) { @@ -191,6 +194,8 @@ static void piix4_pm_init(struct pci_device *pci, void *arg) pci_config_writeb(bdf, 0x80, 0x01); /* enable PM io space */ pci_config_writel(bdf, 0x90, PORT_SMB_BASE | 1); pci_config_writeb(bdf, 0xd2, 0x09); /* enable SMBus io space */ + + pmtimer_init(PORT_ACPI_PM_BASE + 0x08, PM_TIMER_FREQUENCY / 1000); } static const struct pci_device_id pci_device_tbl[] = { diff --git a/src/util.h b/src/util.h index 89e928c..1603a57 100644 --- a/src/util.h +++ b/src/util.h @@ -312,6 +312,7 @@ void lpt_setup(void); // clock.c #define PIT_TICK_RATE 1193180 // Underlying HZ of PIT #define PIT_TICK_INTERVAL 65536 // Default interval for 18.2Hz timer +void pmtimer_init(u16 ioport, u32 khz); int check_tsc(u64 end); void timer_setup(void); void ndelay(u32 count); -- 1.7.1

9 years, 10 months

[PATCH] tsc: use kvmclock for calibration

by Gerd Hoffmann

Use kvmclock for tsc calibration when running on kvm. Without this the tsc frequency calibrated by seabios can be *way* off in case the virtual machine is booted on a loaded host. I've seen seabios calibrating 27 instead of ca. 2800 MHz, resulting in timeouts being to short by factor 100. Which in turn leads to disk I/O errors due to timeouts, especially as I/O requests tend to take a bit longer than usual on a loaded box ... Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> --- src/clock.c | 9 +++++ src/paravirt.c | 90 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ src/paravirt.h | 1 + 3 files changed, 100 insertions(+), 0 deletions(-) diff --git a/src/clock.c b/src/clock.c index 69e9f17..5883b1a 100644 --- a/src/clock.c +++ b/src/clock.c @@ -13,6 +13,7 @@ #include "bregs.h" // struct bregs #include "biosvar.h" // GET_GLOBAL #include "usb-hid.h" // usb_check_event +#include "paravirt.h" // kvm clock // RTC register flags #define RTC_A_UIP 0x80 @@ -80,6 +81,14 @@ calibrate_tsc(void) return; } + if (kvm_para_available()) { + u32 khz = kvm_tsc_khz(); + if (khz != 0) { + SET_GLOBAL(cpu_khz, khz); + return; + } + } + // Setup "timer2" u8 orig = inb(PORT_PS2_CTRLB); outb((orig & ~PPCB_SPKR) | PPCB_T2GATE, PORT_PS2_CTRLB); diff --git a/src/paravirt.c b/src/paravirt.c index 2a98d53..942ce11 100644 --- a/src/paravirt.c +++ b/src/paravirt.c @@ -12,6 +12,7 @@ #include "ioport.h" // outw #include "paravirt.h" // qemu_cfg_port_probe #include "smbios.h" // struct smbios_structure_header +#include "biosvar.h" // GET_GLOBAL int qemu_cfg_present; @@ -346,3 +347,92 @@ void qemu_cfg_romfile_setup(void) dprintf(3, "Found fw_cfg file: %s (size=%d)\n", file->name, file->size); } } + +#define KVM_CPUID_SIGNATURE 0x40000000 +#define KVM_CPUID_FEATURES 0x40000001 +#define KVM_FEATURE_CLOCKSOURCE 0 +#define KVM_FEATURE_CLOCKSOURCE2 3 +#define MSR_KVM_SYSTEM_TIME 0x12 +#define MSR_KVM_SYSTEM_TIME_NEW 0x4b564d01 + +struct pvclock_vcpu_time_info { + u32 version; + u32 pad0; + u64 tsc_timestamp; + u64 system_time; + u32 tsc_to_system_mul; + s8 tsc_shift; + u8 flags; + u8 pad[2]; +} PACKED; + +/* + * do_div() is NOT a C function. It wants to return + * two values (the quotient and the remainder), but + * since that doesn't work very well in C, what it + * does is: + * + * - modifies the 64-bit dividend _in_place_ + * - returns the 32-bit remainder + * + * This ends up being the most efficient "calling + * convention" on x86. + */ +#define do_div(n, base) \ + ({ \ + unsigned long __upper, __low, __high, __mod, __base; \ + __base = (base); \ + asm("" : "=a" (__low), "=d" (__high) : "A" (n)); \ + __upper = __high; \ + if (__high) { \ + __upper = __high % (__base); \ + __high = __high / (__base); \ + } \ + asm("divl %2" : "=a" (__low), "=d" (__mod) \ + : "rm" (__base), "0" (__low), "1" (__upper)); \ + asm("" : "=A" (n) : "a" (__low), "d" (__high)); \ + __mod; \ + }) + +static u64 pvclock_tsc_khz(struct pvclock_vcpu_time_info *src) +{ + u64 pv_tsc_khz = 1000000ULL << 32; + + do_div(pv_tsc_khz, src->tsc_to_system_mul); + if (src->tsc_shift < 0) + pv_tsc_khz <<= -src->tsc_shift; + else + pv_tsc_khz >>= src->tsc_shift; + return pv_tsc_khz; +} + +u64 kvm_tsc_khz(void) +{ + u32 eax, ebx, ecx, edx, msr; + struct pvclock_vcpu_time_info time; + u32 addr = (u32)(&time); + u64 khz; + + /* check presence and figure msr number */ + cpuid(KVM_CPUID_FEATURES, &eax, &ebx, &ecx, &edx); + if (eax & KVM_FEATURE_CLOCKSOURCE2) { + msr = MSR_KVM_SYSTEM_TIME_NEW; + } else if (eax & KVM_FEATURE_CLOCKSOURCE) { + msr = MSR_KVM_SYSTEM_TIME; + } else { + return 0; + } + + /* ask kvm hypervisor to fill struct */ + memset(&time, 0, sizeof(time)); + wrmsr(msr, addr | 1); + wrmsr(msr, 0); + if (time.version < 2 || time.tsc_to_system_mul == 0) + return 0; + + /* go figure tsc frequency */ + khz = pvclock_tsc_khz(&time); + dprintf(1, "Using kvmclock, msr 0x%x, tsc %d MHz\n", + msr, (u32)khz / 1000); + return khz; +} diff --git a/src/paravirt.h b/src/paravirt.h index a284c41..eedfcc3 100644 --- a/src/paravirt.h +++ b/src/paravirt.h @@ -27,6 +27,7 @@ static inline int kvm_para_available(void) return 0; } +extern u64 kvm_tsc_khz(void); #define QEMU_CFG_SIGNATURE 0x00 #define QEMU_CFG_ID 0x01 -- 1.7.1

9 years, 10 months

Re: [SeaBIOS] Compiling SeaBIOS for coreboot has problems with its ACPI code

by Michael S. Tsirkin

On Thu, Aug 09, 2012 at 02:59:45AM +0000, Moore, Robert wrote: > > > >-----Original Message----- > >From: Kevin O'Connor [mailto:kevin@koconnor.net] > >Sent: Wednesday, August 08, 2012 7:23 PM > >To: Moore, Robert > >Cc: Michael S. Tsirkin; Idwer Vollering; seabios(a)seabios.org; Tang, Feng; > >coreboot(a)coreboot.org > >Subject: Re: [SeaBIOS] Compiling SeaBIOS for coreboot has problems with its > >ACPI code > > > >On Tue, Aug 07, 2012 at 07:34:37PM +0000, Moore, Robert wrote: > >> This is very interesting. If I understand correctly, you are using a > >> utility plus various directives to generate tables of AML offsets -- > >> presumably in order to dynamically change AML values, correct? > > > >Yes - exactly. We started off completely generating the SSDT > >dynamically, but that got awkward when we needed to generate Processor > >objects dynamically. So, we compiled an SSDT as template and then > >patched it. It was fragile to hard-code the offsets, so a tool was > >written to parse the IASL output and generate the offsets > >automatically. > > > >I'm CC'ing the coreboot list - they have also been doing SSDT runtime > >generation. > > > >> I have to say that I have not seen anything like this, from any BIOS > >vendor. > >> > >> > By the way, is there interest in adding some of the functionality that > >> > we get by parsing the listing to iasl directly? > >> > >> We are always interested in adding features to make the compiler > >> more useful. What would you suggest? > > > >The tool currently generates offsets and can rename the Amlcode[] > >variable to something more unique. I'm sure additional features could > >be thought up. > > > >-Kevin > > > Here are additional thoughts and questions that I sent out earlier today: > > > > > >From what we have seen, standard BIOS code often modifies the AML on the fly (before the OS gets the ACPI tables) to handle the various setup options and other things. Some vendors do this better than others (we've seen checksum errors because of this, as well as package length issues because, for example, a byte constant is replaced by a dword constant but there is no room for the 32-bit value.) > > Obviously, the iASL compiler knows the offset of not only the start of every ASL statement, but also the start of every argument of every ASL statement. > > What we would be willing to provide is a new type of output file that provides arrays of offsets for you to use when modifying the AML. Something like this should be useful for your project, as well as standard BIOS code that needs this information as well. > > The -sc option for iASL already provides a limited version of this, but only at the statement level with offsets within a trailing comment field: > > /* > * 10....{ > * 11.... Method (MAIN, 0, NotSerialized) > */ > unsigned char DSDT_Template_MAIN [] = > { > 0x14,0x08,0x4D,0x41,0x49,0x4E,0x00, /* 00000023 "..MAIN." */ > > /* > * 12.... { > * 13.... Return (Zero) > */ > 0xA4,0x00, /* 00000025 ".." */ > > A new type of output file could instead create arrays of offsets, one offset per ASL term (statement or argument). The format could be something like one array per ASL statement or one array per method. You could then pick and choose which of these arrays you want to use/include into your BIOS code. > > Does this sound like it would solve your issues? > > Thanks, > Bob Hmm. How would C code know which of the statements it needs? For example, we could have many Return(Zero) statements but only want to patch some of them. Would it be possible to allow some tags in the AML code that specifies which offsets to extract, and how to name the arrays? It would also be useful to specify the array names for the AML code, to avoid dependencies between C code and makefiles. For example, code could look like this: /* Pull in required macros, also allows iasl to figure out it is not in compatibility mode. */ #include <acpi-extract.h> /* Put all code in this definition block in AmlCode array */ ACPI_EXTRACT_CODE(AmlCode) DefinitionBlock ("ssdt-pcihp.aml", "SSDT", 0x01, "BXPC", "BXSSDTPCIHP", 0x1) Name (_S4, /* Put offset of next argument in acpi_s4_pkg array */ ACPI_EXTRACT_OFFSET(acpi_s4_pkg) Package (0x04) { 0x2, /* PM1a_CNT.SLP_TYP */ 0x2, /* PM1b_CNT.SLP_TYP */ Zero, /* reserved */ Zero /* reserved */ }) One other thing to note about our scripts is that offsets are often small, our scripts make the array the correct type (char,short,int,long) to make it fit, to avoid wasting memory. You might want to do the same. -- MST

9 years, 10 months

Re: [SeaBIOS] SeaBIOS "latest updates" broken for few weeks

by Alec Ari

To: Alec Ari <neotheuser(a)ymail.com> Cc: "seabios(a)seabios.org" <seabios(a)seabios.org> Sent: Sunday, August 5, 2012 1:44 AM Subject: Re: [SeaBIOS] SeaBIOS "latest updates" broken for few weeks >I get the same error. Thanks for the feedback! -Alec

9 years, 10 months

Re: [SeaBIOS] How much RAM is required?

by Markus Armbruster

"Fred ." <eldmannen(a)gmail.com> writes: > On Fri, Aug 10, 2012 at 5:28 PM, Markus Armbruster <armbru(a)redhat.com> wrote: >> Frediano Ziglio <frediano.ziglio(a)citrix.com> writes: >> >>> On Fri, 2012-08-10 at 16:24 +0200, Peter Stuge wrote: >>>> Fred . wrote: >>>> > No, I am not. >>>> >>>> Ok, so there's only a hypothesis. >>>> >>>> >>>> > But I believe QEMU does have the functionality to load an arbitrary >>>> > firmware. So the firmware doesn't necessarily have to be SeaBIOS. >>>> >>>> As you may know the 8086 reset vector is at 1MB-16 so it will be >>>> really difficult to run a PC-like machine with less than 1MB of >>>> memory. I don't believe one has ever existed. >>>> >>> >>> I remember that my manual of the NEC V20 (a 8086 clone with 10 MHZ!) has >>> settings for 256KB of RAM (jumpers of course!) >>> >>> The ROM was "mapped" (physically!) at f0000 with extended ROM at e0000. >> >> According to Wikipedia, the original IBM PC was sold with as little as >> 16KiB RAM. IIRC, 64KiB BIOS ROM at the top of the 1MiB address space. >> >> http://en.wikipedia.org/wiki/IBM_PC >> >> [...] > Some machines also have broken memory modules. > So some computers have 0 byte RAM in that case. :D Yup, be we *can* catch that in QEMU :)

9 years, 10 months

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS August 2012