SeaBIOS

seabios@seabios.org

3770 discussions

[ANNOUNCE] Seabios 0.5.0
by Kevin O'Connor 19 Dec '09

19 Dec '09

SeaBIOS 0.5.0 has just been tagged. This release synchs the SeaBIOS tip with qemu in preparation for the qemu-0.12.0 release. The main SeaBIOS repo is available with: git clone git://git.linuxtogo.org/home/kevin/seabios.git Precompiled binaries and source packages are also available at: http://linuxtogo.org/~kevin/SeaBIOS/ Major changes since the last release (0.4.3): * Import of many features needed by kvm and qemu. * The default is now to extract option roms from PCI and from qemu fw_cfg interface. Users of bochs and earlier versions of qemu must now set CONFIG_OPTIONROMS_DEPLOYED=1 in src/config.h. * The bios can now be larger than 64K. (If the bios is over 64K, it will extend into the e-segment.) * Support for "threading" of hardware initialization which can speed up boot times when seabios is used with coreboot. * Initial support for USB keyboards. * Lots of bug fixes and code cleanups. -Kevin

2 2

[PATCH 0/4] qemu option loading
by Gerd Hoffmann 19 Dec '09

19 Dec '09

Hi, qemu is about to change the way how option roms are loaded. pci roms will be loaded into a option rom bar (like real hardware does). non-pci roms can be loaded using the qemu firmware interface. With this change seabios will deploy all roms instead of having qemu copy them to the 0xc0000 -> 0e0000 range. Advantages are: * roms can be packed better, especially in case they resize themself (like the gPXE roms do). * rom area is a bit larger as seabios can additionally use the unused regions of the 0xe0000 segment. * the whole process comes closer to what happens on real hardware. cheers, Gerd

3 12

SeaBIOS release schedule
by Anthony Liguori 19 Dec '09

19 Dec '09

Hi Kevin, Do you have any plans for a regular release schedule for SeaBIOS? For the qemu 0.12.0 release, I'm more or less grabbing a git snapshot but for future releases, I think it would be nice to coordinate to make sure that we grabbed a snapshot that you felt was pretty stable. Currently, qemu releases are anywhere between 3-6 months in duration. We plan the release date before the start of the release but we've altered the lengths to match up with distro cycles. Regards, Anthony Liguori

2 3

Re: [SeaBIOS] Proper support for PCI-based option rom loading (was Re: [Qemu-devel] Re: qdev property bug?)
by Anthony Liguori 17 Dec '09

17 Dec '09

Gerd Hoffmann wrote: > -kernel didn't work on a quick test. Thinking about how to fix this, we have two options. The first would be to use the support in SeaBIOS for static roms but that would limit us to two user supplied option roms (including kernel/multiboot/extboot). We could extend this to more than two roms but I think that's generally ugly. Alternatively, we could introduce a special rom-only PCI device. Besides getting support for a much greater number of option roms, it also gives us a much nicer way to integrate multiboot/linux boot support via qdev (instead of the ugly machine hack we have now). We could make them multifunction devices so that we don't unnecessarily burn PCI slots to support roms. Regards, Anthony Liguori > cheers, > Gerd

6 14

Re: [SeaBIOS] Proper support for PCI-based option rom loading (was Re: [Qemu-devel] Re: qdev property bug?)
by Kevin O'Connor 16 Dec '09

16 Dec '09

On Wed, Dec 16, 2009 at 03:52:34PM +0200, Michael S. Tsirkin wrote: > I am mostly concerned with migrating between qemu versions with > different roms, while guest was in the middle of running ROM. > This might be solved if we migrated ROM content together with > the device and put some padding in ROM content so that > size can be kept constant. SeaBIOS will always copy the roms into the 0xc0000-0xf0000 memory area (regardless of CONFIG_OPTIONROMS_DEPLOYED). So, if one migrates a machine while running a rom, the memory holding the rom should get migrated with everything else. -Kevin

3 7

Re: [SeaBIOS] Proper support for PCI-based option rom loading (was Re: [Qemu-devel] Re: qdev property bug?)
by Kevin O'Connor 16 Dec '09

16 Dec '09

On Tue, Dec 15, 2009 at 10:24:29PM +0100, Sebastian Herbszt wrote: > Keep loading custom roms (e.g. from -option-rom) with rom_add_file > starting at 0xc8000. Modify SeaBIOS to scan the memory range for > pre-deployed option roms before deploying PCI roms. SeaBIOS will > find the last pre-deployed rom and have a starting address for > deploying PCI roms. This will keep ISA option roms working. Unfortunately, if the SeaBIOS post entry gets called again (eg, on ctrl+alt+del), it wont know which roms were originally present, and which roms were deployed by SeaBIOS on the first boot. -Kevin

2 1

Re: [SeaBIOS] Proper support for PCI-based option rom loading (was Re: [Qemu-devel] Re: qdev property bug?)
by Kevin O'Connor 16 Dec '09

16 Dec '09

On Mon, Dec 14, 2009 at 08:37:44PM -0600, Anthony Liguori wrote: > Okay, I think I've figured out how this is supposed to work. With these > two patches to SeaBIOS and the patch to qemu, I can run: I'm not sure why "Do not guard qemu shadow ram work around in CONFIG_OPTIONROMS_DEPLOYED" patch is needed. The code today is: if (CONFIG_OPTIONROMS_DEPLOYED) { int reg = pci_config_readb(bdf, 0x5a + i); if ((reg & 0x11) != 0x11) { // Need to copy optionroms to work around qemu implementation void *mem = (void*)(BUILD_ROM_START + i * 32*1024); memcpy((void*)BUILD_BIOS_TMP_ADDR, mem, 32*1024); pci_config_writeb(bdf, 0x5a + i, 0x33); memcpy(mem, (void*)BUILD_BIOS_TMP_ADDR, 32*1024); clear = 1; } else { pci_config_writeb(bdf, 0x5a + i, 0x33); } } else { pci_config_writeb(bdf, 0x5a + i, 0x33); } So, in the non CONFIG_OPTIONROMS_DEPLOYED case, SeaBIOS will just do the write enable call (pci_config_writeb(bdf, 0x5a + i, 0x33)). The CONFIG_OPTIONROMS_DEPLOYED case should just be to copy the roms qemu has deployed. If SeaBIOS is filling in the 0xc0000-0xf0000 space, it shouldn't matter if the contents of that space is lost during the write enable. Let me know if I've missed something. -Kevin

4 7

Welcome to SeaBIOS
by Kevin O'Connor 13 Dec '09

13 Dec '09

Welcome to the SeaBIOS mailing list.

1 0

[PATCH] Fix PkgLength calculation for the SSDT.
by Magnus Christensson 25 Nov '09

25 Nov '09

Signed-off-by: Magnus Christensson <mch(a)virtutech.com> --- src/acpi.c | 6 ++++-- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/src/acpi.c b/src/acpi.c index f613b03..244536a 100644 --- a/src/acpi.c +++ b/src/acpi.c @@ -429,10 +429,12 @@ build_ssdt(void) // build processor scope header *(ssdt_ptr++) = 0x10; // ScopeOp if (cpu_length <= 0x3e) { + /* Handle 1-4 CPUs with one byte encoding */ *(ssdt_ptr++) = cpu_length + 1; } else { - *(ssdt_ptr++) = 0x7F; - *(ssdt_ptr++) = (cpu_length + 2) >> 6; + /* Handle 5-314 CPUs with two byte encoding */ + *(ssdt_ptr++) = 0x40 | ((cpu_length + 2) & 0xf); + *(ssdt_ptr++) = (cpu_length + 2) >> 4; } *(ssdt_ptr++) = '_'; // Name *(ssdt_ptr++) = 'P'; -- 1.6.2.5 --------------010908080004080305080203--

1 0

[PATCH 01/12] Read APIC version from APIC instead of using a hard-coded value.
by Magnus Christensson 23 Nov '09

23 Nov '09

Signed-off-by: Magnus Christensson <mch(a)virtutech.com> --- src/mptable.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/src/mptable.c b/src/mptable.c index f65bbeb..5357c03 100644 --- a/src/mptable.c +++ b/src/mptable.c @@ -36,6 +36,7 @@ mptable_init(void) // Detect cpu info u32 cpuid_signature, ebx, ecx, cpuid_features; cpuid(1, &cpuid_signature, &ebx, &ecx, &cpuid_features); + u8 apic_version = readl((u8*)BUILD_APIC_ADDR + 0x30) & 0xff; int pkgcpus = 1; if (cpuid_features & (1 << 28)) { /* Only populate the MPS tables with the first logical CPU in @@ -51,7 +52,7 @@ mptable_init(void) memset(cpu, 0, sizeof(*cpu)); cpu->type = MPT_TYPE_CPU; cpu->apicid = i; - cpu->apicver = 0x11; + cpu->apicver = apic_version; /* cpu flags: enabled, bootstrap cpu */ cpu->cpuflag = (i < CountCPUs) | ((i == 0) << 1); if (cpuid_signature) { -- 1.6.2.5 --------------020907050102080101050605--

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS