SeaBIOS

seabios@seabios.org

3783 discussions

Re: [SeaBIOS] [PATCH v2] qemu: fast boot when linuxboot optionrom is used
by Kevin O'Connor 29 Nov '18

29 Nov '18

On Wed, Nov 28, 2018 at 12:30:42PM +0100, Stefano Garzarella wrote: > On Wed, Nov 28, 2018 at 3:12 AM Kevin O'Connor <kevin(a)koconnor.net> wrote: > > On Mon, Nov 26, 2018 at 12:39:12PM +0100, Stefano Garzarella 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. > > > > > > Following the time measured between SeaBIOS entry point and > > > "linuxboot" entry point: > > > > > > * Before this patch > > > qemu -kernel | qemu -vga none -kernel > > > --------------+----------------------- > > > 53.5 msec | 23.34 msec > > > > > > * After this patch > > > qemu -kernel | qemu -vga none -kernel > > > --------------+----------------------- > > > 12.82 msec | 10.89 msec > > > > > > Note: For the measuring, we used the default configuration disabling > > > debug messages (CONFIG_DEBUG_LEVEL=0) and applying Stephen's patch: > > > "tpm: Check for TPM related ACPI tables before attempting hw" > > > > > > 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; > > > + } > > > > I don't think we should hardcode special meanings to the names of > > bootable files. If QEMU wants SeaBIOS to not perform some type of > > hardware init, then I think QEMU should explicitly request that from > > SeaBIOS (eg, a "etc/dont-run-hardware-init"). > > I agree, it is cleaner. That was one of my doubt but, with an explicit > request, it works only with a new version of QEMU. > Do you think is acceptable? It would be good to understand what the source of the delay is. It might be possible to avoid the delay without adding a new config setting. For example, the patch above will prevent the vga rom from being run, but it should be possible to accomplish the same with "-device VGA,romfile=". The other change this patch makes is to skip device_hardware_setup() - is it known which items in that function add to the delay? Also, what is the target boot time that is considered acceptable? Thanks, -Kevin

2 1

[PATCH] SMBIOS: Add SMBIOS Type 6 Memory Module Information
by Liran Alon 29 Nov '18

29 Nov '18

From: Arbel Moshe <arbel.moshe(a)oracle.com> Add support for obsolete SMBIOS Type 6 which describes the speed, type, size and error status of each system memory module. This is required by some guests to boot successfully. Such an example is Cisco NGFW appliance which has a script which runs every boot that parses this SMBIOS Type 6 information and if it doesn't exists, it just fails to boot with an error of "Unable to parse dmidecode. Restarting now!". Reviewed-by: Liran Alon <liran.alon(a)oracle.com> Reviewed-by: Ross Philipson <ross.philipson(a)oracle.com> Signed-off-by: Arbel Moshe <arbel.moshe(a)oracle.com> --- src/fw/smbios.c | 46 ++++++++++++++++++++++++++++++++++++++++++++++ src/std/smbios.h | 12 ++++++++++++ 2 files changed, 58 insertions(+) diff --git a/src/fw/smbios.c b/src/fw/smbios.c index f3b5ad9dd9a0..751ae98f0fc4 100644 --- a/src/fw/smbios.c +++ b/src/fw/smbios.c @@ -348,6 +348,51 @@ smbios_init_type_4(void *start, unsigned int cpu_number) return end; } +/* Type 6 -- Memory Module Information */ +static void * +smbios_init_type_6(void *start, u32 size_mb, int instance) +{ + struct smbios_type_6 *p = (struct smbios_type_6 *)start; + char *end = (char *)start + sizeof(struct smbios_type_6); + u8 size_mem = 0; + char name[1024]; + int str_index = 0; + + p->header.type = 6; + p->header.length = sizeof(struct smbios_type_6); + p->header.handle = 0x600 + instance; + + snprintf(name, sizeof(name), "RAM socket #%2x", instance); + + memcpy(end, name, strlen(name) + 1); + end += strlen(name) + 1; + p->socket_designation_str = ++str_index; + + set_field_with_default(6, bank_connection, 0xff); /* No connection */ + set_field_with_default(6, current_speed, 0); /* Unknown Speed */ + set_field_with_default(6, memory_type, 0x400); /* SDRAM */ + + /* size_mem = n, where 2**n = size_mb */ + size_mb = size_mb >> 1; + while (size_mb) { + ++size_mem; + size_mb = size_mb >> 1; + } + + p->installed_size = size_mem; + p->enabled_size = size_mem; + set_field_with_default(6, error_status, 0); + + *end = 0; + end++; + if (!str_index) { + *end = 0; + end++; + } + + return end; +} + /* Type 16 -- Physical Memory Array */ static void * smbios_init_type_16(void *start, u32 memory_size_mb, int nr_mem_devs) @@ -550,6 +595,7 @@ smbios_legacy_setup(void) u32 dev_mb = ((i == (nr_mem_devs - 1)) ? (((ram_mb - 1) & 0x3fff) + 1) : 16384); + add_struct(6, p, dev_mb, i); add_struct(17, p, dev_mb, i); } diff --git a/src/std/smbios.h b/src/std/smbios.h index 4ccf2ea348ee..765ac51667ed 100644 --- a/src/std/smbios.h +++ b/src/std/smbios.h @@ -100,6 +100,18 @@ struct smbios_type_4 { u16 l3_cache_handle; } PACKED; +/* SMBIOS type 6 - Memory Module Information */ +struct smbios_type_6 { + struct smbios_structure_header header; + u8 socket_designation_str; + u8 bank_connection; + u8 current_speed; + u16 memory_type; + u8 installed_size; + u8 enabled_size; + u8 error_status; +} PACKED; + /* SMBIOS type 16 - Physical Memory Array * Associated with one type 17 (Memory Device). */ -- 2.16.1

2 2

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

28 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. Following the time measured between SeaBIOS entry point and "linuxboot" entry point: * Before this patch qemu -kernel | qemu -vga none -kernel --------------+----------------------- 53.5 msec | 23.34 msec * After this patch qemu -kernel | qemu -vga none -kernel --------------+----------------------- 12.82 msec | 10.89 msec Note: For the measuring, we used the default configuration disabling debug messages (CONFIG_DEBUG_LEVEL=0) and applying Stephen's patch: "tpm: Check for TPM related ACPI tables before attempting hw" 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 2

[PATCH 0/2] Improve PVSCSI guest memory utilization
by Liran Alon 28 Nov '18

28 Nov '18

Hi, This series aims to fix an issue of booting a guest with many PVSCSI disk controllers (>=16). Currently, booting such a guest result in exhausting available memory in high-zone which leads to guest crash. The 1st patch improve PVSCSI memory consumption by removing an unnecessary contraint of allocating a page-aligned memory. The 2nd patch modifies SeaBIOS high-zone allocator to fallback to low-zone in case high-zone is exhausted. This is possible because high-zone is used only by 32-bit code which don't care if allocation is from high-zone or low-zone and just uses high-zone because it has more space. However, in case there is no more memory in high-zone, it makes sense to utilize remaining memory in low-zone to still be able to boot guest successfully. Regards, -Liran

3 10

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 26 Nov '18

26 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 25 Nov '18

25 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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS