SeaBIOS

seabios@seabios.org

4 participants
3801 discussions

Re: [SeaBIOS] SeaBIOS vs other BIOS?
by Gleb Natapov 07 May '12

07 May '12

On Sun, May 06, 2012 at 10:26:31PM +0200, Fred . wrote: > And in terms of standards compliance? > > I know proprietary BIOS have advantage when it comes to SMBIOS due to > the implementation in SeaBIOS lagging behind several versions. > > On Sun, May 6, 2012 at 8:00 PM, Peter Stuge <peter(a)stuge.se> wrote: > > Fred . wrote: > >> How is SeaBIOS working towards the non-technical goals of the project? > > > > This is not so clear. I'm not even sure that there are non-technical > > goals for the project. > > > > Competing with commercial BIOS products would require a company to > > put a SeaBIOS-based PC firmware to market, quite likely in concert > > with coreboot. I know of one company which offers among other things > > coreboot services, Sage Engineering, who are quite active in the > > coreboot community. http://www.se-eng.com/coreboot.html > > > > But even so you can see that the business model is different from > > commercial BIOS products, and already this small difference presents > > a non-technical challenge. > > SeaBIOS lacks documentation. > It lacks communication. > The website is not updated with news about the development. > There is no mention of what's new, whats planned, etc. Now I am curious what other BIOSes give you all that? In all that points Seabios in not different from most other open source project. -- Gleb.

2 1

Re: [SeaBIOS] SeaBIOS vs other BIOS?
by Peter Stuge 06 May '12

06 May '12

Fred . wrote: > How is SeaBIOS working towards the non-technical goals of the project? This is not so clear. I'm not even sure that there are non-technical goals for the project. Competing with commercial BIOS products would require a company to put a SeaBIOS-based PC firmware to market, quite likely in concert with coreboot. I know of one company which offers among other things coreboot services, Sage Engineering, who are quite active in the coreboot community. http://www.se-eng.com/coreboot.html But even so you can see that the business model is different from commercial BIOS products, and already this small difference presents a non-technical challenge. > That said, still curious about a technical comparison. As far as BIOS goes, SeaBIOS will boot and run I believe any OS that a commercial BIOS product does. Differences at this point are perhaps primarily how the build is configured and run, how execution is configured, and the presentation of SeaBIOS during runtime. Because SeaBIOS has a technical goal of not spending more time than neccessary on any task, there isn't much presentation to talk about. Build configuration in SeaBIOS is based on Kconfig, comfortable for anyone who has built a Linux kernel or busybox, but perhaps not completely intuitive for developers who primarily have experience from using Windows systems. The build system itself of SeaBIOS relies on the GNU toolchain, including optionally rather new features, contrary to commercial BIOS products which typically rely on quite old Microsoft toolchains. Runtime configuration in SeaBIOS consists of the F12 menu when multiple boot sources are found, and the QEMU-specific fwcfg interface - compared to the classic text-mode setup menu screens in commercial BIOS products. Then there's of course the fact that BIOS is no longer really relevant for many mainboard vendors, whose customers expect UEFI. //Peter

2 1

Re: [SeaBIOS] SeaBIOS vs other BIOS?
by Peter Stuge 06 May '12

06 May '12

This has very little to do with technical properties, and is much more about politics which obviously require a different approach than technicalities. //Peter

2 1

SeaBIOS vs other BIOS?
by Fred . 06 May '12

06 May '12

What features and functionality does SeaBIOS have that other BIOS does not? What features and functionality does other BIOS have that is better than what SeaBIOS offers?

1 0

Re: [SeaBIOS] [PATCH] Add IASL definition
by Kevin O'Connor 04 May '12

04 May '12

On Sun, Apr 29, 2012 at 11:28:00AM -0600, Marc Jones wrote: > Add IASL definition to the Makefile. > > Add IASL definition to Makefile so it can be passed by the user. Thanks. I applied this change. -Kevin

1 0

[qemu patch] pci: pass i/o windows via fwcfg
by Gerd Hoffmann 04 May '12

04 May '12

This patch adds a fw_cfg entry for the PCI I/O windows. It holds four values, 64bit each. The first two specify the 32bit PCI I/O window below 4G, the second two the 64bit PCI I/O window above 4G. The 32bit PCI I/O window used to start at the fixed address 0xe0000000. Now it starts at the end of low ram, i.e. machines with less than 3.5 GB of memory get a larger PCI I/O window. The 64bit PCI I/O window is located above all memory, is 64G in size and is aligned according to its size, i.e. usually it starts at 64GB and ends at 128GB. When guests have lots of memory it gets moved up accordingly. Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> --- hw/fw_cfg.h | 1 + hw/pc.c | 15 ++++++++++++++- 2 files changed, 15 insertions(+), 1 deletions(-) diff --git a/hw/fw_cfg.h b/hw/fw_cfg.h index 856bf91..3042954 100644 --- a/hw/fw_cfg.h +++ b/hw/fw_cfg.h @@ -27,6 +27,7 @@ #define FW_CFG_SETUP_SIZE 0x17 #define FW_CFG_SETUP_DATA 0x18 #define FW_CFG_FILE_DIR 0x19 +#define FW_CFG_PCI_WINDOWS 0x1a #define FW_CFG_FILE_FIRST 0x20 #define FW_CFG_FILE_SLOTS 0x10 diff --git a/hw/pc.c b/hw/pc.c index 4d34a33..a823b27 100644 --- a/hw/pc.c +++ b/hw/pc.c @@ -72,7 +72,8 @@ #define MSI_ADDR_BASE 0xfee00000 -#define E820_NR_ENTRIES 16 +#define E820_NR_ENTRIES 16 +#define PCI64_SIZE 0x1000000000LL /* 64 GB */ struct e820_entry { uint64_t address; @@ -987,6 +988,7 @@ void pc_memory_init(MemoryRegion *system_memory, int linux_boot, i; MemoryRegion *ram, *option_rom_mr; MemoryRegion *ram_below_4g, *ram_above_4g; + uint64_t *pcimem, pci64_base; void *fw_cfg; linux_boot = (kernel_filename != NULL); @@ -1027,6 +1029,17 @@ void pc_memory_init(MemoryRegion *system_memory, fw_cfg = bochs_bios_init(); rom_set_fw(fw_cfg); + pcimem = g_malloc0(sizeof(uint64_t) * 4); + /* 32bit pci io window */ + pcimem[0] = cpu_to_le64(below_4g_mem_size); + pcimem[1] = cpu_to_le64(0xFEC00000 - 1); + /* 64bit pci io window */ + pci64_base = (0x100000000ULL + above_4g_mem_size + PCI64_SIZE) & ~(PCI64_SIZE-1); + pcimem[2] = cpu_to_le64(pci64_base); + pcimem[3] = cpu_to_le64(pci64_base + PCI64_SIZE - 1); + fw_cfg_add_bytes(fw_cfg, FW_CFG_PCI_WINDOWS, + (uint8_t *)pcimem, sizeof(uint64_t) * 4); + if (linux_boot) { load_linux(fw_cfg, kernel_filename, initrd_filename, kernel_cmdline, below_4g_mem_size); } -- 1.7.1

1 0

[PATCH] Add IASL definition
by Marc Jones 29 Apr '12

29 Apr '12

Add IASL definition to the Makefile. Add IASL definition to Makefile so it can be passed by the user. Signed-off-by: Marc Jones <marc.jones(a)se-eng.com> -- http://se-eng.com

1 0

Re: [SeaBIOS] synching GPE0_BLK between OVMF and qemu
by Gleb Natapov 29 Apr '12

29 Apr '12

On Sat, Apr 28, 2012 at 06:17:24PM -0700, Jordan Justen wrote: > On Sat, Apr 28, 2012 at 00:08, Gleb Natapov <gleb(a)redhat.com> wrote: > > On Fri, Apr 27, 2012 at 02:55:48PM -0700, Jordan Justen wrote: > >> But, if qemu could be changed, > >> could it be made to match the PIIX4 datasheet? > >> > > We try not to change QEMU in non backwards compatible way. We can > > implement PMBA and start using address there if FW writes into it, Actually this is incorrect. QEMU implements PMBA and Seabios sets it to 0xb000. Sorry about the confusion. > > but, as I noted before, OVMF will have to be changed anyways since 0x400 > > address is already occupied and pci/cpu/memory hotplug/unplug > > functionality uses additional IO space not documented by PIIX4 spec. > > The "pci/cpu/memory hotplug/unplug functionality" is also using hard > coded addresses in the 0x400 range? > No, the hard coded addresses at 0x400 range are used for FW debug. There are four of them 0x400/0x401 used to print panic message on stderr and exit qemu process, now they do nothing but qemu still registers them. 0x402/0x403 print character to stderr if qemu is compiled with DEBUG_BIOS, but ports are registered even if DEBUG_BIOS is not defined. hotplug/unplug uses addresses 0xae00 and above. > And, 0xb000 would be the recommended PM base address? > Yes. QEMU splits PM and GPE address spaces though. GPE starts at 0xafe0 and is hardcoded. I do not see the way to move it to PMBA + offset and stay backwards compatible (at least not without adding new fw_cfg value, but what would be the advantage). > > It would be better for OVMF to treat QEMU like separate platform, that > > behave almost, but not exactly like, real HW. > > Yes, it does seem like that will be required here. > Yes, since we do want to support functionality that does not exist in PIIX4 spec. -- Gleb.

1 0

Re: [SeaBIOS] synching GPE0_BLK between OVMF and qemu
by Gleb Natapov 29 Apr '12

29 Apr '12

On Fri, Apr 27, 2012 at 02:55:48PM -0700, Jordan Justen wrote: > On Fri, Apr 27, 2012 at 11:47, Laszlo Ersek <lersek(a)redhat.com> wrote: > > This was how I interpreted our discussion with Jordan: > > > > L: Shouldn't qemu & OVMF agree on GPE0? > > J: Why? Anyway, OVMF should be correct, because all ACPI registers are > > in one tight bunch, starting from 0x400. > > L: None of those two characteristics (1: "0x400", 2: "one tight bunch") > > are required by the spec. For proof, see what SeaBIOS does: 1: it > > doesn't use 0x400 as base, 2: GPE0 is not even above the base. > > This code was written to the PIIX4 datasheet. According to the > datasheet, if you change PMBA, it changes the GPE blk too. > > It sounds like QEMU does not emulate this, and hardcodes the GPE blk. > Yes. QEMU does not really implement PIIX4 though. It implements PIIX3 + PM from PIIX4 (but with a functionality that is not present in original spec like pci/cpu hotplug) + other differences that firmware had to take into account. For instance event if QEMU will implement PMBA, OVMF would not be able to configure it to the value 0x400 since QEMU hardcodes another PV device there. > Regarding a solution, such as communicating the address in fw_cfg, > that could work. OVMF has plans to add fw_cfg support. > Can it check that it runs over QEMU and use QEMU's values? No need for new fw_cfg. > > Anyway, back to my original question: currently OVMF and qemu disagree > > wrt. GPE0. Which one should I try to modify so that they agree? > > It does seem like qemu could be changed, does it? It would require a > simultaneous fix of qemu & seabios. But, if qemu could be changed, > could it be made to match the PIIX4 datasheet? > We try not to change QEMU in non backwards compatible way. We can implement PMBA and start using address there if FW writes into it, but, as I noted before, OVMF will have to be changed anyways since 0x400 address is already occupied and pci/cpu/memory hotplug/unplug functionality uses additional IO space not documented by PIIX4 spec. It would be better for OVMF to treat QEMU like separate platform, that behave almost, but not exactly like, real HW. -- Gleb.

2 1

Re: [SeaBIOS] synching GPE0_BLK between OVMF and qemu
by Laszlo Ersek 27 Apr '12

27 Apr '12

On 04/27/12 17:12, Jordan Justen wrote: > On Fri, Apr 27, 2012 at 07:31, Laszlo Ersek <lersek(a)redhat.com> wrote: >> edk2's "OvmfPkg/AcpiTables/Platform.h" specifies GPE0_BLK at 0x40C, >> while qemu's "hw/acpi_piix4.c" expects the guest to access it at 0xAFE0. >> Which macro should be modified to get them in sync? > > Do they need to be in sync? It appears to me so: https://bugzilla.redhat.com/show_bug.cgi?id=653382#c22 > We set PBMA to 0x400 in OvmfPkg/Library/AcpiTimerLib/AcpiTimerLib.c, > so isn't 0x40c correct? Considering OVMF in isolation, I presume it's self-consistent. However, is it necessary (a) to group these ACPI registers closely together, (b) to base the "group" at 0x400? >From "5.2.9 Fixed ACPI Description Table (FADT)" in the ACPI spec (v5.0) it would appear OVMF can freely choose where to put GPE0_BLK, in both senses (ie. port address considered alone, and also in relation to the other ACPI registers). Considering SeaBIOS again (build_fadt()): - PORT_ACPI_PM_BASE is 0xb000, - PM1a_EVT_BLK, PM1a_CNT_BLK and PM_TMR_BLK are located consecutively from this base, - but GPE0_BLK is placed at 0xafe0 (build_fadt() --> pci_init_device(fadt_init_tbl) --> piix4_fadt_init()) But I'm likely missing something ^W everything... Thanks! Laszlo

3 4

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS