SeaBIOS

seabios@seabios.org

3 participants
3799 discussions

Re: [SeaBIOS] [BUG?] SeaBIOS memcpy copies only 0x04 bytes instead of 0x8c
by Kevin O'Connor 28 Nov '18

28 Nov '18

On Sun, Nov 25, 2018 at 11:58:14PM +0300, Mike Banon wrote: > I am trying to copy a structure romfile_s from one location to another > by memcpy (before the booting stage), but struggling with a weird > problem. My memcpy arguments - memcpy(void *d1, const void *s1, size_t > len) : > > d1 (destination) = 0x000f4d34 > s1 (source) = 0x07f3f610 > len (size) = 0x0000008c It's hard to say without seeing the other code changes. If the memcpy was called while in real mode, then it does not have access to memory above 1Meg. There's some info on this at: https://www.seabios.org/Memory_Model -Kevin

1 0

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

28 Nov '18

On 11/20/18 11:51 AM, Stefano Garzarella wrote: > On Tue, Nov 20, 2018 at 5:13 PM Steve Douthit <stephend(a)silicom-usa.com> wrote: >> On 11/20/18 10:55 AM, Kevin O'Connor wrote: >>> On Mon, Nov 19, 2018 at 07:38:39PM +0100, Stefano Garzarella wrote: >>>> just an update, I enabled the debug prints and I saw two timeouts fired >>>> with a lot >>>> of time lost (~780ms between "init timer" and "Scan for VGA ..."), >>>> putting other prints I discovered that a lot of time is spent in the >>>> tpm_setup(), >>>> during the probe of the 2 TPM devices: >>>> >>>> 00.548869 init timer >>>> 00.549677 ./src/post.c:157 platform_hardware_setup >>>> 00.550182 ./src/hw/tpm_drivers.c:579 tpmhw_probe >>>> 01.300833 WARNING - Timeout at wait_reg8:81! >>>> 01.301388 ./src/hw/tpm_drivers.c:579 tpmhw_probe >>>> 01.331843 WARNING - Timeout at wait_reg8:81! >>>> 01.332316 ./src/post.c:160 platform_hardware_setup >>>> 01.333358 Scan for VGA option rom >>> FYI, this was raised a few months ago - see: >>> >>> https://mail.coreboot.org/pipermail/seabios/2018-March/012186.html >>> >>> IIRC, it should be possible to verify the TPM device is present before >>> trying to wait for it. >> We could skip probing entirely if there's no TCPA or TPM2 ACPI tables. >> There'd need to be some option to force probing in the case of >> missing/broken ACPI configurations. > I've just tried the > 0001-tpm-Check-for-TPM-related-ACPI-tables-before-attempt.patch > (https://mail.coreboot.org/pipermail/seabios/2018-March/012188.html) > and it solves my issue with the TPM. I have tried it with the attached patch of that mail. We have to apply it, also for QEMU. It is this patch here: From: Stephen Douthit <stephend(a)silicom-usa.com> Date: Wed, 7 Mar 2018 13:17:36 -0500 Subject: [PATCH] tpm: Check for TPM related ACPI tables before attempting hw probe Signed-off-by: Stephen Douthit <stephend(a)silicom-usa.com> --- src/tcgbios.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/src/tcgbios.c b/src/tcgbios.c index 40b3028..24846d3 100644 --- a/src/tcgbios.c +++ b/src/tcgbios.c @@ -968,6 +968,13 @@ tpm_setup(void) if (!CONFIG_TCGBIOS) return; + int ret = tpm_tpm2_probe(); + if (ret) { + ret = tpm_tcpa_probe(); + if (ret) + return; + } + TPM_version = tpmhw_probe(); if (TPM_version == TPM_VERSION_NONE) return; @@ -976,13 +983,6 @@ tpm_setup(void) "TCGBIOS: Detected a TPM %s.\n", (TPM_version == TPM_VERSION_1_2) ? "1.2" : "2"); - int ret = tpm_tpm2_probe(); - if (ret) { - ret = tpm_tcpa_probe(); - if (ret) - return; - } - TPM_working = 1; if (runningOnXen()) -- 2.14.3 > > Thanks, > Stefano > >>> -Kevin >>> >

2 1

Re: [SeaBIOS] [PATCH] qemu: fast boot when linuxboot optionrom is used
by Stefano Garzarella 26 Nov '18

26 Nov '18

On Mon, Nov 26, 2018 at 9:48 AM Stefan Hajnoczi <stefanha(a)gmail.com> wrote: > > On Fri, Nov 23, 2018 at 2:09 PM Stefano Garzarella <sgarzare(a)redhat.com> wrote: > > Speed up the boot phase when qemu uses "linuxboot" optionrom > > (qemu -kernel) and the boot-menu is not required. > > Under these conditions we can skip the setup of devices and VGA, > > because they will be initialized (if they are required) during > > the Linux boot phase. > > Please include benchmark results in the commit description so the > improvement is quantified and recorded in the commit history. Sure, I'll prepare a v2 of this patch. Thanks, Stefano > > Thanks, > Stefan -- Stefano Garzarella Red Hat

1 0

[PATCH] qemu: fast boot when linuxboot optionrom is used
by Stefano Garzarella 26 Nov '18

26 Nov '18

Speed up the boot phase when qemu uses "linuxboot" optionrom (qemu -kernel) and the boot-menu is not required. Under these conditions we can skip the setup of devices and VGA, because they will be initialized (if they are required) during the Linux boot phase. Signed-off-by: Stefano Garzarella <sgarzare(a)redhat.com> --- src/bootsplash.c | 3 +++ src/fw/paravirt.c | 10 ++++++++++ src/fw/paravirt.h | 4 ++++ src/optionroms.c | 3 ++- src/post.c | 3 +++ 5 files changed, 22 insertions(+), 1 deletion(-) diff --git a/src/bootsplash.c b/src/bootsplash.c index 165c98d..0eda7f2 100644 --- a/src/bootsplash.c +++ b/src/bootsplash.c @@ -8,6 +8,7 @@ #include "bregs.h" // struct bregs #include "config.h" // CONFIG_* #include "farptr.h" // FLATPTR_TO_SEG +#include "fw/paravirt.h" // runningOnQEMUFastBoot #include "malloc.h" // free #include "output.h" // dprintf #include "romfile.h" // romfile_loadfile @@ -39,6 +40,8 @@ call16_int10(struct bregs *br) void enable_vga_console(void) { + if(runningOnQEMUFastBoot()) + return; dprintf(1, "Turning on vga text mode console\n"); struct bregs br; diff --git a/src/fw/paravirt.c b/src/fw/paravirt.c index 0770c47..9e6e618 100644 --- a/src/fw/paravirt.c +++ b/src/fw/paravirt.c @@ -621,4 +621,14 @@ void qemu_cfg_init(void) if (nogfx && !romfile_find("etc/sercon-port") && !romfile_find("vgaroms/sgabios.bin")) const_romfile_add_int("etc/sercon-port", PORT_SERIAL1); + + /* + * Enable QEMU fast boot if there is "linuxboot" optionrom and + * the boot menu is not required. + */ + if ((romfile_find("genroms/linuxboot_dma.bin") + || romfile_find("genroms/linuxboot.bin")) + && !romfile_loadint("etc/show-boot-menu", 1)) { + PlatformRunningOn |= PF_QEMU_FB; + } } diff --git a/src/fw/paravirt.h b/src/fw/paravirt.h index a14d83e..3713bc2 100644 --- a/src/fw/paravirt.h +++ b/src/fw/paravirt.h @@ -9,6 +9,7 @@ #define PF_QEMU (1<<0) #define PF_XEN (1<<1) #define PF_KVM (1<<2) +#define PF_QEMU_FB (1<<3) typedef struct QemuCfgDmaAccess { u32 control; @@ -24,6 +25,9 @@ static inline int runningOnQEMU(void) { return CONFIG_QEMU || ( CONFIG_QEMU_HARDWARE && GET_GLOBAL(PlatformRunningOn) & PF_QEMU); } +static inline int runningOnQEMUFastBoot(void) { + return runningOnQEMU() && GET_GLOBAL(PlatformRunningOn) & PF_QEMU_FB; +} static inline int runningOnXen(void) { return CONFIG_XEN && GET_GLOBAL(PlatformRunningOn) & PF_XEN; } diff --git a/src/optionroms.c b/src/optionroms.c index fc992f6..c312e91 100644 --- a/src/optionroms.c +++ b/src/optionroms.c @@ -8,6 +8,7 @@ #include "bregs.h" // struct bregs #include "config.h" // CONFIG_* #include "farptr.h" // FLATPTR_TO_SEG +#include "fw/paravirt.h" // runningOnQEMUFastBoot #include "hw/pci.h" // pci_config_readl #include "hw/pcidevice.h" // foreachpci #include "hw/pci_ids.h" // PCI_CLASS_DISPLAY_VGA @@ -428,7 +429,7 @@ vgarom_setup(void) { int have_vga = 0; - if (! CONFIG_OPTIONROMS) + if (!CONFIG_OPTIONROMS || runningOnQEMUFastBoot()) return; dprintf(1, "Scan for VGA option rom\n"); diff --git a/src/post.c b/src/post.c index f93106a..d1c2a54 100644 --- a/src/post.c +++ b/src/post.c @@ -126,6 +126,9 @@ interface_init(void) void device_hardware_setup(void) { + if(runningOnQEMUFastBoot()) + return; + usb_setup(); ps2port_setup(); block_setup(); -- 2.19.1

2 1

[BUG?] SeaBIOS memcpy copies only 0x04 bytes instead of 0x8c
by Mike Banon 25 Nov '18

25 Nov '18

I am trying to copy a structure romfile_s from one location to another by memcpy (before the booting stage), but struggling with a weird problem. My memcpy arguments - memcpy(void *d1, const void *s1, size_t len) : d1 (destination) = 0x000f4d34 s1 (source) = 0x07f3f610 len (size) = 0x0000008c Expected results: all 0x8c bytes are copied Actual results: only the first 0x04 copied Confirmed by dprintf printing the contents after memcpy: source[0x0] = 0x07f3f6e0 || destination[0x0] = 0x07f3f6e0 source[0x4] = 0xff03a9c0 || destination[0x4] = 0x00000000 source[0x8] = 0x00000000 || destination[0x8] = 0x00000000 source[0xc] = 0x6c796170 || destination[0xc] = 0xa4908b65 source[0x10] = 0xff02f388 || destination[0x10] = 0x20525450 ... source[0x88] = 0x0ff81184 || destination[0x88] = 0xa4908b65 This code is being executed inside memcpy: (common case route) SET_SEG(ES, GET_SEG(SS)); void *d = d1; // Common case - use 4-byte copy len /= 4; asm volatile( "rep movsl (%%esi),%%es:(%%edi)" : "+c"(len), "+S"(s1), "+D"(d) : "m" (__segment_ES) : "cc", "memory"); return d1; Is there a hidden bug, or I should be using another memcpy_ function to copy from 0x07f3f610 to 0x000f4d34 , like memcpy_far ? ( however, if indeed the wrong function, why is it working for the first 0x04 bytes while shouldn't be working at all ? ) P.S. also I've tried copying it manually instead of memcpy() - by 4 bytes using for() cycle with (0x8c/4) = 23 iterations. It works but SeaBIOS quickly freezes after that, which probably means it is incorrect substitution for some reason Best regards, Mike Banon

1 0

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

24 Nov '18

Dear Kevin, Please could you tell me, why the memory allocation functions like malloc_tmphigh() are failing at do_boot() stage? (boot.c) . Because of this "VARVERIFY32INIT" problem described in my letter above - https://mail.coreboot.org/pipermail/seabios/2018-November/012575.html - I rewrote all my code to allocate the RAM for one floppy only (space equal to max floppy size, which could be used by any selected floppy) . But when I'm trying to boot that selected floppy - it is failing, because these floppies are LZMA compressed inside CBFS and to decompress them another malloc_tmphigh() is needed (from cbfs_copyfile() / coreboot.c) / Although this code compiles fine (no VARVERIFY32INIT problem) - this malloc_tmphigh() function is always failing and SeaBIOS is freezing. Spent all my weekend debugging this problem and really stuck, any help will be highly appreciated Best regards, Mike Banon On Sat, Nov 17, 2018 at 2:30 AM Mike Banon <mikebdp2(a)gmail.com> wrote: > > Thank you very much for clarifying, Kevin. I finally moved this ram > allocation to do_boot function (line 800) at boot.c - after the > printf("Booting from Floppy...\n") - but sadly it seems that > memalign_tmphigh and similar malloc'ing functions (like > malloc_tmphigh) are not allowed at this stage: > > ERROR: .data.varinit.. is VARVERIFY32INIT but used from > ['.text.runtime..', '.text.do_boot', '.text.malloc_tmphigh'] > Makefile:162: recipe for target 'out/romlayout16.lds' failed > make[2]: *** [out/romlayout16.lds] Error 1 > > I can't understand this cryptic error, and especially why it's > happening with "malloc functions" at do_boot while they're working > fine at loadBootOrder function from the same boot.c file (line 50) : > Bootorder = malloc_tmphigh(BootorderCount*sizeof(char*)); Out of > curiosity I tried restoring do_boot to its' original state then > inserted this line of code there ( Bootorder and BootorderCount are > globally declared ) and got a similar error. > > Is it true that malloc'ing during the do_boot is impossible (why?) - > and, if yes, what are the possible workarounds? Maybe I could rewrite > it to leave a single "malloc_tmphigh" inside ramdisk_setup / ramdisk.c > for the size of largest floppy (will look through the floppies at CBFS > and find the largest one) and use this allocated RAM space for any > floppy that would be selected later. <--- This way I would allocate > just 1.4MB if there are 10 * 1.4M floppies and should be less code > changes > On Tue, Nov 13, 2018 at 9:06 PM Kevin O'Connor <kevin(a)koconnor.net> wrote: > > > > 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

1 0

Re: [SeaBIOS] [Qemu-devel] SeaBIOS booting time optimization
by Kevin O'Connor 23 Nov '18

23 Nov '18

On Fri, Nov 23, 2018 at 12:18:13PM +0100, Stefano Garzarella wrote: > On Fri, Nov 23, 2018 at 7:21 AM Gerd Hoffmann <kraxel(a)redhat.com> wrote: > > On Thu, Nov 22, 2018 at 04:13:38PM +0100, Stefano Garzarella wrote: > > > On Thu, Nov 22, 2018 at 12:51 PM Gerd Hoffmann <kraxel(a)redhat.com> wrote: > > > > On Thu, Nov 22, 2018 at 12:08:55PM +0100, Stefano Garzarella wrote: > > > > > Hi, > > > > > I continued to investigate how to reduce the boot time with SeaBIOS > > > > > and QEMU when it used with linuxboot_dma.bin (-kernel parameter). > > > > > I reached ~12ms with a SeaBIOS configuration (attached) where I > > > > > disabled debug output, all Hardware support (except SMM & MTRRs) and I > > > > > applied a small patch to disable VGA setup and console (attached). > > > > > > > > Is there any difference to "qemu -vga none" ? > > > > > > Using both (qemu -vga none, and my patch) we are around 10.8 ms. > > > Note: using only the patch, Linux is still able to initialize and use the VGA. > > > > But do you want linux use the vga console if you care about boot times? > > I'd expect virtio-console would be fastest in that case. > > I agree with you, but if we will implement a QEMU fastboot feature in > SeaBIOS, we are sure that it works with Linux kernel if someone uses > "qemu -kernel" and wants also use a VGA. It should be possible to use "-device VGA,romfile=" to enable VGA without an optionrom. > > > - QEMU -vga none + SeaBIOS config (CONFIG_DEBUG_LEVEL=0, disable all > > > HW support except > > > SMM & MTRRs) + Stephen's TPM patch > > > qemu_init_end: 43.675803 > > > fw_start: 43.865178 (+0.189375) > > > fw_do_boot: 58.093161 (+14.227983) > > > linux_start_boot: 59.490308 (+1.397147) > > > linux_start_user: 556.782354 (+497.292046) > > > > > > - QEMU -vga none + SeaBIOS config (CONFIG_DEBUG_LEVEL=0, disable all > > > HW support except > > > SMM & MTRRs, CONFIG_DISABLE_VGA=y) + Stephen's TPM patch > > > qemu_init_end: 42.387412 > > > fw_start: 42.579257 (+0.191845) > > > fw_do_boot: 53.381517 (+10.802260) > > > linux_start_boot: 54.848643 (+1.467126) > > > linux_start_user: 498.517050 (+443.668407) > > > > Interesting that CONFIG_DISABLE_VGA=y makes a noticable difference even > > without vga hardware being preset. And not only in seabios but also for > > the linux kernel. > > > > Do you know why? > > In SeaBIOS I think the reasons are: > - vgarom_setup() scan all PCI devices to find a VGA > - enable_vga_console() invokes an int10 without check if there is a > VGA (maybe here we can add a check) Where is CONFIG_DISABLE_VGA set - it's not a standard SeaBIOS config option? In my experience, the only meaningful delays are the result of accessing hardware. Neither of the above two items would result in additional hardware accesses, so I don't think they would be the cause of an additional delay. -Kevin

2 1

Re: [SeaBIOS] [Qemu-devel] SeaBIOS booting time optimization
by Gerd Hoffmann 23 Nov '18

23 Nov '18

On Thu, Nov 22, 2018 at 04:13:38PM +0100, Stefano Garzarella wrote: > On Thu, Nov 22, 2018 at 12:51 PM Gerd Hoffmann <kraxel(a)redhat.com> wrote: > > > > On Thu, Nov 22, 2018 at 12:08:55PM +0100, Stefano Garzarella wrote: > > > Hi, > > > I continued to investigate how to reduce the boot time with SeaBIOS > > > and QEMU when it used with linuxboot_dma.bin (-kernel parameter). > > > I reached ~12ms with a SeaBIOS configuration (attached) where I > > > disabled debug output, all Hardware support (except SMM & MTRRs) and I > > > applied a small patch to disable VGA setup and console (attached). > > > > Is there any difference to "qemu -vga none" ? > > Using both (qemu -vga none, and my patch) we are around 10.8 ms. > Note: using only the patch, Linux is still able to initialize and use the VGA. But do you want linux use the vga console if you care about boot times? I'd expect virtio-console would be fastest in that case. > - QEMU -vga none + SeaBIOS config (CONFIG_DEBUG_LEVEL=0, disable all > HW support except > SMM & MTRRs) + Stephen's TPM patch > qemu_init_end: 43.675803 > fw_start: 43.865178 (+0.189375) > fw_do_boot: 58.093161 (+14.227983) > linux_start_boot: 59.490308 (+1.397147) > linux_start_user: 556.782354 (+497.292046) > > - QEMU -vga none + SeaBIOS config (CONFIG_DEBUG_LEVEL=0, disable all > HW support except > SMM & MTRRs, CONFIG_DISABLE_VGA=y) + Stephen's TPM patch > qemu_init_end: 42.387412 > fw_start: 42.579257 (+0.191845) > fw_do_boot: 53.381517 (+10.802260) > linux_start_boot: 54.848643 (+1.467126) > linux_start_user: 498.517050 (+443.668407) Interesting that CONFIG_DISABLE_VGA=y makes a noticable difference even without vga hardware being preset. And not only in seabios but also for the linux kernel. Do you know why? cheers, Gerd

2 1

Enable vga_console later during startup
by Julian Sparber 23 Nov '18

23 Nov '18

Hi to all, During boot Seabios shows some text including the version number on top of the screen for a couple of seconds before switching to the boot splash. It doesn't happen every time, but it is really annoying when it does because it makes the boot much less fluid. I fixed this by enabling the vga_console later during the startup. I attached a patch to this email. I tried it in qemu and on my laptop. Let me know what you think. Cheers, jsparber

2 1

Re: [SeaBIOS] [Qemu-devel] SeaBIOS booting time optimization
by Gerd Hoffmann 22 Nov '18

22 Nov '18

On Thu, Nov 22, 2018 at 12:08:55PM +0100, Stefano Garzarella wrote: > Hi, > I continued to investigate how to reduce the boot time with SeaBIOS > and QEMU when it used with linuxboot_dma.bin (-kernel parameter). > I reached ~12ms with a SeaBIOS configuration (attached) where I > disabled debug output, all Hardware support (except SMM & MTRRs) and I > applied a small patch to disable VGA setup and console (attached). Is there any difference to "qemu -vga none" ? > Samuel, I put also the total time to userspace (linux_start_user) > adding a probe in the kernel_init() and when I disabled the VGA in the > SeaBIOS I noticed also a speed up in the kernel boot phase. Might come from linux 16bit boot code scanning vgabios for available video modes (for vga=<mode> cmdline arg). > Another approach that I tried, obtaining similar results, is to > recognize the linuxboot_dma.bin at runtime, then skip > device_hardware_setup(), enable_vga_console(), and vgarom_setup(). Hmm, tricky. linuxboot_dma.bin just registers a boot entry, so with "qemu -kernel -boot menu=on" you can still get a boot menu, and the direkt kernel boot is one menu item there. So you can't know for sure whenever a direct kernel boot will happen or not. So, I think at minimum we should make this depend on both linuxboot_dma and boot menu disabled. cheers, Gerd

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS