SeaBIOS February 2017

seabios@seabios.org

15 participants
37 discussions

Re: [SeaBIOS] [coreboot] How does SeaBIOS transition to Linux?
by Zoran Stojsavljevic 13 Feb '17

13 Feb '17

Hello Peter, Did not understand... I must admit! As of my best interpretation SeaBIOS has 5 functions which makes BIOS legacy: get and set variables, get and set real time clock, reset. Or maybe, something changed. I went back, to inspect CSM code in SeaBIOS, and found the following: # # General Features # # CONFIG_COREBOOT is not set # CONFIG_QEMU is not set *CONFIG_CSM=y <<==================== set CSM ON* # CONFIG_QEMU_HARDWARE is not set CONFIG_THREADS=y CONFIG_RELOCATE_INIT=y CONFIG_BOOTMENU=y CONFIG_BOOTSPLASH=y CONFIG_BOOTORDER=y CONFIG_ENTRY_EXTRASTACK=y CONFIG_MALLOC_UPPERMEMORY=y CONFIG_ROM_SIZE=0 Then make: Compile checking out/src/hw/pcidevice.o Compile checking out/src/hw/ahci.o Compile checking out/src/hw/pvscsi.o Compile checking out/src/hw/usb-xhci.o Compile checking out/src/hw/usb-hub.o Compile checking out/src/hw/sdcard.o Compile checking out/src/fw/coreboot.o Compile checking out/src/fw/lzmadecode.o Compile checking out/src/fw/multiboot.o *Compile checking out/src/fw/csm.o* Compile checking out/src/fw/biostables.o Compile checking out/src/fw/paravirt.o Compile checking out/src/fw/shadow.o Compile checking out/src/fw/pciinit.o Compile checking out/src/fw/smm.o Compile checking out/src/fw/smp.o Compile checking out/src/fw/mtrr.o Compile checking out/src/fw/xen.o Compile checking out/src/fw/acpi.o Compile checking out/src/fw/mptable.o Compile checking out/src/fw/pirtable.o Compile checking out/src/fw/smbios.o Where I see e820 table which is to be passed to OS, in order OS to understand what memory it can use. But I did not find explicitly these 5 functions. So I need a little help here. Where are these functions? Now... How GRUB2 replaces all of these functionalities? I see what you said here (that GRUB2 is directly implemented into FW, thus skipping MBR), but who/what entity is replacing missing SeaBIOS functionalities? Thank you, Zoran On Sat, Feb 11, 2017 at 2:18 PM, Peter Stuge <peter(a)stuge.se> wrote: > Zoran Stojsavljevic wrote: > > crucial question from me: how Coreboot will work if instead SeaBIOS > > GRUB2 is the payload chosen > > Instead of SeaBIOS reading MBR, GRUB2 will read its configuration > file and operate accordingly. > > > //Peter > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot >

1 0

coreboot and `Timeout at i8042_flush:71!`
by Paul Menzel 11 Feb '17

11 Feb '17

Dear SeaBIOS folks, coreboots board status repository has some SeaBIOS warnings, and I believe the keyboard doesn’t work in that case. ``` $ git grep 'Timeout at i8042_flush' origin/master -- origin/master:amd/lamar/4.0-9540-gae5ab60/2015-04-30T02:12:19Z/coreboot_console.txt:WARNING - Timeout at i8042_flush:71! origin/master:amd/olivehill/4.0-7005-gb9a0809/2014-10-08T13:44:17Z/coreboot_console.txt:WARNING - Timeout at i8042_flush:71! origin/master:amd/olivehillplus/4.0-6942-g4177db5/2014-09-19T19:38:48Z/coreboot_console.txt:WARNING - Timeout at i8042_flush:71! origin/master:amd/thatcher/4.3-102-g380e167/2016-02-04T18_30_40Z/coreboot_console.txt:WARNING - Timeout at i8042_flush:71! origin/master:aopen/dxplplusu/4.5-485-g52896c6/2016-12-04T02_03_58Z/coreboot_console.txt:WARNING - Timeout at i8042_flush:71! origin/master:gizmosphere/gizmo/4.0-9564-g58649b0/2015-05-03T07:14:33Z/coreboot_console.txt:WARNING - Timeout at i8042_flush:71! origin/master:google/panther/4.0-9491-g64c7791/2015-04-23T21:31:14Z/coreboot_console.txt:WARNING - Timeout at i8042_flush:71! origin/master:google/panther/4.1-340-gb38b0f2/2015-08-25T18:38:10Z/coreboot_console.txt:WARNING - Timeout at i8042_flush:71! origin/master:google/panther/4.3-777-g4774bb9/2016-04-18T13_11_58Z/coreboot_console.txt:|7f6bc000| WARNING - Timeout at i8042_flush:71! origin/master:hp/2760p/4.5-906-g3fb6e6e-dirty/2017-01-27T03_04_14Z/coreboot_console.txt:|7feca000| WARNING - Timeout at i8042_flush:71! origin/master:hp/2760p/4.5-911-g9510156/2017-01-28T14_47_33Z/coreboot_console.txt:WARNING - Timeout at i8042_flush:71! origin/master:hp/2760p/4.5-913-g0f70fbd/2017-01-29T02_16_08Z/coreboot_console.txt:WARNING - Timeout at i8042_flush:71! origin/master:intel/bayleybay_fsp/4.0-6293-g0b4b230/2014-06-25T23:32:28Z/coreboot_console.txt:|7ba9a000| WARNING - Timeout at i8042_flush:71! origin/master:intel/minnowmax/4.2-429-g4013469/2015-11-30T20_21_41Z/coreboot_console.txt:WARNING - Timeout at i8042_flush:71! origin/master:intel/minnowmax/4.2-429-g4013469/2015-11-30T20_21_41Z/tests/cbmem-console.log:WARNING - Timeout at i8042_flush:71! origin/master:intel/minnowmax/4.5-306-g00ad7ff/2016-11-17T17_00_43Z/coreboot_console.txt:WARNING - Timeout at i8042_flush:71! origin/master:intel/minnowmax/4.5-306-g00ad7ff/2016-11-17T17_00_43Z/tests/cbmem-console.log:WARNING - Timeout at i8042_flush:71! origin/master:pcengines/alix2d/4.0-6723-ga0a3727-dirty/2014-08-15T23:01:34Z/coreboot_console.txt:WARNING - Timeout at i8042_flush:71! origin/master:pcengines/alix2d/4.0-6723-ga0a3727/2014-08-15T01:44:46Z/coreboot_console.txt:WARNING - Timeout at i8042_flush:71! origin/master:pcengines/apu1/4.4-422-g9aba60e/2016-06-05T08_06_37Z/coreboot_console.txt:WARNING - Timeout at i8042_flush:71! origin/master:pcengines/apu2/4.5-801-gfeb4ef6/2017-01-11T16_15_42Z/coreboot_console.txt:WARNING - Timeout at i8042_flush:71! origin/master:siemens/mc_tcu3/4.4-108-g0d4e124/2016-05-09T06_14_45Z/coreboot_console.txt:WARNING - Timeout at i8042_flush:71! ``` I also experience this sometimes on a Lenovo X60, when I load the SeaBIOS ELF file from GRUB with the commands below. ``` > chainloader (cbfsdisk)/img/seabios > boot ``` Every time, the keyboard doesn’t work – on the Lenovo X60 it’s connected over the PS/2 port – the error message `Timeout at i8042_flush:71!` can be seen. Note, that it’s unlikely to be a timing issue, as the keyboard works in the GRUB payload *before*. Any idea, what causes the problem, and is there a way to fix it? Thanks, Paul

2 6

Re: [SeaBIOS] [PATCH v3 2/2] QEMU fw_cfg: Add command to write back address of file
by Laszlo Ersek 08 Feb '17

08 Feb '17

On 02/05/17 18:09, ben(a)skyportsystems.com wrote: > From: Ben Warren <ben(a)skyportsystems.com> > > This command is similar to ADD_POINTER, but instead of patching > memory, it writes the pointer back to QEMU over the DMA interface. > > Signed-off-by: Ben Warren <ben(a)skyportsystems.com> > --- > src/fw/romfile_loader.c | 37 +++++++++++++++++++++++++++++++++++++ > src/fw/romfile_loader.h | 16 ++++++++++------ > 2 files changed, 47 insertions(+), 6 deletions(-) > > diff --git a/src/fw/romfile_loader.c b/src/fw/romfile_loader.c > index f4b17ff..d0ae42b 100644 > --- a/src/fw/romfile_loader.c > +++ b/src/fw/romfile_loader.c > @@ -5,6 +5,7 @@ > #include "romfile.h" // struct romfile_s > #include "malloc.h" // Zone*, _malloc > #include "output.h" // warn_* > +#include "paravirt.h" // qemu_cfg_write_file > > struct romfile_loader_file { > struct romfile_s *file; > @@ -98,7 +99,39 @@ static void romfile_loader_add_pointer(struct romfile_loader_entry_s *entry, > pointer += (unsigned long)src_file->data; > pointer = cpu_to_le64(pointer); > memcpy(dest_file->data + offset, &pointer, entry->pointer_size); > + return; > +err: > + warn_internalerror(); > +} > + > +static void romfile_loader_write_pointer(struct romfile_loader_entry_s *entry, > + struct romfile_loader_files *files) > +{ > + struct romfile_s *dest_file; > + struct romfile_loader_file *src_file; > + unsigned offset = le32_to_cpu(entry->pointer_offset); > + u64 pointer = 0; There's no need to zero-init "pointer" here. It doesn't hurt of course; I just like to avoid initialization if it is useless. > + > + /* Writing back to a file that may not be loaded in RAM */ > + dest_file = romfile_find(entry->pointer_dest_file); > + src_file = romfile_loader_find(entry->pointer_src_file, files); > > + if (!dest_file || !src_file || !src_file->data || > + offset + entry->pointer_size < offset || > + offset + entry->pointer_size > dest_file->size || > + entry->pointer_size < 1 || entry->pointer_size > 8 || > + entry->pointer_size & (entry->pointer_size - 1)) { > + goto err; > + } > + > + pointer = (unsigned long)src_file->data; > + pointer = cpu_to_le64(pointer); > + > + /* Only supported on QEMU */ > + if (qemu_cfg_write_file(&pointer, dest_file, offset, > + entry->pointer_size) != entry->pointer_size) { > + goto err; > + } > return; > err: > warn_internalerror(); > @@ -161,6 +194,10 @@ int romfile_loader_execute(const char *name) > break; > case ROMFILE_LOADER_COMMAND_ADD_CHECKSUM: > romfile_loader_add_checksum(entry, files); > + break; > + case ROMFILE_LOADER_COMMAND_WRITE_POINTER: > + romfile_loader_write_pointer(entry, files); > + break; > default: > /* Skip commands that we don't recognize. */ > break; > diff --git a/src/fw/romfile_loader.h b/src/fw/romfile_loader.h > index 15eab2a..0c0782c 100644 > --- a/src/fw/romfile_loader.h > +++ b/src/fw/romfile_loader.h > @@ -25,10 +25,13 @@ struct romfile_loader_entry_s { > }; > > /* > - * COMMAND_ADD_POINTER - patch the table (originating from > - * @dest_file) at @pointer_offset, by adding a pointer to the table > + * COMMAND_ADD_POINTER & > + * COMMAND_WRITE_POINTER - patch memory (originating from > + * @dest_file) at @pointer.offset, by adding a pointer to the memory > * originating from @src_file. 1,2,4 or 8 byte unsigned > - * addition is used depending on @pointer_size. > + * addition is used depending on @pointer.size. > + * Instead of patching memory, COMMAND_WRITE_POINTER writes the changes > + * to @dest_file back to the host via DMA > */ > struct { > char pointer_dest_file[ROMFILE_LOADER_FILESZ]; In general I think the patch is good, but (similarly to the QEMU case) I quite dislike this kind of repurposing. At the least, please leave the original comment block for COMMAND_ADD_POINTER intact, and add a separate, standalone comment block for COMMAND_WRITE_POINTER. Thanks! Laszlo > @@ -57,9 +60,10 @@ struct romfile_loader_entry_s { > }; > > enum { > - ROMFILE_LOADER_COMMAND_ALLOCATE = 0x1, > - ROMFILE_LOADER_COMMAND_ADD_POINTER = 0x2, > - ROMFILE_LOADER_COMMAND_ADD_CHECKSUM = 0x3, > + ROMFILE_LOADER_COMMAND_ALLOCATE = 0x1, > + ROMFILE_LOADER_COMMAND_ADD_POINTER = 0x2, > + ROMFILE_LOADER_COMMAND_ADD_CHECKSUM = 0x3, > + ROMFILE_LOADER_COMMAND_WRITE_POINTER = 0x4, > }; > > enum { >

2 1

Re: [SeaBIOS] [PATCH v3 1/2] QEMU DMA: Add DMA write capability
by Laszlo Ersek 08 Feb '17

08 Feb '17

On 02/05/17 18:09, ben(a)skyportsystems.com wrote: > From: Ben Warren <ben(a)skyportsystems.com> > > This allows BIOS to write data back to QEMU using the DMA interface and > provides a higher-level abstraction to write to a fw_cfg file > > Signed-off-by: Ben Warren <ben(a)skyportsystems.com> > --- > src/fw/paravirt.c | 49 +++++++++++++++++++++++++++++++++++++++++++++++++ > src/fw/paravirt.h | 3 +++ > 2 files changed, 52 insertions(+) > > diff --git a/src/fw/paravirt.c b/src/fw/paravirt.c > index 6de70f6..75cb992 100644 > --- a/src/fw/paravirt.c > +++ b/src/fw/paravirt.c > @@ -253,6 +253,20 @@ qemu_cfg_read(void *buf, int len) > } > > static void > +qemu_cfg_write(void *buf, int len) > +{ > + if (len == 0) { > + return; > + } > + > + if (qemu_cfg_dma_enabled()) { > + qemu_cfg_dma_transfer(buf, len, QEMU_CFG_DMA_CTL_WRITE); > + } else { > + warn_internalerror(); > + } > +} > + > +static void > qemu_cfg_skip(int len) > { > if (len == 0) { > @@ -280,6 +294,18 @@ qemu_cfg_read_entry(void *buf, int e, int len) > } > } > > +static void > +qemu_cfg_write_entry(void *buf, int e, int len) > +{ > + if (qemu_cfg_dma_enabled()) { > + u32 control = (e << 16) | QEMU_CFG_DMA_CTL_SELECT > + | QEMU_CFG_DMA_CTL_WRITE; > + qemu_cfg_dma_transfer(buf, len, control); > + } else { > + warn_internalerror(); > + } > +} > + > struct qemu_romfile_s { > struct romfile_s file; > int select, skip; > @@ -303,6 +329,29 @@ qemu_cfg_read_file(struct romfile_s *file, void *dst, u32 maxlen) > return file->size; > } > > +int > +qemu_cfg_write_file(void *src, struct romfile_s *file, u32 offset, u32 len) > +{ > + if ((file->size + offset) < len) > + return -1; I'm confused about this; mathematically, we want to require offset + len <= size If we want to avoid any possibility for overflow in the addition, we can subtract "len": offset <= size - len However, in this case the subtraction needs to be protected, and we end up with the following condition to proceed: size >= len && offset <= size - len If we want a condition for bailing out early, we got to negate the above: size < len || offset > size - len The rest looks good to me. Thanks Laszlo > + > + if (!qemu_cfg_dma_enabled() || (file->copy != qemu_cfg_read_file)) { > + warn_internalerror(); > + return -1; > + } > + struct qemu_romfile_s *qfile; > + qfile = container_of(file, struct qemu_romfile_s, file); > + if (offset == 0) { > + /* Do it in one transfer */ > + qemu_cfg_write_entry(src, qfile->select, len); > + } else { > + qemu_cfg_select(qfile->select); > + qemu_cfg_skip(offset); > + qemu_cfg_write(src, len); > + } > + return len; > +} > + > static void > qemu_romfile_add(char *name, int select, int skip, int size) > { > diff --git a/src/fw/paravirt.h b/src/fw/paravirt.h > index d8eb7c4..fb220d8 100644 > --- a/src/fw/paravirt.h > +++ b/src/fw/paravirt.h > @@ -3,6 +3,7 @@ > > #include "config.h" // CONFIG_* > #include "biosvar.h" // GET_GLOBAL > +#include "romfile.h" // struct romfile_s > > // Types of paravirtualized platforms. > #define PF_QEMU (1<<0) > @@ -43,6 +44,7 @@ static inline int runningOnKVM(void) { > #define QEMU_CFG_DMA_CTL_READ 0x02 > #define QEMU_CFG_DMA_CTL_SKIP 0x04 > #define QEMU_CFG_DMA_CTL_SELECT 0x08 > +#define QEMU_CFG_DMA_CTL_WRITE 0x10 > > // QEMU_CFG_DMA ID bit > #define QEMU_CFG_VERSION_DMA 2 > @@ -53,5 +55,6 @@ void qemu_platform_setup(void); > void qemu_cfg_init(void); > > u16 qemu_get_present_cpus_count(void); > +int qemu_cfg_write_file(void *src, struct romfile_s *file, u32 offset, u32 len); > > #endif >

2 1

[PATCH v3 0/2] QEMU: Add capability to write back fw_cfg address to QEMU
by ben＠skyportsystems.com 05 Feb '17

05 Feb '17

From: Ben Warren <ben(a)skyportsystems.com> This patch set adds the capability to write to QEMU across the fw_cfg DMA link. It adds a higher-level command to write the BIOS-allocated address of one fw_cfg file into an arbitrary point within another, writeable fw_cfg file across the above-mentioned link. The initial use case is for Windows VM Generation ID, where QEMU needs to change the contents of fw_cfg data at runtime, while still having BIOS allocate and manage the memory. v2->v3: - fixed up the qemu_cfg_write* functions to allow writing to an arbitrary offset within the destination file. - Changed function name to COMMAND_WRITE_POINTER and its functionality to not patch memory at all, but write back to a specified offset. v1->v2: - separated patch into two functional units. - changed so writes only occur over the DMA interface. - fixed coding style. - removed change to romfile struct definition (removed new write_back method). Ben Warren (2): QEMU DMA: Add DMA write capability QEMU fw_cfg: Add command to write back address of file src/fw/paravirt.c | 49 +++++++++++++++++++++++++++++++++++++++++++++++++ src/fw/paravirt.h | 3 +++ src/fw/romfile_loader.c | 37 +++++++++++++++++++++++++++++++++++++ src/fw/romfile_loader.h | 16 ++++++++++------ 4 files changed, 99 insertions(+), 6 deletions(-) -- 2.7.4

1 2

Boot menu key does not work with config options threads set to 2
by Paul Menzel 01 Feb '17

01 Feb '17

Dear SeaBIOS folks, On the ASRock E350M1 with coreboot and SeaBIOS, setting the runtime config option `threads` to 2, I am unable to press the boot menu key (ESC). [1] > By default, SeaBIOS will parallelize hardware initialization during bootup to reduce boot time. Multiple hardware devices can be initialized in parallel between vga initialization and option rom initialization. One can set this file to a value of zero to force hardware initialization to run serially. Alternatively, one can set this file to 2 to enable early hardware initialization that runs in parallel with vga, option rom initialization, and the boot menu. My rotating hard drive is pretty slow, and SeaBIOS is waiting for that. Not adding `etc/threads` to CBFS, pressing the key works, and the boot menu is displayed. Is that the expected behavior? Kind regards, Paul [1] https://www.seabios.org/Runtime_config

3 3

[PATCH 1/2] fw/acpi: Build MADT the way commodity BIOSes do
by Filippo Sironi 01 Feb '17

01 Feb '17

When running Linux on an Intel machine with a commodity BIOS, CPUs are numbered starting from 0 and the first half refers to the first logical CPU on each core while the second half refers to the second logical CPU on each core. As an example, on machine with 2 sockets, 4 cores per socket, and 2 logical CPUs per core, CPUs would be numbered: * 0 1 2 3 - first logical CPU on each core of socket 0 * 4 5 6 7 - first logical CPU on each core of socket 1 * 8 9 10 11 - second logical CPU on each core of socket 0 * 12 13 14 15 - second logical CPU on each core of socket 1 With seabios (prior to this patch), CPU 0 would be the first logical CPU on core 0 of socket 0, CPU 1 would be the second logical CPU on core 0 of socket 0, and so on. This is due to the fact that processor_id and local_apic_id are assigned with the same value when building MADT. Exhaust the most-significant 7 bits of the 8-bit APIC ID and then come back to the least-significant bit when assigning local_apic_id, since the least-significant bit identifies the second logical CPU on a core. If HTT isn't available, keep the previous behavior. Signed-off-by: Filippo Sironi <sironi(a)amazon.de> --- src/fw/acpi.c | 42 +++++++++++++++++++++++++++++++++++++++++- 1 file changed, 41 insertions(+), 1 deletion(-) diff --git a/src/fw/acpi.c b/src/fw/acpi.c index 8bc2ca6..864c247 100644 --- a/src/fw/acpi.c +++ b/src/fw/acpi.c @@ -158,13 +158,53 @@ build_madt(void) memset(madt, 0, madt_size); madt->local_apic_address = cpu_to_le32(BUILD_APIC_ADDR); madt->flags = cpu_to_le32(1); + u32 eax, ebx, ecx, edx; + cpuid(1, &eax, &ebx, &ecx, &edx); + int htt = 0; + if (!eax) { + dprintf(1, "No cpuid\n"); + } else { + htt = !!(edx & (1 << 28)); + /* assuming at most 2 logical CPUs per core */ + if (htt) + dprintf(4, "Found HTT feature\n"); + } struct madt_processor_apic *apic = (void*)&madt[1]; int i; for (i=0; i<MaxCountCPUs; i++) { apic->type = APIC_PROCESSOR; apic->length = sizeof(*apic); apic->processor_id = i; - apic->local_apic_id = i; + if (htt) { + /* + * In a system with 2 packages, 4 cores per package, and 2 CPUs per + * core we want to achieve the following coupling: + * CPU# APIC ID + * 0 0 [first socket, first logical CPUs] + * 1 2 + * 2 4 + * 3 6 + * 4 8 [second socket, first logical CPUs] + * 5 10 + * 6 12 + * 7 14 + * 8 1 [first socket, second logical CPUs] + * 9 3 + * 10 5 + * 11 7 + * 12 9 [second socket, second logical CPUs] + * 13 11 + * 14 13 + * 15 15 + * where the least-significant bit of the APIC ID identifies the + * first (0) or second (1) logical CPU in a core. + */ + apic->local_apic_id = i * 2; + if (apic->local_apic_id >= MaxCountCPUs) + apic->local_apic_id -= MaxCountCPUs - 1; + } else { + apic->local_apic_id = i; + } if (apic_id_is_present(apic->local_apic_id)) apic->flags = cpu_to_le32(1); else -- 2.7.4

5 11

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS February 2017