SeaBIOS

seabios@seabios.org

4 participants
3801 discussions

[PATCH] resume: Don't attempt to use generic reboot mechanisms on QEMU
by Kevin O'Connor 13 Mar '17

13 Mar '17

On QEMU it's necessary to manually reset the BIOS memory region between 0xc0000-0x100000 on a reboot. After this manual memory reset is completed, it's not valid to use the generic reset mechanisms. Rename qemu_prep_reset() to qemu_reboot() and change the function to immediately reboot after the code memcpy. This fixes a bug that could cause code corruption on reboots - calling the udelay() function (as invoked by i8042_reboot and/or pci_reboot) was not valid after the BIOS was memcpy'd. Reported-by: "Dr. David Alan Gilbert" <dgilbert(a)redhat.com> Signed-off-by: Kevin O'Connor <kevin(a)koconnor.net> --- This patch is based on Paolo's recommendation of first attempting a PCI style reboot on QEMU. However, instead of next attempting a keyboard reset, this patch attempts to signal an "INIT" via a triple fault (as I think that's a bit simpler and less likely to fail). --- src/fw/shadow.c | 14 +++++++++++++- src/hw/pci.c | 1 - src/hw/pci.h | 2 ++ src/resume.c | 4 ++-- src/util.h | 2 +- 5 files changed, 18 insertions(+), 5 deletions(-) diff --git a/src/fw/shadow.c b/src/fw/shadow.c index cd02d3a..c80b266 100644 --- a/src/fw/shadow.c +++ b/src/fw/shadow.c @@ -167,7 +167,7 @@ make_bios_readonly(void) } void -qemu_prep_reset(void) +qemu_reboot(void) { if (!CONFIG_QEMU || runningOnXen()) return; @@ -187,4 +187,16 @@ qemu_prep_reset(void) memcpy(hrp + 4, hrp + 4 + BIOS_SRC_OFFSET, cend - (hrp + 4)); barrier(); HaveRunPost = 0; + barrier(); + + // Request a QEMU system reset. Do the reset in this function as + // the BIOS code was overwritten above and not all BIOS + // functionality may be available. + + // Attempt PCI style reset + outb(0x02, PORT_PCI_REBOOT); + outb(0x06, PORT_PCI_REBOOT); + + // Next try triple faulting the CPU to force a reset + asm volatile("int3"); } diff --git a/src/hw/pci.c b/src/hw/pci.c index 506ee56..8e3d617 100644 --- a/src/hw/pci.c +++ b/src/hw/pci.c @@ -12,7 +12,6 @@ #include "x86.h" // outl #define PORT_PCI_CMD 0x0cf8 -#define PORT_PCI_REBOOT 0x0cf9 #define PORT_PCI_DATA 0x0cfc void pci_config_writel(u16 bdf, u32 addr, u32 val) diff --git a/src/hw/pci.h b/src/hw/pci.h index bf50430..ee6e196 100644 --- a/src/hw/pci.h +++ b/src/hw/pci.h @@ -3,6 +3,8 @@ #include "types.h" // u32 +#define PORT_PCI_REBOOT 0x0cf9 + static inline u8 pci_bdf_to_bus(u16 bdf) { return bdf >> 8; } diff --git a/src/resume.c b/src/resume.c index 99fa34f..fb0b8a8 100644 --- a/src/resume.c +++ b/src/resume.c @@ -125,8 +125,8 @@ tryReboot(void) { dprintf(1, "Attempting a hard reboot\n"); - // Setup for reset on qemu. - qemu_prep_reset(); + // Use a QEMU specific reboot on QEMU + qemu_reboot(); // Reboot using ACPI RESET_REG acpi_reboot(); diff --git a/src/util.h b/src/util.h index 336eaaf..8269057 100644 --- a/src/util.h +++ b/src/util.h @@ -123,7 +123,7 @@ void pirtable_setup(void); // fw/shadow.c void make_bios_writable(void); void make_bios_readonly(void); -void qemu_prep_reset(void); +void qemu_reboot(void); // fw/smbios.c void smbios_legacy_setup(void); -- 2.5.5

2 2

Re: [SeaBIOS] NVMe 1.0 compatibility and fixes
by Kevin O'Connor 05 Mar '17

05 Mar '17

On Sun, Mar 05, 2017 at 03:34:02PM -0700, Daniel Verkamp wrote: > On Thu, Mar 2, 2017 at 7:51 AM, Kevin O'Connor <kevin(a)koconnor.net> wrote: > > On Thu, Feb 23, 2017 at 11:27:52PM -0700, Daniel Verkamp wrote: > >> With the first two patches applied, I am able to install and boot > >> FreeDOS on an Intel SSD DC P3700, an NVMe 1.0 device, in QEMU > >> using PCI device assignment. > >> > >> The rest of the patches are minor issues found through inspection. > > > > Thanks. I committed this series. > > > > If this was tested with QEMU device passthrough, do you think we can > > also enable NVMe on real hardware? > > I am not equipped to test on a complete real-hardware system, but I > don't see anything that would prevent the driver from working > correctly there. If you tested with a real PCI device using PCI passthrough, then I think it's safe to enable support on real machines. -Kevin

1 0

NVMe 1.0 compatibility and fixes
by Daniel Verkamp 05 Mar '17

05 Mar '17

With the first two patches applied, I am able to install and boot FreeDOS on an Intel SSD DC P3700, an NVMe 1.0 device, in QEMU using PCI device assignment. The rest of the patches are minor issues found through inspection.

4 11

Seabios stops booting when pressing esc at wrong time
by i1w5d7gf38keg＠tutanota.com 03 Mar '17

03 Mar '17

Normal user expect that when there is written on the screen "Press ESC for boot menu." and afterwards when the user have not pressed anything inside the short time, and see then "Booting from Hard Disk..." then when the user press ESC nothing should happen any more because the user simply missed the time period to press the ESC button. In SeaBios there is a strange situation. When i see "Booting from Hard Disk..." and suddenly press ESC (few times) i get in a fully unusable state. The machine didnt do anything any more. Seabios Version is rel-1.10.0-19-g8f598a4 ... Press ESC for boot menu. Checking for bootsplash Searching bootorder for: HALT Mapping hd drive 0x000f5f80 to 0 drive 0x000f5f80: PCHS=16383/16/63 translation=lba LCHS=1024/255/63 s=312581808 finalize PMM malloc finalize Add to e820 map: 0009fc00 00000400 2 Space available for UMB: c7000-ea800, f5840-f5f80 Add to e820 map: 7bdc0000 00040000 1 Returned 262144 bytes of ZoneHigh e820 map has 9 items: 0: 0000000000000000 - 000000000009fc00 = 1 RAM 1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED 2: 00000000000f0000 - 0000000000100000 = 2 RESERVED 3: 0000000000100000 - 000000007bb29000 = 1 RAM 4: 000000007bb29000 - 000000007bc00000 = 2 RESERVED 5: 000000007bc00000 - 000000007be00000 = 1 RAM 6: 000000007be00000 - 0000000080000000 = 2 RESERVED 7: 00000000e0000000 - 00000000f0000000 = 2 RESERVED 8: 00000000fed10000 - 0000000100000000 = 2 RESERVED Jump to int19 enter handle_19: NULL Booting from Hard Disk... Booting from 0000:7c00 ata_reset drive=0x000f5f80 ata_reset exit status=50 i8042_command cmd=ae i8042_wait_write i8042_command cmd=ae i8042_wait_write i8042_command cmd=ae i8042_wait_write i8042_command cmd=ae i8042_wait_write Get VBE Controller: VBE2 Signature found VBE current mode=3 stub vbe_104fXX:406: a=00004f15 b=00000000 c=00000000 d=00000000 ds=0000 es=0000 ss=eab4 si=00000000 di=00000000 bp=00001ff0 sp=000001f6 cs=0000 ip=9104 f=0202 stub vbe_104fXX:406: a=00004f11 b=00000001 c=7bd00930 d=00000004 ds=7bd8 es=6000 ss=eab4 si=0007fbec di=00008080 bp=00001ff0 sp=000001f6 cs=0000 ip=9104 f=0202 set VGA mode 12 i8042_command cmd=ae i8042_wait_write i8042_command cmd=ae i8042_wait_write i8042_command cmd=ae i8042_wait_write i8042_command cmd=ae i8042_wait_write i8042_command cmd=ae i8042_wait_write i8042_command cmd=ae i8042_wait_write i8042_command cmd=ae i8042_wait_write i8042_command cmd=ae i8042_wait_write i8042_command cmd=ae i8042_wait_write i8042_command cmd=ae i8042_wait_write i8042_command cmd=ae i8042_wait_write i8042_command cmd=ae i8042_wait_write i8042_command cmd=ae i8042_wait_write i8042_command cmd=ae i8042_wait_write i8042_command cmd=ae i8042_wait_write i8042_command cmd=ae i8042_wait_write This should not happen. The user expect to not get into a state where nothing can be done any more.

2 1

Add log level to banner
by Paul Menzel 02 Mar '17

02 Mar '17

Dear SeaBIOS, Do you think it would be beneficial to have SeaBIOS log level noted in it’s banner? Kind regards, Paul

1 0

varlow/extrastack vs code
by Dr. David Alan Gilbert 27 Feb '17

27 Feb '17

Hi, I turned the debug level up to 4 on our smaller (128k) ROM downstream build and seem to have hit a case where it's been layed out so that the 'ExtraStack' is at the same location as some code (display_uuid) which was causing some very random behaviour; from an objdump disassemble of the rom.o that was produced: ef79d: f3 ab rep stos %eax,%es:(%edi) ef79f: 8d 43 08 lea 0x8(%ebx),%eax ef7a2: b1 10 mov $0x10,%cl ef7a4: 8d 54 24 74 lea 0x74(%esp),%edx ef7a8: e8 50 46 ff ff call e3dfd <memcmp> ef7ad: 85 c0 test %eax,%eax ef7af: 0f 84 33 01 00 00 je ef8e8 <ExtraStack+0x110> ef7b5: 8b 15 0c 23 0f 00 mov 0xf230c,%edx ef7bb: 80 7a 06 02 cmpb $0x2,0x6(%edx) ef7bf: 0f b6 43 17 movzbl 0x17(%ebx),%eax ef7c3: 77 0c ja ef7d1 <StackPos+0x1> ef7c5: 0f 85 80 00 00 00 jne ef84b <ExtraStack+0x73> ef7cb: 80 7a 07 05 cmpb $0x5,0x7(%edx) ef7cf: 76 7a jbe ef84b <ExtraStack+0x73> Note the 'ExtraStack+...' where as a few lines before it's maininit for other jumps, then looking at a sorted output of the rom.o.objdump: 000eddf2 l F .text 000000e0 virtio_scsi_add_lun.constprop.113 000eded2 l F .text 0000080d device_hardware_setup 000ee6df l F .text 00001a17 maininit <------------- 000ef790 g *ABS* 00000000 final_varlow_start 000ef790 g O *ABS* 00000004 BootSequence 000ef794 g O *ABS* 00000001 FloppyDOR 000ef798 g O *ABS* 00000008 LastUSBkey 000ef7a0 g O *ABS* 00000001 Ps2ctr 000ef7a4 g O *ABS* 00000004 RTCusers 000ef7a8 g O *ABS* 00000004 TimerLast 000ef7ac g O *ABS* 00000001 HaveAttemptedReboot 000ef7ad g O *ABS* 00000001 Century 000ef7b0 g O *ABS* 00000010 CDRom_locks 000ef7c0 g O *ABS* 00000010 DefaultDPTE 000ef7d0 g O *ABS* 00000004 StackPos 000ef7d8 g O *ABS* 00000801 ExtraStack <------------- 000effdc g O *ABS* 00000018 Call16Data 000f0000 g *ABS* 00000000 final_readonly_start 000f0000 g *ABS* 00000000 zonefseg_start 000f00f6 g F .text 0000038b dopost 000f0481 g F .text 000001c2 handle_pmm 000f0644 l O .text 00000014 CSWTCH.1353 000f0658 l O .text 00000014 __func__.14607 000f066c l O .text 00000011 __func__.14624 000f0680 l O .text 00000010 __func__.14549 000f0690 l O .text 0000000b __func__.14497 What's supposed to stop that happening? I'd chosen a debug level of 4 since that was the largest it would go without the build complaining it wouldn't fit, so I thought I was safe since something did complain if it got way too big. (This is based off 1.9.1) Dave -- Dr. David Alan Gilbert / dgilbert(a)redhat.com / Manchester, UK

5 39

Stable seabios release
by Kevin O'Connor 24 Feb '17

24 Feb '17

On Tue, Feb 21, 2017 at 08:10:57AM +0100, Gerd Hoffmann wrote: > Hi, > > > Gerd - are you planning to backport this series to the stable branch? > > Yes. Unless we'll have a 1.11 release next week, which I doubt ;) No short term plans for a major release. You may want to consider the following additional patches for the next stable release: 106543de - ahci: Set upper 32-bit registers to zero 970af16e - vgasrc: Increase debug level dbf9dd27 - ps2port: Disable keyboard/mouse prior to resetting ps2 controller -Kevin

3 2

Make it possible to boot encrypted HDDs when using seabios as payload on coreboot
by i1w5d7gf38keg＠tutanota.com 23 Feb '17

23 Feb '17

I liked to try out seabios instead of grub as payload and after flashing a coreboot image with seabios as only payload i got the message that i cant find any bootable device. Seems like seabios cant boot a basic debian installation where you encrypt the hdd and write grub into the MBR - the most default configuration. I have search trough the last months seabios mailing list archives but cant find a talk about that. Are there any plans of adding support for this?

2 1

[PATCH v7 0/5] QEMU: Add capability to write back fw_cfg address to QEMU
by ben＠skyportsystems.com 21 Feb '17

21 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. The final corresponding QEMU patch can be found here: https://www.mail-archive.com/qemu-devel@nongnu.org/msg430490.html v6->v7: - minor refactoring of qemu_cfg_write_file* functions v5->v6: - Rebased to top-of-tree - Minor refactoring and conditional execution based on code review v4->v5: - Minor changes to range checking and data validation - Added code for replaying COMMAND_WRITE_POINTER commands on S3 resume v3->v4: - Added a 'src_offset' field in the message so the pointer need not point to the beginning of the file. - Changed the command struct definitions from anonymous to named. 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 (5): QEMU DMA: Add DMA write capability romfile-loader: Switch to using named structs QEMU fw_cfg: Add command to write back address of file QEMU fw_cfg: Add functions for accessing files by key QEMU fw_cfg: Write fw_cfg back on S3 resume src/fw/paravirt.c | 68 +++++++++++++++++++++++++++++ src/fw/paravirt.h | 5 +++ src/fw/romfile_loader.c | 112 ++++++++++++++++++++++++++++++++++++++++-------- src/fw/romfile_loader.h | 65 ++++++++++++++++++---------- src/resume.c | 4 ++ 5 files changed, 214 insertions(+), 40 deletions(-) -- 2.7.4

3 7

Re: [SeaBIOS] [PATCH v7 5/5] QEMU fw_cfg: Write fw_cfg back on S3 resume
by Kevin O'Connor 21 Feb '17

21 Feb '17

On Mon, Feb 20, 2017 at 07:56:19PM -0800, ben(a)skyportsystems.com wrote: > From: Ben Warren <ben(a)skyportsystems.com> > > Any pointers to BIOS-allocated memory that were written back to QEMU > fw_cfg files are replayed when resuming from S3 sleep. > > Signed-off-by: Ben Warren <ben(a)skyportsystems.com> > Reviewed-by: Laszlo Ersek <lersek(a)redhat.com> > --- > src/fw/romfile_loader.c | 33 +++++++++++++++++++++++++++++++++ > src/fw/romfile_loader.h | 2 ++ > src/resume.c | 4 ++++ > 3 files changed, 39 insertions(+) > > diff --git a/src/fw/romfile_loader.c b/src/fw/romfile_loader.c > index 30e7b58..14bc908 100644 > --- a/src/fw/romfile_loader.c > +++ b/src/fw/romfile_loader.c > @@ -4,6 +4,7 @@ > #include "string.h" // strcmp > #include "romfile.h" // struct romfile_s > #include "malloc.h" // Zone*, _malloc > +#include "list.h" // struct hlist_node > #include "output.h" // warn_* > #include "paravirt.h" // qemu_cfg_write_file > > @@ -16,6 +17,16 @@ struct romfile_loader_files { > struct romfile_loader_file files[]; > }; > > +// Data structures for storing "write pointer" entries for possible replay > +struct romfile_wr_pointer_entry { > + u64 pointer; > + u32 offset; > + u16 key; > + u8 ptr_size; > + struct hlist_node node; > +}; > +static struct hlist_head romfile_pointer_list; > + > static struct romfile_loader_file * > romfile_loader_find(const char *name, > struct romfile_loader_files *files) > @@ -29,6 +40,19 @@ romfile_loader_find(const char *name, > return NULL; > } > > +// Replay "write pointer" entries back to QEMU > +void romfile_fw_cfg_resume(void) > +{ > + if (!CONFIG_QEMU) > + return; > + > + struct romfile_wr_pointer_entry *entry; > + hlist_for_each_entry(entry, &romfile_pointer_list, node) { > + qemu_cfg_write_file_simple(&entry->pointer, entry->key, > + entry->offset, entry->ptr_size); > + } > +} > + > static void romfile_loader_allocate(struct romfile_loader_entry_s *entry, > struct romfile_loader_files *files) > { > @@ -163,6 +187,15 @@ static void romfile_loader_write_pointer(struct romfile_loader_entry_s *entry, > entry->wr_pointer.size) != entry->wr_pointer.size) { > goto err; > } > + > + /* Store the info so it can replayed later if necessary */ > + struct romfile_wr_pointer_entry *store = malloc_high(sizeof(*store)); > + store->pointer = pointer; I missed this in my earlier review - it's necessary to always check the return of malloc() in seabios. (Writing to NULL changes memory at address 0 which is shared with the 16bit interrupt table.) I fixed it upon commit. -Kevin

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS