SeaBIOS

seabios@seabios.org

4 participants
3801 discussions

Re: [SeaBIOS] [Qemu-devel] [PATCH 5/6] load_linux: report open kernel file & its size error
by li guang 05 Feb '13

05 Feb '13

OK, will fix. Thanks! 在 2013-02-04一的 18:20 +0000，Blue Swirl写道： > On Mon, Feb 4, 2013 at 2:27 AM, liguang <lig.fnst(a)cn.fujitsu.com> wrote: > > Signed-off-by: liguang <lig.fnst(a)cn.fujitsu.com> > > --- > > hw/pc.c | 14 +++++++++++--- > > 1 files changed, 11 insertions(+), 3 deletions(-) > > > > diff --git a/hw/pc.c b/hw/pc.c > > index 01d00f6..0ccd775 100644 > > --- a/hw/pc.c > > +++ b/hw/pc.c > > @@ -652,12 +652,20 @@ static void load_linux(void *fw_cfg, > > char *vmode; > > > > /* Align to 16 bytes as a paranoia measure */ > > - cmdline_size = (strlen(kernel_cmdline)+16) & ~15; > > + cmdline_size = (strlen(kernel_cmdline)+16) & ~0xf; > > Here 15 is 16 - 1, so 0xf seems out of place. I'd use QEMU_ALIGN_UP(). > > If you touch the line, please add spaces around '+'. > > > > > /* load the kernel header */ > > f = fopen(kernel_filename, "rb"); > > - if (!f || !(kernel_size = get_file_size(f)) || > > - fread(header, 1, MIN(ARRAY_SIZE(header), kernel_size), f) != > > + if (!f) { > > + fprintf(stderr, "can't open kernel image file\n"); > > The error message from strerror(errno) would be interesting. > > > + exit(1); > > + } > > + kernel_size = get_file_size(f); > > + if (kernel_size <= 0) { > > + fprintf(stderr, "can't get size of kernel image file\n"); > > + exit(1); > > + } > > + if (fread(header, 1, MIN(ARRAY_SIZE(header), kernel_size), f) != > > MIN(ARRAY_SIZE(header), kernel_size)) { > > fprintf(stderr, "qemu: could not load kernel '%s': %s\n", > > kernel_filename, strerror(errno)); > > -- > > 1.7.2.5 > > > >

1 0

Re: [SeaBIOS] [PATCH 05/13] Add macros for pushing and popping struct bregs
by David Woodhouse 31 Jan '13

31 Jan '13

On Wed, 2013-01-30 at 22:13 -0500, Kevin OConnor wrote: > This bothers me a little as well. Would it be possible to > separate out the UMBStart/End stuff into a separate patch. (The > main patch would assume OVMF doesn't lock 0xc0000-0xfffff at all, > and the UMBStart/End patch would assume that OVMF has your > proposed extensions.) I've done that and pushed it to the git tree. Although the latest version actually works fine anyway, as long as OVMF has the simple one-line to avoid locking the range. The extra fields in the table don't bother it at all since the table has a TableLength field and the checksum is calculated over that. So they're just ignored. -- dwmw2

1 0

Re: [SeaBIOS] [PATCH 05/13] Add macros for pushing and popping struct bregs
by David Woodhouse 31 Jan '13

31 Jan '13

On Wed, 2013-01-30 at 09:58 -0700, Marc Jones wrote: > > > Not-yet-signed-off-by: David Woodhouse <David.Woodhouse(a)intel.com> > would-be-acked-by: Marc Jones <marc.jones(a)se-eng.com> Thanks. I've updated the git tree at git://, http://git.infradead.org/users/dwmw2/seabios.git accordingly. The 'not yet' bit has been revoked, btw. The bureaucracy is done and it's ready for merging once it's passed review. The main thing that bothers me is the UMBStart,UMBEnd fields and corresponding patch to OVMF; we haven't finalised that side of it yet but we certainly *need* it. -- David Woodhouse Open Source Technology Centre David.Woodhouse(a)intel.com Intel Corporation

2 1

[PATCH] Reject non-compliant PCI option ROMs
by David Woodhouse 29 Jan '13

29 Jan '13

cf. http://lists.gnu.org/archive/html/qemu-devel/2013-01/msg03650.html Signed-off-by: David Woodhouse <David.Woodhouse(a)intel.com> diff --git a/src/Kconfig b/src/Kconfig index f35b0f5..e49dd82 100644 --- a/src/Kconfig +++ b/src/Kconfig @@ -293,6 +293,13 @@ menu "BIOS interfaces" default y help Support finding and running option roms during POST. + config PERMIT_UNALIGNED_PCIROM + bool "Allow broken PCI option ROMs with unaligned PCIR table" + default n + help + Support initialising PCI ROMs which violate the spec by having + their PCI information at an unaligned offset, and which may not + be accepted by other firmwares. config OPTIONROMS_DEPLOYED depends on OPTIONROMS bool "Option roms are already at 0xc0000-0xf0000" diff --git a/src/optionroms.c b/src/optionroms.c index c9e7d7b..99c4135 100644 --- a/src/optionroms.c +++ b/src/optionroms.c @@ -107,6 +107,8 @@ static struct pci_data * get_pci_rom(struct rom_header *rom) { struct pci_data *pd = (void*)((u32)rom + rom->pcioffset); + if ((rom->pcioffset & 3) && !CONFIG_PERMIT_UNALIGNED_PCIROM) + return NULL; if (pd->signature != PCI_ROM_SIGNATURE) return NULL; return pd; -- dwmw2

1 0

[PATCH] Reformat .lst in case it is generated by new iasl.
by Bo Yang 26 Jan '13

26 Jan '13

New iasl generate .lst as 'number: ' instead of 'number....', then acpi_extrace.py fails to extract any useful information, building fails. Signed-off-by: Bo Yang <boyang(a)suse.com> --- Makefile | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/Makefile b/Makefile index f28d86c..e87210b 100644 --- a/Makefile +++ b/Makefile @@ -217,6 +217,7 @@ $(OUT)%.hex: src/%.dsl ./tools/acpi_extract_preprocess.py ./tools/acpi_extract.p $(Q)cpp -P $< > $(OUT)$*.dsl.i.orig $(Q)$(PYTHON) ./tools/acpi_extract_preprocess.py $(OUT)$*.dsl.i.orig > $(OUT)$*.dsl.i $(Q)$(IASL) $(call iasl-option,$(IASL),-Pn,) -vs -l -tc -p $(OUT)$* $(OUT)$*.dsl.i + $(Q)sed -i 's/^$ *[0-9A-Fa-f]\+$: /\1..../' $(OUT)$*.lst $(Q)$(PYTHON) ./tools/acpi_extract.py $(OUT)$*.lst > $(OUT)$*.off $(Q)cat $(OUT)$*.off > $@ -- 1.6.0.2

2 2

[PATCH] Reformat .lst in case it is generated by new iasl.
by Bo Yang 24 Jan '13

24 Jan '13

1 0

SeaBIOS CSM status
by David Woodhouse 24 Jan '13

24 Jan '13

Just a brief update for those who are interested... the CSM is fairly functional now. I've tested with: Various Linuxes including CentOS [56], Fedora 17. Windows 7 Windows 2008r2 (via EFI) OpenBSD 5.2 FreeBSD 9 FreeBSD 8 Debian/kFreeBSD (also FBSD 8 kernel I think) DragonflyBSD NetBSD Solaris 10 Solaris 11 OpenIndiana FreeDOS I think everything is working except a few problems with the ACPI tables that OVMF produces. OpenBSD crashes in its AML interpreter unless I revert OVMF commit r14403. FreeBSD 9 crashes when assigning PCI interrupts: pcib0: allocated type 3 (0x82000000-0x8201ffff) for rid 10 of pci0:0:3:0 map[14]: type I/O Port, range 32, base 0xc000, size 6, enabled pcib0: allocated type 4 (0xc000-0xc03f) for rid 14 of pci0:0:3:0 pcib0: matched entry for 0.3.INTA (src \_SB_.PCI0.LPC_.LNKC:0) ... and then it just sits there. If I boot with a normal SeaBIOS, it looks like this: pcib0: allocated type 3 (0xfeba0000-0xfebbffff) for rid 10 of pci0:0:3:0 map[14]: type I/O Port, range 32, base 0xc000, size 6, enabled pcib0: allocated type 4 (0xc000-0xc03f) for rid 14 of pci0:0:3:0 pcib0: matched entry for 0.3.INTA (src \_SB_.LNKC:0) pcib0: slot 3 INTA routed to irq 11 via \_SB_.LNKC isab0: <PCI-ISA bridge> at device 1.0 on pci0 isa0: <ISA bus> on isab0 ... and continues happily. FreeBSD 8 (and Debian/kFreeBSD) seem to work but keep complaining of a storm of IRQ9, which is the ACPI interrupt. At this point, I'm fairly much prepared to declare that all of those are Not My Fault™ and that the CSM is basically working. I'm probably going to look at NV variable storage for OVMF next, using qemu's fw_cfg (which *is* writeable) directly instead of the evil thing it does now with storing a file on the EFI partition. And also fix up the device detection on the OVMF side, and fix the fact that OVMF won't even *ask* the CSM to boot from a virtio or SCSI disk if they exist. -- dwmw2

1 0

Problems booting FreeBSD9 under SeaBIOS as CSM
by David Woodhouse 23 Jan '13

23 Jan '13

I'm probably going to have to chase this one down for myself, but before I do I figured I'd ask if anyone's seen anything similar before, and can give me some pointers... When booting FreeBSD 9 under real SeaBIOS, it all works fine. When SeaBIOS is invoked for a 'legacy' boot under EFI, the FreeBSD bootloader gets as far as displaying its main screen with the FreeBSD banner and the ASCII-art dæmon and the options, but then seems to *stop* before displaying the 'Autoboot in 9 seconds. Press [Space] to pause' message. The qemu log shows that it's in an endless stream of Servicing hardware INT=0x20 44024: v=20 cr0=00000032 e=0000 i=0 cpl=0 IP=f000:000000000000ffec pc=00000000000fffec SP=0000:0000000000005d9c EAX=0000000000000000 EAX=00000000 EBX=00005dd0 ECX=0000ffea EDX=00000000 ESI=0000c350 EDI=00000000 EBP=00000000 ESP=00005d9c EIP=0000ffec EFL=00000202 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =d500 000d5000 ffffffff 00cf9300 CS =f000 000f0000 0000ffff 00009a00 SS =0000 00000000 ffffffff 00cf9300 DS =0000 00000000 ffffffff 00cf9300 FS =0000 00000000 ffffffff 00cff300 GS =0000 00000000 ffffffff 00cff300 LDT=0000 00000000 0000ffff 00008200 TR =0038 00005f98 00002067 00008900 GDT= 00009590 0000003f IDT= 00000000 000003ff CR0=00000032 CR2=00000000 CR3=7fb36000 CR4=00000648 DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 DR6=00000000ffff0ff0 DR7=0000000000000400 CCS=00000044 CCD=00000000 CCO=EFLAGS EFER=0000000000000000 44025: v=1c cr0=00000032 e=0000 i=1 cpl=0 IP=f000:000000000000f856 pc=00000000000ff856 SP=0000:0000000000005d72 EAX=0000000000000000 EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000000 ESI=00000000 EDI=00000000 EBP=00000000 ESP=00005d72 EIP=0000f856 EFL=00000202 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0000 00000000 ffffffff 00cf9300 CS =f000 000f0000 0000ffff 00009a00 SS =0000 00000000 ffffffff 00cf9300 DS =0000 00000000 ffffffff 00cf9300 FS =0000 00000000 ffffffff 00cff300 GS =0000 00000000 ffffffff 00cff300 LDT=0000 00000000 0000ffff 00008200 TR =0038 00005f98 00002067 00008900 GDT= 00009590 0000003f IDT= 00000000 000003ff CR0=00000032 CR2=00000000 CR3=7fb36000 CR4=00000648 DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 DR6=00000000ffff0ff0 DR7=0000000000000400 CCS=00000000 CCD=00000000 CCO=EFLAGS EFER=0000000000000000 Servicing hardware INT=0x20 -- dwmw2

2 2

[PATCH 0/2] q35: Fix seabios IRQ mapping and setup
by Alex Williamson 23 Jan '13

23 Jan '13

This seems like the easier approach from my RFC yesterday. Instead of trying to make ich9 interrupt mapping look like piix, just add a new slot-to-irq function so we can not only get bus 0 devices, but root ports fixed as well. The change from piix mapping is subtle, but required for device assignment. Additionally, fix the PIRQn initialization value, enabling the interrupts for boot ROMs. Thanks, Alex --- Alex Williamson (2): q35: Enable all PIRQn IRQs at startup q35: Add new PCI slot to irq routing function src/pciinit.c | 41 ++++++++++++++++++++++++++++++++++++----- 1 file changed, 36 insertions(+), 5 deletions(-)

1 4

[RFC PATCH 0/2] Q35/ICH9 interrupt routing
by Alex Williamson 21 Jan '13

21 Jan '13

I was trying to revive the patch to add Qemu INTx routing support for Q35 and stumbled on some rather broken interrupt routing problems. Sadly a seabios release claiming Q35 support snuck out already, but I'd like to at least discuss these before Qemu 1.4 even though they may not get fixed for that release either. ICH9 adds 4 more PCI interrupt routing registers, so in addition to the previous PIRQ[A:D], we now also have PIRQ[E:H]. AIUI, each pin can operate in either PIC or APIC mode based on whether the IRQEN bit of each register is clear or set respectively. In PIC mode bits 3:0 of the PIRQn register identifiy the ISA compatible interrupt to trigger. In APIC mode each PIRQn is statically mapped to an APIC pin, where PIRQA->16, PIRQB->17, ..., PIRQH->23. The first problem we encounter is that the system boots into PIC mode but we're programming the PIRQn registers into APIC mode. After fixing that, we quickly notice that seabios has a single function for programming PCI interrupt line registers based on the PIIX mapping of PIRQn registers. A comment in the Qemu source indicates the slot:pin to PIRQn mapping is arbitrary so long as Qemu and ACPI match, disregarding that boot ROMs may also use interrupts and have no ACPI support. Solutions to this are either to create an ICH9 specific mapping function or to adjust slot:pin mappings to match PIIX. I've done the latter here, but it's incomplete as slots 25-31 have directly programmable mappings. I'm looking for comments on how to proceed. Do we want to try to meld ICH9 to be more PIIX compatible or do we want to do our own thing. I suspect there are still a number of holes in ICH9 irq programming no matter which path we take and these in particular are likely to be challenging for migration compatibility. Thanks, Alex --- Alex Williamson (2): q35: Fix PIC-mode interrupt setup q35: Fix ACPI _PRT routing to match PIIX src/pciinit.c | 6 +-- src/q35-acpi-dsdt.dsl | 100 +++++++++++++++++++++++++------------------------ 2 files changed, 52 insertions(+), 54 deletions(-)

1 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS