SeaBIOS

seabios@seabios.org

3783 discussions

Re: [SeaBIOS] [Qemu-devel] SeaBIOS booting time optimization
by Samuel Ortiz 19 Nov '18

19 Nov '18

Hi Stefan, On Fri, Nov 16, 2018 at 04:39:20PM +0000, Stefan Hajnoczi wrote: > On Fri, Nov 16, 2018 at 4:21 PM Stefano Garzarella <sgarzare(a)redhat.com> wrote: > > I'm investigating the SeaBIOS booting time, to understand if we can reduce > > the boot time in some cases (e.g. legacy hardware is not needed). I think > > this > > can be interesting also for NEMU developers. > > Questions for NEMU folks: > > qboot isn't part of the virt-x86 NEMU tree and is only mentioned in > one or two places. Is NEMU focussing exclusively on OVMF guest > firmware instead of qboot? Initally we were only focusing on OVMF, but we added support for qboot [1] as we were not happy with the OVMF boot latencies we measured, especially in the Kata containers context. Rob was about to start looking at seabios support as well. We are going to upstream a cleaner version of the virt support to qboot very soon now. > Are there other boot time optimizations in NEMU that are a candidate > for upstreaming? We did not add anything specific, but when comparing PC+qboot with virt+qboot, we're seeing interesting overall boot time improvements. We assume the simpler virt machine type explains the difference. Cheers, Samuel. [1] https://github.com/rbradford/qboot/commit/dbcaaa1f6921064cd46f330a3625eb01e…

1 0

[ANNOUNCE] SeaBIOS 1.12.0
by Kevin O'Connor 18 Nov '18

18 Nov '18

The 1.12.0 version of SeaBIOS has now been released. For more information on the release, please see: http://seabios.org/Releases New in this release: * Initial support for "TPM CRB" hardware * Improved cdrom media reporting in the boot menu on QEMU * Improved floppy support on real floppy hardware * SeaVGABIOS support for QEMU "bochs-display" and QEMU "ramfb" displays * Several bug fixes and code cleanups For information on obtaining SeaBIOS, please see: http://seabios.org/Download ===== git shortlog -n rel-1.11.0..rel-1.12.0 ===== Gerd Hoffmann (12): optionrom: enable non-vga display devices cbvga: factor out cbvga_setup_modes() qemu: add bochs-display support cbvga_setup_modes: use real mode number instead of 0x140 cbvga_list_modes: don't list current mode twice cbvga_set_mode: disable clearmem in windows x86 emulator. bochs_display_setup: return error on failure pmm: use tmp zone on oom vgasrc: add allocate_pmm() qemu: add qemu ramfb support cbvga_set_mode: refine clear display logic pretty boot menu entry for cdrom drives Nikolay Nikolov (11): floppy: Introduce the floppy_dor_read() function floppy: Introduce floppy_dor_mask() floppy: Introduce FLOPPY_DOR_XXX constants floppy: Preserve motor and drive sel bits when resetting the floppy controller floppy: Reset the floppy motor count in floppy_drive_pio() floppy: Use timer_check() in floppy_wait_irq() floppy: hold the DOR reset bit low for 4 microseconds, when resetting floppy: Execute a SPECIFY command after sensing the media type floppy: Support up to 4 floppy drives when turning on the floppy motor floppy: Wait for the floppy motor to reach a stable speed, after starting floppy: Send 4 sense interrupt commands during controller initialization Kevin O'Connor (10): docs: Add sercon-port to Runtime_config.md documentation paravirt: Only enable sercon in NOGRAPHIC mode if no other console specified shadow: Don't invoke a shutdown on reboot unless in a reboot loop build: Use git describe --always docs: Update Download.md to use git clone via https ssdt: Fix building of legacy acpi tables on current iasl compiler docs: Update download file link sdcard: Increase SDHCI_POWER_ON_TIME to 5ms shadow: Rework bios copy code to prevent gcc array-bounds warning docs: Note v1.12.0 release Stefan Berger (5): tpm: Add support for TPM2 ACPI table tpm: Wait for tpmRegValidSts flag on CRB interface before probing tpm: revert return values for successful/failed CRB probing tpm: when CRB is active, select, lock it, and check addresses tpm: Request access to locality 0 Marc-André Lureau (4): x86: add readq() tpm: generalize init_timeout() tpm: use get_tpm_version() callback tpm: add TPM CRB device support Jing Liu (3): pci: fix the return value for truncated capability pci: clean up the debug message for pci capability found pci: recognize RH PCI legacy bridge resource reservation capability Stephen Douthit (3): tpm: Refactor duplicated wait code in tis_wait_sts() & crb_wait_reg() tpm: Wait for interface startup when probing tpm: Handle unimplemented TIS_REG_IFACE_ID in tis_get_tpm_version() Matt DeVillier (2): nvme: fix I/O queue length calculation overflow SeaVGABios/cbvga: Fix bpp for coreboot framebuffer Marcel Apfelbaum (1): pci: fix 'io hints' capability for RedHat PCI bridges Paul Menzel (1): docs/Download: Use more secure HTTPS URLs where possible Shmuel Eiderman (1): pvscsi: Scan all 64 possible targets

1 0

Re: [SeaBIOS] [PATCH] ramdisk: search for all available floppy images instead of one
by Kevin O'Connor 17 Nov '18

17 Nov '18

On Sun, Nov 11, 2018 at 02:12:09AM +0300, Mike Banon wrote: > > However I'm concerned that this would reserve memory for all > > of the floppy images in the e820 map (and thus the final OS > > would not be able to use that memory). > > sorry Kevin I'm not fully understanding the consequences. Would > reserving e820 memory for all the floppies - result in a slightly > lower amount of available RAM to OS (e.g. just 14 MB lower if I add 10 > floppies) or there could be more serious problems? Just the loss of 14MB of ram. It seems odd to reserve that ram when I expect one would rarely use it. Arguably, seabios shouldn't reserve even 1.4MB of ram if one isn't actually booting from the given image, but extending this to every image found when most wouldn't even be accessible seems even worse. >When I've been > testing this patch - together with "35 boot menu entries" patch by > Ivan - https://mail.coreboot.org/pipermail/seabios/2017-June/011416.html > - I added about 30 floppies and everything seemed to work perfectly. > If there are no other possible problems, I am okay with slightly lower > amount of RAM - and only the "multiple floppies" users will be > affected. Also, what's good about this patch is that its' only a small > change for SeaBIOS source code - mostly placing the "floppy searching" > code inside the "for" cycle. But I could try to do something with the > allocation part if that wouldn't turn out too difficult Okay, thanks. We're planning to make a SeaBIOS release in a few days and this change would be post release anyway. -Kevin

2 1

Re: [SeaBIOS] [Qemu-devel] SeaBIOS booting time optimization
by Stefan Hajnoczi 17 Nov '18

17 Nov '18

On Fri, Nov 16, 2018 at 4:21 PM Stefano Garzarella <sgarzare(a)redhat.com> wrote: > I'm investigating the SeaBIOS booting time, to understand if we can reduce > the boot time in some cases (e.g. legacy hardware is not needed). I think > this > can be interesting also for NEMU developers. Questions for NEMU folks: qboot isn't part of the virt-x86 NEMU tree and is only mentioned in one or two places. Is NEMU focussing exclusively on OVMF guest firmware instead of qboot? Are there other boot time optimizations in NEMU that are a candidate for upstreaming? Stefan

1 0

SeaBIOS booting time optimization
by Stefano Garzarella 17 Nov '18

17 Nov '18

Hi, I'm investigating the SeaBIOS booting time, to understand if we can reduce the boot time in some cases (e.g. legacy hardware is not needed). I think this can be interesting also for NEMU developers. Following this thread ( https://mail.coreboot.org/pipermail/seabios/2015-July/009497.html), I'm using qboot (https://github.com/bonzini/qboot) to compare the SeaBIOS booting time. As Paolo did in qboot, I manually add small debug port writes in SeaBIOS and linuxboot_dma.c (QEMU) to trace the events with perf (kvm_pio events) The goal is to have only one image of SeaBIOS configurable at runtime to reduce the boot time, avoiding unnecessary initialization. Any pointers or suggestions would be helpful. Following I put some preliminary measurements that I obtained: I used this QEMU command line: ./qemu-system-x86_64 -bios $BIOS -m 1G -cpu host -M accel=kvm \ -kernel /boot/vmlinuz-4.18.18-300.fc29.x86_64 -append 'console=ttyS0' \ -nographic -serial mon:stdio For each test, I measured these times (in milliseconds) relative to the "sched_process_exec" event: - qemu_init_end: first kvm_entry (i.e. QEMU initialized has finished) - fw_start: first entry of the BIOS - fw_do_boot: after the BIOS initialization (e.g. PCI setup, etc.) - linux_start_boot: before the jump to the Linux kernel # qboot BIOS=/home/stefano/repos/qboot/bios.bin qemu_init_end: 40.561234 fw_start: 40.721729 (+0.160495) fw_do_boot: 47.025591 (+6.303862) linux_start_boot: 48.874112 (+1.848521) # SeaBIOS with default configuration BIOS=/home/stefano/repos/seabios/out_default/bios.bin qemu_init_end: 40.419451 fw_start: 40.639967 (+0.220516) fw_do_boot: 886.668828 (+846.028861) linux_start_boot: 889.723547 (+3.054719) # SeaBIOS with Kevin's configuration # (https://mail.coreboot.org/pipermail/seabios/2015-July/009508.html) # Note: this SeaBIOS setup is so stripped down that it can't actually boot an OS BIOS=/home/stefano/repos/seabios/out_kevin/bios.bin qemu_init_end: 40.676412 fw_start: 40.755757 (+0.079345) fw_do_boot: 56.427023 (+15.671266) I did the same tests also with NEMU (without using -M virt) and I have approximately the same results. As the next step, I'll start from Kevin's configuration to have a minimal SeaBIOS image ables to boot a Linux kernel. Thanks, Stefano -- Stefano Garzarella Red Hat

1 0

Re: [SeaBIOS] [PATCH] ramdisk: search for all available floppy images instead of one
by Kevin O'Connor 11 Nov '18

11 Nov '18

On Fri, Nov 02, 2018 at 01:07:20AM +0300, Mike Banon wrote: > All the floppy images available at CBFS will be found and listed in a > boot menu, instead of the first found. Could be highly valuable if you > are participating in a hobby OS development - would like to test > multiple versions of your floppy in the same coreboot image, to reduce > the amount of re-flashes and accelerate the development at bare metal > - or simply would like to access multiple floppies as a coreboot user; > for example: KolibriOS (nice assembly OS with GUI), FreeDOS, Visopsys > and memtest (coreboot's own memtest version is a bit buggy, e.g. > external USB keyboard isn't working there at some laptops) Thanks. However I'm concerned that this would reserve memory for all of the floppy images in the e820 map (and thus the final OS would not be able to use that memory). I think if multiple floppy support was desired then we'd want to delay memory reservation until after a particular image was selected in the boot menu. -Kevin

2 1

[PATCH] coreboot: update memory table before handling execution to payload/system
by Krystian Hebel 11 Nov '18

11 Nov '18

SeaBIOS modifies its internal e820 structure, but does not propagate these changes back to coreboot tables. This resulted in multiple errors in MemTest86 when run on 2 GB platforms, probably because of some memory-mapped devices. This patch copies back modified e820 tables before booting an OS or a payload. Change-Id: I16a3f059695717daedb1e997ce4e62018c7e02b3 Signed-off-by: Krystian Hebel <krystian.hebel(a)3mdeb.com> --- src/e820map.c | 2 ++ src/e820map.h | 2 ++ src/fw/coreboot.c | 50 +++++++++++++++++++++++++++++++++++++++++++---- 3 files changed, 50 insertions(+), 4 deletions(-) diff --git a/src/e820map.c b/src/e820map.c index 39445cf6399d..2d2de6094b14 100644 --- a/src/e820map.c +++ b/src/e820map.c @@ -148,5 +148,7 @@ e820_remove(u64 start, u64 size) void e820_prepboot(void) { + // Synchronize memory maps. + coreboot_update_memtable(); dump_map(); } diff --git a/src/e820map.h b/src/e820map.h index de8b523003c5..78bf1ce76572 100644 --- a/src/e820map.h +++ b/src/e820map.h @@ -23,4 +23,6 @@ void e820_prepboot(void); extern struct e820entry e820_list[]; extern int e820_count; +extern void coreboot_update_memtable(void); + #endif // e820map.h diff --git a/src/fw/coreboot.c b/src/fw/coreboot.c index 7c0954b5398c..aa07baad3a7f 100644 --- a/src/fw/coreboot.c +++ b/src/fw/coreboot.c @@ -189,10 +189,6 @@ coreboot_preinit(void) e820_add(m->start, m->size, type); } - // Ughh - coreboot likes to set a map at 0x0000-0x1000, but this - // confuses grub. So, override it. - e820_add(0, 16*1024, E820_RAM); - struct cb_cbmem_ref *cbref = find_cb_subtable(cbh, CB_TAG_CBMEM_CONSOLE); if (cbref) { cbcon = (void*)(u32)cbref->cbmem_addr; @@ -567,3 +563,49 @@ cbfs_payload_setup(void) boot_add_cbfs(cfile->fhdr, desc, bootprio_find_named_rom(filename, 0)); } } + +// Mirror changes done on e820 to coreboot tables. +void +coreboot_update_memtable(void) +{ + if (!CONFIG_COREBOOT) + return; + + // Find coreboot table. + struct cb_header *cbh = find_cb_table(); + if (!cbh) { + dprintf(1, "Unable to find coreboot table!\n"); + return; + } + char *end = (char *)cbh + sizeof(*cbh) + cbh->table_bytes; + dprintf(3, "Now attempting to find coreboot memory map\n"); + struct cb_memory *dst = find_cb_subtable(cbh, CB_TAG_MEMORY); + if (!dst) { + dprintf(1, "Unable to find coreboot memory table!\n"); + return; + } + + // Remove old memory table, overwriting it with following subtables + // and append an updated memory table to the end. + u32 old_size = dst->size; + char *src = (char *)dst + old_size; + memcpy(dst, src, (end - src)); + dst = (struct cb_memory *)(end - old_size); + u32 new_size = e820_count * sizeof(struct e820entry); + dst->tag = CB_TAG_MEMORY; + // Tables are binary compatible, except that CB_MEM_TABLE became + // E820_RESERVED. + memcpy((char*)dst + sizeof(struct cb_memory), e820_list, new_size); + new_size += sizeof(struct cb_memory); + dst->size = new_size; + + // Update header fields (size and checksum). + cbh->table_bytes += new_size - old_size; + cbh->table_checksum = ipchksum((char*)cbh + sizeof(*cbh), cbh->table_bytes); + cbh->header_checksum = 0; + cbh->header_checksum = ipchksum((char*)cbh, sizeof(*cbh)); + + // Ughh - coreboot likes to set a map at 0x0000-0x1000, but this + // confuses grub. So, override it in e820 only. + e820_add(0, 16*1024, E820_RAM); +} -- 2.17.1

4 5

[PATCH] shadow: Rework bios copy code to prevent gcc array-bounds warning
by Kevin O'Connor 11 Nov '18

11 Nov '18

Signed-off-by: Kevin O'Connor <kevin(a)koconnor.net> --- src/fw/shadow.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/src/fw/shadow.c b/src/fw/shadow.c index 987eaf4..4c627a8 100644 --- a/src/fw/shadow.c +++ b/src/fw/shadow.c @@ -173,9 +173,9 @@ qemu_reboot(void) return; // QEMU doesn't map 0xc0000-0xfffff back to the original rom on a // reset, so do that manually before invoking a hard reset. - void *cstart = VSYMBOL(code32flat_start), *cend = VSYMBOL(code32flat_end); - void *hrp = &HaveRunPost; - if (readl(hrp + BIOS_SRC_OFFSET)) { + void *flash = (void*)BIOS_SRC_OFFSET; + u32 hrp = (u32)&HaveRunPost; + if (readl(flash + hrp)) { // There isn't a pristine copy of the BIOS at 0xffff0000 to copy if (HaveRunPost == 3) { // In a reboot loop. Try to shutdown the machine instead. @@ -187,8 +187,9 @@ qemu_reboot(void) } else { // Copy the BIOS making sure to only reset HaveRunPost at end make_bios_writable(); - memcpy(cstart, cstart + BIOS_SRC_OFFSET, hrp - cstart); - memcpy(hrp + 4, hrp + 4 + BIOS_SRC_OFFSET, cend - (hrp + 4)); + u32 cstart = SYMBOL(code32flat_start), cend = SYMBOL(code32flat_end); + memcpy((void*)cstart, flash + cstart, hrp - cstart); + memcpy((void*)hrp + 4, flash + hrp + 4, cend - (hrp + 4)); barrier(); HaveRunPost = 0; barrier(); -- 2.17.2

1 0

[PATCH] pvscsi: Scan all 64 possible targets
by Shmuel Eiderman 11 Nov '18

11 Nov '18

The max number of targets per PVSCSI controller is 64, not 7. This can easily be seen in QEMU PVSCSI emulation code (hw/scsi/vmw_pvscsi.c) as PVSCSI_MAX_DEVS, which defines the number of targets, have value of 64. Fixes: 83d60b3c474b ("Add pvscsi boot support") Reviewed-by: Liran Alon <liran.alon(a)oracle.com> Reviewed-by: Mark Kanda <mark.kanda(a)oracle.com> Signed-off-by: Shmuel Eiderman <shmuel.eiderman(a)oracle.com> --- src/hw/pvscsi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/hw/pvscsi.c b/src/hw/pvscsi.c index d62d0a0..e0ea33c 100644 --- a/src/hw/pvscsi.c +++ b/src/hw/pvscsi.c @@ -310,7 +310,7 @@ init_pvscsi(void *data) struct pvscsi_ring_dsc_s *ring_dsc = NULL; pvscsi_init_rings(iobase, &ring_dsc); int i; - for (i = 0; i < 7; i++) + for (i = 0; i < 64; i++) pvscsi_scan_target(pci, iobase, ring_dsc, i); } -- 2.16.1

2 1

[PATCH] ramdisk: search for all available floppy images instead of one
by Mike Banon 02 Nov '18

02 Nov '18

All the floppy images available at CBFS will be found and listed in a boot menu, instead of the first found. Could be highly valuable if you are participating in a hobby OS development - would like to test multiple versions of your floppy in the same coreboot image, to reduce the amount of re-flashes and accelerate the development at bare metal - or simply would like to access multiple floppies as a coreboot user; for example: KolibriOS (nice assembly OS with GUI), FreeDOS, Visopsys and memtest (coreboot's own memtest version is a bit buggy, e.g. external USB keyboard isn't working there at some laptops) Shortened patch description message: All the available floppy images will be found and listed in a boot menu, instead of the first found. Useful if you are participating in a hobby OS development or would like to access multiple floppies as a coreboot user. Signed-off-by: Mike Banon <mikebdp2(a)gmail.com> --- diff --git a/src/hw/ramdisk.c b/src/hw/ramdisk.c index b9e9baa..0cd8470 100644 --- a/src/hw/ramdisk.c +++ b/src/hw/ramdisk.c @@ -23,40 +23,51 @@ ramdisk_setup(void) if (!CONFIG_FLASH_FLOPPY) return; + struct romfile_s *file = NULL; + char *filename, *desc; + u32 size; + int ftype, ret; + void *pos; + struct drive_s *drive; + + for (;;) { + - // Find image. - struct romfile_s *file = romfile_findprefix("floppyimg/", NULL); - if (!file) - return; + // Find the next image. + file = romfile_findprefix("floppyimg/", file); + if (!file) + return; - const char *filename = file->name; - u32 size = file->size; - dprintf(3, "Found floppy file %s of size %d\n", filename, size); - int ftype = find_floppy_type(size); - if (ftype < 0) { - dprintf(3, "No floppy type found for ramdisk size\n"); - return; - } + filename = file->name; + size = file->size; + dprintf(3, "Found floppy file %s of size %d\n", filename, size); + ftype = find_floppy_type(size); + if (ftype < 0) { + dprintf(3, "No floppy type found for ramdisk size\n"); + return; + } - // Allocate ram for image. - void *pos = memalign_tmphigh(PAGE_SIZE, size); - if (!pos) { - warn_noalloc(); - return; - } - e820_add((u32)pos, size, E820_RESERVED); + // Allocate ram for image. + pos = memalign_tmphigh(PAGE_SIZE, size); + if (!pos) { + warn_noalloc(); + return; + } + e820_add((u32)pos, size, E820_RESERVED); - // Copy image into ram. - int ret = file->copy(file, pos, size); - if (ret < 0) - return; + // Copy image into ram. + ret = file->copy(file, pos, size); + if (ret < 0) + return; - // Setup driver. - struct drive_s *drive = init_floppy((u32)pos, ftype); - if (!drive) - return; + // Setup driver. + drive = init_floppy((u32)pos, ftype); + if (!drive) + return; - drive->type = DTYPE_RAMDISK; - dprintf(1, "Mapping floppy %s to addr %p\n", filename, pos); - char *desc = znprintf(MAXDESCSIZE, "Ramdisk [%s]", &filename[10]); - boot_add_floppy(drive, desc, bootprio_find_named_rom(filename, 0)); + drive->type = DTYPE_RAMDISK; + dprintf(1, "Mapping floppy %s to addr %p\n", filename, pos); + desc = znprintf(MAXDESCSIZE, "Ramdisk [%s]", &filename[10]); + boot_add_floppy(drive, desc, bootprio_find_named_rom(filename, 0)); + + } } static int

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS