SeaBIOS

seabios@seabios.org

4 participants
3801 discussions

tpm: TPM 2 support
by Wim Vervoorn 07 Apr '17

07 Apr '17

Hello, I am planning to implement coreboot with SeaBIOS payload and using the Infineon 9665 TPM (in 2.0 mode). Can I assume this to work or should I expect issues with it that need to be solved? Best Regards, Wim Vervoorn

1 0

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

31 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 30 Mar '17

30 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 25 Mar '17

25 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

Minimum RAM size for PC machines?
by Markus Armbruster 23 Mar '17

23 Mar '17

Last time I checked[1], SeaBIOS required 1MiB of RAM, and the failure modes were mean. Back then, I asked whether we should enforce a suitable minimum RAM size[2]. Peter Maydell replied that modelling RAM constraints involves an expedition into the Generality Swamps, and wished me better luck than he had. Four and a half years later, the failure modes are as mean as ever. For instance, $ qemu-system-x86_64 --nodefaults -device VGA -m 640k simply hangs for me, and $ qemu-system-x86_64 --nodefaults -device VGA -m 16k crashes with "qemu: fatal: Trying to execute code outside RAM or ROM at 0x0000000000004000" and a register dump with TCG, or the even less helpful "KVM internal error. Suberror: 1" with KVM. Waiting for "someone" to design and implement the completely general solution has had the predictable result: nothing. Are we now ready to accept a simple & stupid patch that actually helps users, say letting boards that care declare minimum and maximum RAM size? And make PC reject RAM size less than 1MiB, even though "someone" might conceivably have firmware that works with less? [1] Message-ID: <87fw7xwqkq.fsf(a)blackfin.pond.sub.org> https://www.seabios.org/pipermail/seabios/2012-August/004343.html [2] Message-ID: <87wr1921rd.fsf(a)blackfin.pond.sub.org> https://lists.gnu.org/archive/html/qemu-devel/2012-08/msg01319.html

6 6

[PATCH 0/4] SeaVGABIOS improvments for coreboot's framebuffer
by Patrick Rudolph 18 Mar '17

18 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 I was able to boot Windows using VgaSave driver in text-mode with a fixed display resolution of 640x480@4Bpp. I was able to boot Windows using VgaSave driver in VESA mode and set a display resolution up to 1600x1200@24Bpp. Most likely other VESA compatible bootloaders and operating systems will be fixed, too. While most issues are fixed, one critical remains: Windows replaces int 15h at the start of the boot process, but SeaVGABios relies on it to clear the screen. It would be great if you could help me to implement a 32bit memcpy method that doesn't rely on bios calls to copy memory. All test in VESA mode had the clear screen feature disabled. Patrick Rudolph (4): 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 vgasrc/bochsvga.c | 5 ++ vgasrc/bochsvga.h | 1 + vgasrc/cbvga.c | 136 ++++++++++++++++++++++++++++++++++++++++++++++++++++-- vgasrc/clext.c | 5 ++ vgasrc/stdvga.c | 5 ++ vgasrc/vbe.c | 2 +- vgasrc/vgahw.h | 10 ++++ vgasrc/vgautil.h | 3 ++ 8 files changed, 161 insertions(+), 6 deletions(-) -- 2.7.4

3 8

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS