SeaBIOS March 2017

seabios@seabios.org

19 participants
17 discussions

[PATCH 0/3] SeaVGABIOS serial console test
by Kevin O'Connor 05 Sep '17

05 Sep '17

Hi Gerd, I was curious to see what the "sercon" stuff would look like in SeaVGABIOS instead of in SeaBIOS. So, I put together a quick prototype. The code is also at: https://github.com/KevinOConnor/seabios/tree/testing This is just a proof-of-concept thing - I didn't implement any of the useful features you have in your series. Specifically, it doesn't unclutter the serial output, doesn't implement cp437 translations, and doesn't handle multi-byte input. It does does have basic input, output, and split-output handling though. I'm not sure if this is better than a SeaBIOS implementation. I suspect it will be easier to handle vga quirks this way. However, handling exotic serial outputs (eg, mmio and usb based) would be better suited in SeaBIOS. Thoughts? -Kevin Kevin O'Connor (3): sercon: Initial support for VGA emulation over serial port sercon: Add basic keyboard input support sercon: Support "split output" mode Makefile | 2 +- vgasrc/Kconfig | 6 + vgasrc/sercon.c | 356 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ vgasrc/vgabios.c | 15 ++- vgasrc/vgabios.h | 5 + vgasrc/vgaentry.S | 7 ++ vgasrc/vgahw.h | 72 ++++++++++- vgasrc/vgainit.c | 12 +- vgasrc/vgautil.h | 24 ++++ 9 files changed, 482 insertions(+), 17 deletions(-) create mode 100644 vgasrc/sercon.c -- 2.5.5

2 12

Re: [SeaBIOS] [PATCH 1/4] SeaVGABios/cbvga: Assume VGA compatible GPU in text-mode
by Patrick Rudolph 10 May '17

10 May '17

On Sat Mar 18 02:04:38 CET 2017, Kevin O'Connor wrote: >> Assume the GPU is VGA compatible when running in text-mode. >> Advertise VGA modes using SeaVGABios' stdvga driver. >> running in text mode, even when not advertised. >> >> Allows Windows 7 to boot in 640x480 and 16 colors mode using the >> VgaSave driver. >> Allows Windows 7 to show the loading bar splash screen. >> >> Known issues: >> The palette seems wrong, as colors are swapped ( blue is red, ... ). > >What graphics hardware did you test this on? > >If stdvga_set_mode() works on the hardware, why not use stdvga >seavgabios and get the rest of the vgabios functionality? (That is, >why use cbvga seavgabios at all?) I'm on Lenovo T500 (Intel Graphics Media Accelerator 4500MHD). I'm going to do some tests using stdvga instead of cbvga. Regards, Patrick

2 1

[PATCH 0/9] add support for generic lun enumeration
by Roman Kagan 10 Apr '17

10 Apr '17

A number of SCSI drivers currently only see luns #0 in their targets. This may be a problem when drives have to be assigned bigger lun numbers, e.g. because the storage controllers don't provide enough target numbers to accomodate all drives. (In particular, I'm about to submit a driver for Hyper-V VMBus SCSI controller which is limited to 2 targets only). This series adds generic SCSI lun enumeration (either via REPORT LUNS command or sequentially trying every lun), and makes the respective drivers use it. Note that the series has only been minimally tested against a recent QEMU. Roman Kagan (9): blockcmd: accept only disks and CD-ROMs blockcmd: generic SCSI luns enumeration virtio-scsi: enumerate luns with REPORT LUNS esp-scsi: enumerate luns with REPORT LUNS usb-uas: enumerate luns with REPORT LUNS pvscsi: fix the comment about lun enumeration mpt-scsi: try to enumerate luns with REPORT LUNS lsi-scsi: reset in case of a serious problem lsi-scsi: try to enumerate luns with REPORT LUNS src/hw/blockcmd.h | 4 +++ src/hw/blockcmd.c | 96 ++++++++++++++++++++++++++++++++++++++++++++++++++++ src/hw/esp-scsi.c | 35 +++++++++++++------ src/hw/lsi-scsi.c | 39 +++++++++++++++------ src/hw/mpt-scsi.c | 40 ++++++++++++++-------- src/hw/pvscsi.c | 2 +- src/hw/usb-uas.c | 45 +++++++++++++++--------- src/hw/virtio-scsi.c | 38 ++++++++++++++------- 8 files changed, 235 insertions(+), 64 deletions(-) -- 2.9.3

5 26

issues about keyboard in the safe mode of windows 7
by fulaiyang 30 Mar '17

30 Mar '17

I use the qemu-2.7 and seabios-1.10.1 to start the windows 7 guest. And the xhci controller is passthroughed to the guest. When the safe mode interface of the windows 7 appears, keyboard sometimes doesn't work and I can not choose any mode. I have referred to seabios code about xhci configuration and find that after initializing USB keyboard, the timer ISR will check usb event periodically. Normally, the "xhci_process_events" function can process the keyboard events, but now TRB_C bit of xhci controller has been unchanged and "xhci_process_events" function derectly return. So keyboard didn't work. I want to know why TRB_C bit of xhci controller is always unchanged. Hope somebody can help me. Sorry for my poor English. static void xhci_process_events(struct usb_xhci_s *xhci) { struct xhci_ring *evts = xhci->evts; for (;;) { /* check for event */ u32 nidx = evts->nidx; u32 cs = evts->cs; struct xhci_trb *etrb = evts->ring + nidx; u32 control = etrb->control; if ((control & TRB_C) != (cs ? 1 : 0)) return;//stop here .... ....}

1 0

[PATCH v3] config: Add function to check if fw_cfg exists
by Petr Berky 29 Mar '17

29 Mar '17

It was found qemu_get_present_cpus_count may return impossible number of cpus because of not checking if fw_cfg exists before using it. That may lead to undefined behavior of emulator, in particular Bochs that freezes. Signed-off-by: Petr Berky <petr.berky(a)email.cz> --- src/fw/paravirt.c | 12 +++++++++++- src/fw/paravirt.h | 1 + 2 files changed, 12 insertions(+), 1 deletion(-) diff --git a/src/fw/paravirt.c b/src/fw/paravirt.c index 707502d..5b23d78 100644 --- a/src/fw/paravirt.c +++ b/src/fw/paravirt.c @@ -32,9 +32,16 @@ u32 RamSize; u64 RamSizeOver4G; // Type of emulator platform. int PlatformRunningOn VARFSEG; +// cfg enabled +int cfg_enabled = 0; // cfg_dma enabled int cfg_dma_enabled = 0; +inline int qemu_cfg_enabled(void) +{ + return cfg_enabled; +} + inline int qemu_cfg_dma_enabled(void) { return cfg_dma_enabled; @@ -392,7 +399,9 @@ u16 qemu_get_present_cpus_count(void) { u16 smp_count = 0; - qemu_cfg_read_entry(&smp_count, QEMU_CFG_NB_CPUS, sizeof(smp_count)); + if (qemu_cfg_enabled()) { + qemu_cfg_read_entry(&smp_count, QEMU_CFG_NB_CPUS, sizeof(smp_count)); + } u16 cmos_cpu_count = rtc_read(CMOS_BIOS_SMP_COUNT) + 1; if (smp_count < cmos_cpu_count) { smp_count = cmos_cpu_count; @@ -571,6 +580,7 @@ void qemu_cfg_init(void) return; dprintf(1, "Found QEMU fw_cfg\n"); + cfg_enabled = 1; // Detect DMA interface. u32 id; diff --git a/src/fw/paravirt.h b/src/fw/paravirt.h index 16f3d9a..a14d83e 100644 --- a/src/fw/paravirt.h +++ b/src/fw/paravirt.h @@ -49,6 +49,7 @@ static inline int runningOnKVM(void) { // QEMU_CFG_DMA ID bit #define QEMU_CFG_VERSION_DMA 2 +int qemu_cfg_enabled(void); int qemu_cfg_dma_enabled(void); void qemu_preinit(void); void qemu_platform_setup(void); -- 2.11.0

3 2

[PATCH] config: Add function to check if fw_cfg exists
by petr.berky＠email.cz 28 Mar '17

28 Mar '17

>From 405de6e571a2bf332452a17ae98f7b3a0613365e Mon Sep 17 00:00:00 2001 From: Petr Berky <petr.berky(a)email.cz> Date: Tue, 14 Mar 2017 20:30:52 +0100 Subject: [PATCH] config: Add function to check if fw_cfg exists It was found qemu_get_present_cpus_count may return impossible number of cpus because of not checking if fw_cfg exists before using it. That may lead to undefined behavior of emulator, in particular Bochs that freezes. Signed-off-by: Petr Berky <petr.berky(a)email.cz> --- src/fw/paravirt.c | 28 +++++++++++++++++++++------- 1 file changed, 21 insertions(+), 7 deletions(-) diff --git a/src/fw/paravirt.c b/src/fw/paravirt.c index 707502d..b2cfc23 100644 --- a/src/fw/paravirt.c +++ b/src/fw/paravirt.c @@ -220,6 +220,21 @@ qemu_cfg_select(u16 f) outw(f, PORT_QEMU_CFG_CTL); } +static int +qemu_cfg_check_signature(void) +{ + int i; + char *sig = "QEMU"; + + qemu_cfg_select(QEMU_CFG_SIGNATURE); + for (i = 0; i < 4; i++) { + if (inb(PORT_QEMU_CFG_DATA) != sig[i]) { + return -1; + } + } + return 0; +} + static void qemu_cfg_dma_transfer(void *address, u32 length, u32 control) { @@ -392,7 +407,9 @@ u16 qemu_get_present_cpus_count(void) { u16 smp_count = 0; - qemu_cfg_read_entry(&smp_count, QEMU_CFG_NB_CPUS, sizeof(smp_count)); + if (qemu_cfg_check_signature() == 0) { + qemu_cfg_read_entry(&smp_count, QEMU_CFG_NB_CPUS, sizeof(smp_count)); + } u16 cmos_cpu_count = rtc_read(CMOS_BIOS_SMP_COUNT) + 1; if (smp_count < cmos_cpu_count) { smp_count = cmos_cpu_count; @@ -563,12 +580,9 @@ void qemu_cfg_init(void) return; // Detect fw_cfg interface. - qemu_cfg_select(QEMU_CFG_SIGNATURE); - char *sig = "QEMU"; - int i; - for (i = 0; i < 4; i++) - if (inb(PORT_QEMU_CFG_DATA) != sig[i]) - return; + if (qemu_cfg_check_signature() != 0) { + return; + } dprintf(1, "Found QEMU fw_cfg\n"); -- 2.11.0

4 6

Bootsplash
by Gert Menke 26 Mar '17

26 Mar '17

Hi, I recently installed Coreboot and SeaBIOS on my Thinkpad X230. After sorting out a little problem with suspend/resume, I am quite happy with it. Now I would like to add a bootsplash image, but SeaBIOS seems unable to find any vesa modes. However, HDT (http://www.hdt-project.org) shows several modes, including the native display resolution (1366x768x32) and the resolution of my bootsplash.bmp (1024x768x32). I am using the proprietary vesa bios blob extracted from the original X230 BIOS and it seems to work fine, except for the bootsplash. Thanks for any help, Gert

2 4

[Bochs] [PATCH RFC] shadow: Change order of PCI writes
by petr.berky＠email.cz 25 Mar '17

25 Mar '17

I am working on an issue with SeaBIOS running in Bochs emulator. I found I need to revert SeaBIOS patch d449a11, otherwise Bochs freezes. After the further investigation, I narrowed down the problem to those lines: File: src/fw/shadow.c Function: __make_bios_writable_intel 48 // Write PAM settings back to pci config space 49 pci_config_writel(bdf, ALIGN_DOWN(pam0, 4), pamdata.data32[0]); 50 pci_config_writel(bdf, ALIGN_DOWN(pam0, 4) + 4, pamdata.data32[1]); File: src/fw/shadow.c Function: make_bios_readonly_intel 109 // Write PAM settings back to pci config space 110 pci_config_writel(bdf, ALIGN_DOWN(pam0, 4), pamdata.data32[0]); 111 pci_config_writel(bdf, ALIGN_DOWN(pam0, 4) + 4, pamdata.data32[1]); What has changed, comparing to the code before patch d449a11 is the order of writes to PAM registers. Before d449a11 the order was: 0x5a 0x5b 0x5c 0x5d 0x5e 0x5f 0x59 After d449a11 the order is : 0x59 0x5a 0x5b 0x5c 0x5d 0x5e 0x5f I believe also the 0x58 (DRAMT?) register is written after the patch d449a11 and was not before. I checked, and the registers values after write are exactly the same in both cases (before/after patch). This lead me to think the order of writes matters. So I prepared the patch that restores the old order. I works well and fixes the issue with Bochs. But there is still one think I cannot explain and I hope I can find some help here. If you look on the patch below, you will see I had to use different pci write functions in __make_bios_writable_intel and make_bios_readonly_intel. The only difference in those functions (I think) is the size of data that is written at one call. Still It does not work for me when written some other way. Again, I would appreciate if someone could explain it to me or point me some documentation. Just to summarize, I have two questions: 1. Why the order of pci writes makes a difference here? 2. Why the size of pci writes matters? >From 953c133a6ade49e9148a0734ffefc0fb27c116fb Mon Sep 17 00:00:00 2001 From: Petr Berky <petr.berky(a)email.cz> Date: Sun, 19 Mar 2017 10:14:49 +0100 Subject: [PATCH RFC] shadow: Change order of PCI writes This change solves the problem with Bochs freeze --- src/fw/shadow.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/src/fw/shadow.c b/src/fw/shadow.c index c80b266..508af20 100644 --- a/src/fw/shadow.c +++ b/src/fw/shadow.c @@ -23,6 +23,7 @@ union pamdata_u { u8 data8[8]; + u16 data16[4]; u32 data32[2]; }; @@ -46,8 +47,9 @@ __make_bios_writable_intel(u16 bdf, u32 pam0) pam[0] = 0x30; // Write PAM settings back to pci config space - pci_config_writel(bdf, ALIGN_DOWN(pam0, 4), pamdata.data32[0]); + pci_config_writew(bdf, ALIGN_DOWN(pam0, 4) + 2, pamdata.data16[1]); pci_config_writel(bdf, ALIGN_DOWN(pam0, 4) + 4, pamdata.data32[1]); + pci_config_writeb(bdf, ALIGN_DOWN(pam0, 4) + 1, pamdata.data8[1]); if (!ram_present) // Copy bios. @@ -107,8 +109,11 @@ make_bios_readonly_intel(u16 bdf, u32 pam0) pam[0] = 0x10; // Write PAM settings back to pci config space - pci_config_writel(bdf, ALIGN_DOWN(pam0, 4), pamdata.data32[0]); - pci_config_writel(bdf, ALIGN_DOWN(pam0, 4) + 4, pamdata.data32[1]); + pci_config_writew(bdf, ALIGN_DOWN(pam0, 4) + 2, pamdata.data16[1]); + pci_config_writew(bdf, ALIGN_DOWN(pam0, 4) + 4, pamdata.data16[2]); + pci_config_writeb(bdf, ALIGN_DOWN(pam0, 4) + 6, pamdata.data8[6]); + pci_config_writeb(bdf, ALIGN_DOWN(pam0, 4) + 7, pamdata.data8[7]); + pci_config_writeb(bdf, ALIGN_DOWN(pam0, 4) + 1, pamdata.data8[1]); } static int ShadowBDF = -1; -- 2.11.0

2 2

Re: [SeaBIOS] [PATCH 0/8] SeaVGABIOS improvments for coreboot's framebuffer v2
by Patrick Rudolph 25 Mar '17

25 Mar '17

On Fri, 24 Mar 2017 20:51:56 -0400 Kevin O'Connor <kevin(a)koconnor.net> wrote: > On Fri, Mar 24, 2017 at 05:27:19PM +0100, Patrick Rudolph wrote: > > This series add several fixes to coreboot's framebuffer > > implementation and it main purpose is to fix Microsoft's Windows as > > supported OS. > > > > The series fixes the following issues: > > * Windows shows no image in text-mode > > * Windows NTLDR/bootmgr shows no image in VESA mode > > * Windows shows no image in VESA mode > > * Windows legacy Intel VGA driver requires VBT in VGA option ROM > > * Clear screen broken due to INT 15h replaced by OS > > > > I was able to boot Windows with the following configurations: > > * using VgaSave driver in text-mode with a > > fixed display resolution of 640x480 at 4Bpp. > > * using VgaSave driver in VESA mode and > > set a display resolution up to 1600x1200 at 24Bpp. > > * using VgaSave driver in Windows's "Safe Mode" in VESA mode and > > set a display resolution up to 1600x1200 at 24Bpp. > > * using the Intel VGA driver with up to the panel native > > resolution of 1680x1050 at 24Bpp. > > > > Most likely other VESA compatible bootloaders and operating systems > > will be fixed, too. > > > > Changes since v1: > > Thanks, but I didn't see a response to my comments on patches 1 and 2 > from the last series. > Sorry, I'll will fix the issues in patches 1 and 2. > > * Add crash detection handler for INT 15h modifications. > > Can you explain how this works? If int1587 is disabled, why is it a > priority to not clear the screen? To prevent a crash on the next mode change. Windows will iterate over modes and finaly end with mode 12, which isn't a compatible VESA mode. > > > * Copy Intel VBT to VGA option ROM if provided by ASLS > > As a high level comment, I think it would be great to have further > support for Intel video in SeaVGABIOS, but I wonder if extending cbvga > is the right approach. Seems like we could make an intel-seavgabios > and it would be a better platfrom for future intel specific features > (like auto-detecting the framebuffer and maybe even switching modes). > Having a seperate vga option rom would require additional configuration overhead in coreboot. As for now autodetecting the card at runtime seems to be prefereable. I'm not planing to include any intel specific features. > Cheers, > -Kevin

1 0

[PATCH 0/8] SeaVGABIOS improvments for coreboot's framebuffer v2
by Patrick Rudolph 24 Mar '17

24 Mar '17

This series add several fixes to coreboot's framebuffer implementation and it main purpose is to fix Microsoft's Windows as supported OS. The series fixes the following issues: * Windows shows no image in text-mode * Windows NTLDR/bootmgr shows no image in VESA mode * Windows shows no image in VESA mode * Windows legacy Intel VGA driver requires VBT in VGA option ROM * Clear screen broken due to INT 15h replaced by OS I was able to boot Windows with the following configurations: * using VgaSave driver in text-mode with a fixed display resolution of 640x480 at 4Bpp. * using VgaSave driver in VESA mode and set a display resolution up to 1600x1200 at 24Bpp. * using VgaSave driver in Windows's "Safe Mode" in VESA mode and set a display resolution up to 1600x1200 at 24Bpp. * using the Intel VGA driver with up to the panel native resolution of 1680x1050 at 24Bpp. Most likely other VESA compatible bootloaders and operating systems will be fixed, too. Changes since v1: * Add crash detection handler for INT 15h modifications. * Disable VESA modes in cbvga_init * Make memcpy_high method public * Copy Intel VBT to VGA option ROM if provided by ASLS Patrick Rudolph (8): SeaVGABios/cbvga: Advertise correct pixel format SeaVGABios/cbvga: Assume VGA compatible GPU in text-mode SeaVGABIOS/vbe: Query driver for scanline pitch SeaVGABios/cbvga: Use active mode to clear screen SeaVGABios/cbvga: Advertise compatible VESA modes SeaVGABios/vgafb: Make memcpy_high public SeaVGABios/cbvga:: Add Intel VBT support SeaVGABios/cbvga: Add crash detection handler vgasrc/bochsvga.c | 5 + vgasrc/bochsvga.h | 1 + vgasrc/cbvga.c | 274 ++++++++++++++++++++++++++++++++++++++++++++++++++++-- vgasrc/clext.c | 5 + vgasrc/stdvga.c | 5 + vgasrc/vbe.c | 2 +- vgasrc/vgaentry.S | 2 +- vgasrc/vgafb.c | 2 +- vgasrc/vgafb.h | 2 +- vgasrc/vgahw.h | 10 ++ vgasrc/vgautil.h | 3 + 11 files changed, 301 insertions(+), 10 deletions(-) -- 2.9.3

2 9

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS March 2017