SeaBIOS

seabios@seabios.org

3770 discussions

Xen Hypervisor and Disk Drive Layer
by Daniel Castro 03 May '11

03 May '11

Greetings, My Name is Daniel Castro, I am working with the Xen Hypervisor Community in order to change our existing BIOS for SeaBIOS. For now we are interested to modify the int 13 where the higher level disk driver abstraction resides, We will plug into it in order to communicate via shared memory and replace the existing emulated devices that are being used (Xen only). The result will be a patch for your source code maintainer that will include support for Xen. I am going to write new code to allow SeaBios to use the split-driver model of Xen to write directly to the back-end device of Xen using shared memory, but was wondering if I could leverage the drive abstraction layer that SeaBIOS has for hard drives? How and where does Virtio handle this? And also where is the best place to insert the code? So in a very near future I could send patch to the SeaBIOS repository. I will greatly appreciate any help and information you can give us that will help us to join efforts and include SeaBIOS into Xen. If you have any suggestions on the best way to do this please do not hesitate to email me, I am not familiar with SeaBIOS so please be as detailed as posible. Thank you all for your time, Best Regards, Daniel -- +-=====---------------------------+ | +---------------------------------+ | This space intentionally blank for notetaking. | | | Daniel Castro, | | | | Consultant/Programmer.| | | | U Andes | +-------------------------------------+

3 2

[PATCH] skip interactive boot menu if only one boot device present
by Sven Schnelle 30 Apr '11

30 Apr '11

There's no point in presenting a menu to the user if there's only one option to choose from. In that case skip this menu to save some waiting time during boot. Signed-off-by: Sven Schnelle <svens(a)stackframe.org> --- src/boot.c | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/src/boot.c b/src/boot.c index 1cd4126..df26d33 100644 --- a/src/boot.c +++ b/src/boot.c @@ -360,6 +360,11 @@ interactive_bootmenu(void) if (! CONFIG_BOOTMENU || ! qemu_cfg_show_boot_menu()) return; + /* If we have only one bootdevice, + skip interactive menu */ + if (!BootList->next) + return; + while (get_keystroke(0) >= 0) ; -- 1.7.4.4

4 5

[PATCH] Make pci memory window configurable.
by Gerd Hoffmann 28 Apr '11

28 Apr '11

This patch makes the memory window for PCI memory bars configurable via Kconfig. Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> --- src/Kconfig | 6 ++++++ src/config.h | 4 ++-- 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/src/Kconfig b/src/Kconfig index 6d55b23..c68a815 100644 --- a/src/Kconfig +++ b/src/Kconfig @@ -187,6 +187,12 @@ menu "Hardware support" depends on EXTRA_PCI_ROOTS hex "Extra secondary PCI root bus number" default 0x00 + config PCIMEM_START + hex "PCI memory window start address" + default 0xf0000000 + config PCIMEM_SIZE + hex "PCI memory window size size" + default 0x08000000 config USE_SMM depends on !COREBOOT diff --git a/src/config.h b/src/config.h index 5b40488..4500669 100644 --- a/src/config.h +++ b/src/config.h @@ -57,8 +57,8 @@ #define BUILD_PCIPREFMEM_SIZE 0 #define BUILD_PCIPREFMEM_END 0 #else -#define BUILD_PCIMEM_START 0xf0000000 -#define BUILD_PCIMEM_SIZE 0x08000000 /* half- of pci window */ +#define BUILD_PCIMEM_START CONFIG_PCIMEM_START +#define BUILD_PCIMEM_SIZE CONFIG_PCIMEM_SIZE #define BUILD_PCIMEM_END (BUILD_PCIMEM_START + BUILD_PCIMEM_SIZE) #define BUILD_PCIPREFMEM_START BUILD_PCIMEM_END #define BUILD_PCIPREFMEM_SIZE (BUILD_PCIPREFMEM_END - BUILD_PCIPREFMEM_START) -- 1.7.1

2 2

my bios.bin.elf is too big
by Rock Cui 07 Apr '11

07 Apr '11

hello, everyone, I'm a seabios newer. I want to build a coreboot image with seabios as its payload. I need the seabios(bios.bin.elf) to be smaller then 1M, but I got a 1.3M one after building . I did not change anything in my seabios host directory. I don't know how to decrease the size. My colleague had built a smaller image(64k) with cygwin in win7, but he also does not know how to help me. So if anyone could give me some advices, that will be highly appreciated!^_^ PS: I don't know whether this subject line meets the requirements, if not, please tell me, thinks a lot!

3 3

GSoC: Xen.org project to implement PV driver frontend for SeaBIOS
by Ian Campbell 06 Apr '11

06 Apr '11

Hi, (I was unsure what the appropriate mailing list for this was, apologies for the cross post) You may or may not be aware that Xen intends to switch to using SeaBIOS as part of switching to using upstream qemu as our device model (hopefully in our next major release later this year). The switch to SeaBIOS is currently a WIP by Anthony Perard (who did the Xen port to upstream qemu). This is mainly a heads up that we have several students interested in a project which I am mentoring to add Xen PV frontends (particularly disk) to SeaBIOS . You can see a brief description of the project near the end of the table at http://wiki.xen.org/xenwiki/GSoC_2011_ideas. Obviously one of the main goals will be to work with the SeaBIOS (and if necessary qemu) communities as well as Xen.org in order to produce patches which can can be submitted to the relevant upstreams. If/when we have an actual student assigned to the project I will ask them introduce themselves too. If anyone want to be more involved with this work (e.g. as a backup mentor or whatever) then please do let me know. Cheers, Ian.

3 2

[PATCH V3 0/8] Add TPM support to SeaBIOS
by Stefan Berger 05 Apr '11

05 Apr '11

The following set of patches add TPM and Trusted Computing support to SeaBIOS. In particular the patches add: - a TPM driver for the Qemu's TPM TIS emulation (not yet in Qemu git) - ACPI support for the TPM device (SSDT table) - ACPI support for measurement logging (TCPA table) - Support for initialzation of the TPM - Support for the TCG BIOS extensions (1ah handler [ah = 0xbb]) (used by trusted grub; http://trousers.sourceforge.net/grub.html) - Static Root of Trusted for Measurement (SRTM) support - Support for S3 resume (sends command to TPM upon resume) - TPM-specific menu for controlling aspects of the TPM - [An optional test suite for the TIS interface] All implementations necessarily follow specifications. When all patches are applied the following services are available - SSDT ACPI table for TPM support - initialization of the TPM upon VM start and S3 resume - Static root of trust for measurements (SRTM) that measures (some) data of SeaBIOS in TCPA ACPI table - 1ah interrupt handler offering APIs for measuring and sending commands to the TPM (trusted grub uses them) - User menu for controlling aspects of the state of the TPM v3: - some nits here and there - calling timer_setup now after S3 resume v2: - following Kevin's comment - refactoring code so that every patch compiles Regards, Stefan

2 9

[PATCH V2 0/8] Add TPM support to SeaBIOS
by Stefan Berger 05 Apr '11

05 Apr '11

2 10

[PATCH V1 0/8] Add TPM support to SeaBIOS
by Stefan Berger 04 Apr '11

04 Apr '11

2 16

Re: [SeaBIOS] [Qemu-devel] OEM Windows in qemu/kvm again (mini-howto)
by Isaku Yamahata 01 Apr '11

01 Apr '11

Hi. SLIC table can be fed dynamically by utilize the existing fw_cfg interface. Something like this. (This requires your qemu patch.) This is just for showing the idea. thanks, diff --git a/src/acpi.c b/src/acpi.c index 6428d9c..e0815bd 100644 --- a/src/acpi.c +++ b/src/acpi.c @@ -627,6 +627,7 @@ acpi_bios_init(void) ACPI_INIT_TABLE(build_srat()); u16 i, external_tables = qemu_cfg_acpi_additional_tables(); + bool slic = false; for(i = 0; i < external_tables; i++) { u16 len = qemu_cfg_next_acpi_table_len(); @@ -635,7 +636,12 @@ acpi_bios_init(void) warn_noalloc(); continue; } - ACPI_INIT_TABLE(qemu_cfg_next_acpi_table_load(addr, len)); + struct acpi_table_header *header = + qemu_cfg_next_acpi_table_load(addr, len); + if (header->signature == SLIC_SIGNATURE) { + slic = true; + } + ACPI_INIT_TABLE(header); if (tbl_idx == MAX_ACPI_TABLES) { warn_noalloc(); break; @@ -654,6 +660,9 @@ acpi_bios_init(void) memcpy(rsdt->table_offset_entry, tables, sizeof(u32) * tbl_idx); build_header((void*)rsdt, RSDT_SIGNATURE, rsdt_len, 1); + if (slic) { + // fix up rsdt->oem_id and check sum + } // Build rsdp pointer table memset(rsdp, 0, sizeof(*rsdp)); On Thu, Mar 31, 2011 at 05:00:08PM +0400, Michael Tokarev wrote: > Here's a quick-n-dirty howto about running OEM version > of windows7 or vista in qemu/kvm, assuming you own a > computer with pre-installed OEM version of such operating > system so you have rights to run it there. > > Windows 7 & Vista OEM activation are based on a special > OEM marker in BIOS in a form of one ACPI table named SLIC. > The idea is to take content of that table from your computer > and present it in the virtual machine. > > This table can be taken directly from /sys/firmware/acpi/tables/SLIC > (it's a small binary file), and hopefully qemu will be able > to use that directly (I submitted a patch to do that a few > days ago). > > But there's on caveat still: windows apparently checks not only > the SLIC table/marker, but also verifies that the Vendor ID > fields in SLIC and RSDT tables matches each other. So just > presenting SLIC into a VM isn't enough, one have to modify > at least two fields in RSDT table too. > > And since there's no way currently to do that using qemu > command line, I took another approach and modified seabios > code a bit. Here's a small howto to do that "at home". > > 1) First of all, you need seabios source code appropriate > for your qemu/kvm. See http://www.seabios.org/ for that. > Also you need tools to recompile it, obviously. > > 2) after getting and extracting seabios sources, cd to > the source directory. > > 3) You need to build slic table to be used by a C compiler, > like this: > > xxd -i /sys/firmware/acpi/tables/SLIC | > grep -v len | > sed 's/unsigned char.*/static char SLIC[] = {/' > > src/acpi-slic.hex > > this produces file src/acpi-slic.hex with content like > this: > > static char SLIC[] = { > 0x53, 0x4c, 0x49, 0x43, 0x76, 0x01, ... > }; > > 4) apply the following patch to src/acpi.c: > > ============= cut ============= > --- a/src/acpi.c > +++ b/src/acpi.c > @@ -199,4 +199,9 @@ struct srat_memory_affinity > #include "acpi-dsdt.hex" > > +#define CONFIG_OEM_SLIC > +#ifdef CONFIG_OEM_SLIC > +#include "acpi-slic.hex" > +#endif > + > static void > build_header(struct acpi_table_header *h, u32 sig, int len, u8 rev) > @@ -211,4 +216,8 @@ build_header(struct acpi_table_header *h, u32 sig, int len, u8 rev) > h->oem_revision = cpu_to_le32(1); > h->asl_compiler_revision = cpu_to_le32(1); > +#ifdef CONFIG_OEM_SLIC > + if (sig == RSDT_SIGNATURE) // only RSDT is checked by win7 & vista > + memcpy(h->oem_id, ((struct acpi_table_header*)SLIC)->oem_id, 14); > +#endif > h->checksum -= checksum(h, len); > } > @@ -627,4 +636,15 @@ acpi_bios_init(void) > ACPI_INIT_TABLE(build_srat()); > > +#ifdef CONFIG_OEM_SLIC > + { void *buf = malloc_high(sizeof(SLIC)); > + if (!buf) > + warn_noalloc(); > + else { > + memcpy(buf, SLIC, sizeof(SLIC)); > + ACPI_INIT_TABLE(buf); > + } > + } > +#endif > + > u16 i, external_tables = qemu_cfg_acpi_additional_tables(); > > ============= cut ============= > > The patch above arranges for your SLIC table to be > included inside the ("virtual") bios (that table does > exactly nothing for the bios itself and for other > system components) and also modifies OEM identification > information in RSDT table to match SLIC table. > > 5) build the bios as usual by issuing `make' in the top > source directory. You'll get out/bios.bin file. > Place it somewhere like /usr/share/qemu/bios-asus.bin > or anywhere like you want. > > 6) and finally, specify that bios file when running your > preinstalled windows: > > qemu -hda /dev/sda -bios /usr/share/qemu/bios-asus.bin > [...other options...] > > (But be careful and choose appropriate boot entry, do > not boot linux itself in your virtual machine :) > > Something like that. This is formed as a quick-n-dirty > howto because there's quite alot of questions lately about > this very stuff (how to run activated windows in qemu), > and I wanted to write an instruction so that less > expirienced people will be able to do that. > > > Kevin, do you remember why this code is present in > acpi.c: > > build_header(struct acpi_table_header *h, u32 sig, int len, u8 rev) > { > memcpy(h->oem_id, CONFIG_APPNAME6, 6); > memcpy(h->oem_table_id, CONFIG_APPNAME4, 4); > memcpy(h->asl_compiler_id, CONFIG_APPNAME4, 4); > memcpy(h->oem_table_id + 4, (void*)&sig, 4); <=== this > > To me it looks like we need another #define, like > CONFIG_APPNAME8, to be used for whole oem_table_id > field. And also, maybe made all this stuff configurable > somehow (starting from the build config in out/autoconf.h > etc) ? > > Thanks! > > /mjt > -- yamahata

1 0

Re: [SeaBIOS] Some questions
by Kevin O'Connor 31 Mar '11

31 Mar '11

Hi Stefan, I'm CC'ing the mailing list. On Wed, Nov 24, 2010 at 11:45:17AM -0500, Stefan Berger wrote: > Hi Kevin, > > while I am porting the BIOS code for TCG support to SeaBIOS, I am > wondering about the following: > > 'When' is it recommendable to switch from 16 bit to 32bit. To be honest, this has never really been done before in SeaBIOS, so I think we'll have to figure this out as we go. Since you need to access full memory, it looks like it will be required to jump into 32bit mode. >I am > asking because the interface I am implementing allows callers to > pass input and output data structures using es:di and ds:si, with es > and ds allowed to be loaded with anything possible. So my strategy > in the Bochs BIOS was to switch to 32 bit even before calling the > interrupt handler, there doing the case statement for branching into > the actual functions (switch (regs->al)) and passing 32 bit pointers > converted from es:di and ds:si to the functions doing the work and > reading from those memory locations. This sounds okay to me - it should be possible to implement handle_1abb(regs) which does a call32(tcg32_1abb, regs). It's possible to do all the pointer conversion while in 32bit mode. >The 'thing' is also that > several ones of the functions that can be called through the > interrupt interface are also called from the implemented functions. > Example: > > Functions A,B,C can be called via the interrupt handler. > > Function B also calls A. > Function C also calls B. This shouldn't really be an issue. The build should take care of this. > > This is due to the hierarchical nature of the functions. Also, while > for example B calls A, B fills a data structure (on the stack) that > it passes to A. A of course can get the same data structure from the > user calling the interrupt interface. So, by switching to 32 bit > mode and converting to 32 bit pointers early I could previously > avoid a lot of headaches with the segment registers in 16 bit mode > and reading the data from wherever they may be. Would you have any > concerns about switching to 32 bit mode early, so that the interrupt > handler and anything subsequent runs in 32 bit mode? I can't say for sure what will make sense without seeing the code first, but it sounds okay to me. -Kevin > > Regards, > Stefan > > >

2 4

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS