SeaBIOS

seabios@seabios.org

2 participants
3799 discussions

USB Keyboard and Mouse not Detected
by Ankita Mahato 09 Dec '19

09 Dec '19

Hi, I have some problem in SeaBIOS. USB keyboard and USB mouse are not detected. EHCI and OHCI are enabled. I cannot use my keyboard in my SeaBIOS. USB keyboard and USB mouse are enabled in SeaBIOS .config . The Linux kernel does detect them and I can use them in Linux. Some timeout is happening. Following is the part of the debug message where only keyboard is attached: Searching bootorder for: /pci@i0cf8/*@1f,2/drive@0/disk@0 AHCI/0: Set transfer mode to UDMA-6 AHCI/0: registering: "AHCI/0: WDC WD5000AZLX-00CL5A0 ATA-9 Hard-Disk (465 GiBytes)" Found 0 lpt ports Found 1 serial ports Searching bootorder for: /rom@img/uefi XHCI no devices found USB keyboard initialized WARNING - Timeout at ehci_wait_td:517! ehci pipe=0x7ecec300 cur=7eccfdc0 tok=00000c00 next=7ecced40 td=0x7ecced40 status=80e80 WARNING - Timeout at ehci_waittick:178! Failure on hub port 3 reset WARNING - Timeout at ehci_wait_td:517! ehci pipe=0x7ecec300 cur=7eccfdc0 tok=00000000 next=7ecced40 td=0x7ecced40 status=80e80 WARNING - Timeout at ehci_waittick:165! Failure on hub port 3 disconnect WARNING - Timeout at ehci_wait_td:517! ehci pipe=0x7ecec300 cur=7eccfdc0 tok=00000000 next=7eccfd40 td=0x7eccfd40 status=80e80 WARNING - Timeout at ehci_waittick:165! Failure on hub port 2 detect WARNING - Timeout at ehci_wait_td:517! ehci pipe=0x7ecec300 cur=7eccfdc0 tok=00000000 next=7ecd0d40 td=0x7ecd0d40 status=80e80 WARNING - Timeout at ehci_waittick:165! Failure on hub port 1 detect Initialized USB HUB (1 ports used) WARNING - Timeout at ehci_waittick:165! All threads complete. Scan for option roms Press ESC for boot menu. Thanks and Regards, Ankita L&T Technology Services Ltd www.LTTS.com L&T Technology Services Limited (LTTS) is committed to safeguard your data privacy. For more information to view our commitment towards data privacy under GDPR, please visit the privacy policy on our website www.Ltts.com. This Email may contain confidential or privileged information for the intended recipient (s). If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system.

1 0

[PATCH 2/4] pci: Allow scanning pci bus number up to 255 in CSM mode
by Your Real Name 05 Dec '19

05 Dec '19

From 3bf91481863ec504d113aa6b94827bf92840e291 Mon Sep 17 00:00:00 2001 From: gaobin <gaobin(a)amazon.com> Date: Thu, 19 Sep 2019 11:23:04 -0700 Subject: [PATCH 2/4] pci: Allow scanning pci bus number up to 255 in CSM mode On real hardware especially server platforms, there are many pci devices, bridges, either SoC integrated or addon. They can exhaust all the pci bus numbers. So when scanning the pci bus, we need to allow the bus number up to 255. Signed-off-by: gaobin <gaobin(a)amazon.com> --- src/hw/pcidevice.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/hw/pcidevice.c b/src/hw/pcidevice.c index 8853cf7..acf15b4 100644 --- a/src/hw/pcidevice.c +++ b/src/hw/pcidevice.c @@ -26,6 +26,12 @@ pci_probe_devices(void) struct hlist_node **pprev = &PCIDevices.first; int extraroots = romfile_loadint("etc/extra-pci-roots", 0); int bus = -1, lastbus = 0, rootbuses = 0, count=0; + + // On real hardware especially server platforms, the bus number + // could run up to the top value, i.e. 0xff + if (CONFIG_CSM) + extraroots = 0xff; + while (bus < 0xff && (bus < MaxPCIBus || rootbuses < extraroots)) { bus++; int bdf; -- 2.17.1

2 5

csm: Call pci_probe_devices() late until PrepareToBoot is invoked by UEFI
by Your Real Name 03 Dec '19

03 Dec '19

From 7dd0e8b98c71254148180b3cc432de1c4936526c Mon Sep 17 00:00:00 2001 From: gaobin <gaobin(a)amazon.com> Date: Thu, 19 Sep 2019 11:17:46 -0700 Subject: [PATCH 1/4] csm: Call pci_probe_devices() late until PrepareToBoot is invoked by UEFI On real hardware, some PCI devices are not detectable when UEFI BIOS invokes our InitializeYourself() function. But they are guaranteed to be available before UEFI invokes our PreparToBoot() function. Signed-off-by: gaobin <gaobin(a)amazon.com> --- src/fw/csm.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/src/fw/csm.c b/src/fw/csm.c index 8359bcb..c8111cd 100644 --- a/src/fw/csm.c +++ b/src/fw/csm.c @@ -63,7 +63,6 @@ static void csm_maininit(struct bregs *regs) { interface_init(); - pci_probe_devices(); csm_compat_table.PnPInstallationCheckSegment = SEG_BIOS; csm_compat_table.PnPInstallationCheckOffset = get_pnp_offset(); @@ -143,6 +142,12 @@ handle_csm_0002(struct bregs *regs) return; } + // On real hardware, some PCI devices are not detectable when + // UEFI invokes our InitializeYourself() function. But they + // are guaranteed to be available before UEFI invokes our + // PreparToBoot() function. + pci_probe_devices(); + dprintf(3, "PrepareToBoot table %04x:%04x\n", regs->es, regs->bx); struct e820entry *p = (void *)csm_compat_table.E820Pointer; -- 2.17.1

2 2

1.13 release?
by Gerd Hoffmann 20 Nov '19

20 Nov '19

Hi, Almost a year since 1.12.0 was tagged (Nov 17th to be exact), time to plan the 1.13 release I think ... How about freeze in a week or two, release by mid-november? Pending stuff I'm aware of is the disk geometry patch series. The corresponding qemu series is still waiting to be merged. There already was a pull request for it though, it only was dropped due to a regression showing up, so I think there is still a chance that it'll be merged shortly given that no objections where raised during review. Anything else which should be considered for 1.13? cheers, Gerd

2 5

[PATCH] ahci: zero-initialize port struct
by Gerd Hoffmann 15 Nov '19

15 Nov '19

Specifically port->driver.lchs needs clearing, otherwise seabios will try interpret whatever random crap happens to be there as disk geometry, which may or may not break boot depending on how lucky you are. Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> --- src/hw/ahci.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/hw/ahci.c b/src/hw/ahci.c index 97a072a1ca81..d45b4307ec68 100644 --- a/src/hw/ahci.c +++ b/src/hw/ahci.c @@ -345,6 +345,7 @@ ahci_port_alloc(struct ahci_ctrl_s *ctrl, u32 pnr) warn_noalloc(); return NULL; } + memset(port, 0, sizeof(*port)); port->pnr = pnr; port->ctrl = ctrl; port->list = memalign_tmp(1024, 1024); -- 2.18.1

4 13

[PATCH 0/2] tpm: Defend against TPM sending unexpected short packets
by Stefan Berger 13 Nov '19

13 Nov '19

This series of patches addresses issues that may arise if a TPM sends unexpected short packets. Stefan Stefan Berger (2): tpm: Require a response to have minimum size of a valid response header tcgbios: Check for enough bytes returned from TPM2_GetCapability src/hw/tpm_drivers.c | 3 ++- src/tcgbios.c | 13 +++++++++++-- 2 files changed, 13 insertions(+), 3 deletions(-) -- 2.20.1

4 7

[PING: PATCH v1] virtio: extend virtio queue size to 256
by Denis Plotnikov 12 Nov '19

12 Nov '19

v1: * more verbose commit message [Gerd] --- The goal of the patch is to work around a performance bug in guest linux kernels. Old linux kernels has a performance flaw in virtio block device access: on some frequent disk access patterns, e.g. 1M read, the kernel produces more block requests than needed. This happens because of virtio seg_max parameter set to 126 (virtqueue_size - 2) which limits the maximum block request to 516096 (126 * 4096_PAGE_SIZE) bytes. Setting seg_max > 126 fixes the issue, however, not all linux kernels allow that without increasing virtio virtqueue size. The old kernels have a restriction: virtqueue_size >= seg_max. In case of the restriction violation the old kernels crash. The restriction is relaxed in the recent linux kernels (ver >= 4.13) with: commit 44ed8089e991a60d614abe0ee4b9057a28b364e4 Author: Richard W.M. Jones Date: Thu Aug 10 17:56:51 2017 +0100 scsi: virtio: Reduce BUG if total_sg > virtqueue size to WARN. and the recent linux kernels don't crash if total_sg > virtqueue size allowing to set seg_max to the needed value without virtqueue size increasing. To fix the performance flaw in the old linux kernels, it's needed to increse seg_max to 254, and comply the restriction by setting virtqueue_size to 256. This is achievable if seabios can support virtqueue size > 128 which this patch actually does. Windows kernels don't have virtqueue_size >= seg_max restriction and isn't affected with this kind of the performance bug. Signed-off-by: Denis Plotnikov <dplotnikov(a)virtuozzo.com> --- src/hw/virtio-ring.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/hw/virtio-ring.h b/src/hw/virtio-ring.h index 8604a01..dccc50d 100644 --- a/src/hw/virtio-ring.h +++ b/src/hw/virtio-ring.h @@ -20,7 +20,7 @@ #define VIRTIO_F_VERSION_1 32 #define VIRTIO_F_IOMMU_PLATFORM 33 -#define MAX_QUEUE_NUM (128) +#define MAX_QUEUE_NUM (256) #define VRING_DESC_F_NEXT 1 #define VRING_DESC_F_WRITE 2 -- 2.17.0

2 2

[PATCH v1--annotate] virtio: extend virtio queue size to 256
by Denis Plotnikov 11 Nov '19

11 Nov '19

1 0

Re: [PULL 0/1] Seabios 20191106 patches
by Gerd Hoffmann 08 Nov '19

08 Nov '19

On Thu, Nov 07, 2019 at 11:56:03AM +0000, Peter Maydell wrote: > On Wed, 6 Nov 2019 at 12:26, Gerd Hoffmann <kraxel(a)redhat.com> wrote: > > > > The following changes since commit 36609b4fa36f0ac934874371874416f7533a5408: > > > > Merge remote-tracking branch 'remotes/palmer/tags/palmer-for-master-4.2-sf1' into staging (2019-11-02 17:59:03 +0000) > > > > are available in the Git repository at: > > > > git://git.kraxel.org/qemu tags/seabios-20191106-pull-request > > > > for you to fetch changes up to 58b16e57ded751e2e8be626124aad1d46a408a33: > > > > seabios: update to pre-1.13 snapshot (2019-11-06 13:23:02 +0100) > > > > ---------------------------------------------------------------- > > seabios: update to pre-1.13 snapshot > > > > ---------------------------------------------------------------- > > > > Gerd Hoffmann (1): > > seabios: update to pre-1.13 snapshot > > Hi; this fails 'make check' on at least > aarch64, aarch32, FreeBSD, NetBSD, s390: > > ERROR:/home/linux1/qemu/tests/boot-sector.c:161:boot_sector_test: > assertion failed (signature == SIGNATURE): (0x00000000 == 0x0000dead) > ERROR - Bail out! > ERROR:/home/linux1/qemu/tests/boot-sector.c:161:boot_sector_test: > assertion failed (signature == SIGNATURE): (0x00000000 == 0x0000dead) > PASS 9 bios-tables-test /x86_64/acpi/q35/bridge > Aborted (core dumped) > /home/linux1/qemu/tests/Makefile.include:916: recipe for target > 'check-qtest-i386' failed > make: *** [check-qtest-i386] Error 1 > > the x86-64 bootsector tests seem to fail similarly. [ full quote for seabios list ] Re-ran test on x86-64 box -> works. Tried on aarch64 machine -> fails. Given the arch list above this pretty much looks like it is tcg-related, even though a quick check with "qemu -accel tcg -cdrom /some/live/iso" (on x86_64) doesn't show any obvious problems. Recompiled seabios with gcc 4.8 instead of gcc 8 -> Works on both x86-64 and aarch64. -> I'll redo the pull request with that. I'll go try find the root cause next week. On a quick glance this looks like a bug in tcg or gcc. In case anyone has hints what might have caused this drop me a note. thanks, Gerd

1 0

Booting Memtest86+ from CBFS fails
by Martin Kepplinger 08 Nov '19

08 Nov '19

Hi, I use the simple coreboot config https://github.com/merge/skulls/blob/master/x230/free-defconfig-555419f356 on today's coreboot master branch HEAD (403f433238), using SeaBIOS 1.12.1. When choosing memtest86+ in SeaBIOS' menu, "Booting from CBFS" gets printed but nothing else happens. Booting into nvramcui or coreinfo works though. (earlier, at least on coreboot 555419f356, using the same version of SeaBIOS, things were fine). Can you imagine why? thanks, martin

3 2

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS