SeaBIOS

seabios@seabios.org

3783 discussions

Re: [SeaBIOS] [PATCH] virtio-blk/scsi: enable multi-queues support when starting device
by Laszlo Ersek 26 Sep '18

26 Sep '18

On 09/26/18 10:16, Liu, Changpeng wrote: > I posted the patch again, because I didn't get any response since several months ago... :). Indeed, you didn't receive any comments under that (July) posting, regrettably: http://mid.mail-archive.com/1531201226-4099-1-git-send-email-changpeng.liu@… However, prior to that, the topic had been discussed several times. QEMU commit fb20fbb76 is correct, and the idea behind the present patch is wrong. Obviously I'm not a SeaBIOS maintainer, so take my opinion for what it's worth. However, I will definitely not accept a similar patch for OVMF -- it was tried, and I rejected it: https://lists.01.org/pipermail/edk2-devel/2017-December/019131.html (In fact, although the author of the OVMF posting and the author of the QEMU patch were different persons, and it's also unclear whether they worked for the same organization, I suspect that the QEMU patch was actually the direct result of the OVMF discussion.) >> -----Original Message----- >> From: Liu, Changpeng >> Sent: Wednesday, September 26, 2018 4:24 PM >> To: seabios(a)seabios.org >> Cc: stefanha(a)redhat.com; Liu, Changpeng <changpeng.liu(a)intel.com>; Harris, >> James R <james.r.harris(a)intel.com>; Zedlewski, Piotr >> <piotr.zedlewski(a)intel.com>; marcandre.lureau(a)redhat.com >> Subject: [PATCH] virtio-blk/scsi: enable multi-queues support when starting >> device >> >> QEMU will not start all the queues since commit fb20fbb76 >> "vhost: avoid to start/stop virtqueue which is not read", >> because seabios only use one queue when starting, this will >> not work for some vhost slave targets which expect the exact >> number of queues defined in virtio-pci configuration space, This expectation that you spell out in the commit message is what's wrong, in those "vhost slave targets". Thanks Laszlo >> while here, we also enable those queues in the BIOS phase. >> >> Signed-off-by: Changpeng Liu <changpeng.liu(a)intel.com> >> --- >> src/hw/virtio-blk.c | 26 +++++++++++++++++++------- >> src/hw/virtio-ring.h | 1 + >> src/hw/virtio-scsi.c | 28 +++++++++++++++++++--------- >> 3 files changed, 39 insertions(+), 16 deletions(-) >> >> diff --git a/src/hw/virtio-blk.c b/src/hw/virtio-blk.c >> index 88d7e54..79638ec 100644 >> --- a/src/hw/virtio-blk.c >> +++ b/src/hw/virtio-blk.c >> @@ -25,7 +25,7 @@ >> >> struct virtiodrive_s { >> struct drive_s drive; >> - struct vring_virtqueue *vq; >> + struct vring_virtqueue *vq[MAX_NUM_QUEUES]; >> struct vp_device vp; >> }; >> >> @@ -34,7 +34,7 @@ virtio_blk_op(struct disk_op_s *op, int write) >> { >> struct virtiodrive_s *vdrive = >> container_of(op->drive_fl, struct virtiodrive_s, drive); >> - struct vring_virtqueue *vq = vdrive->vq; >> + struct vring_virtqueue *vq = vdrive->vq[0]; >> struct virtio_blk_outhdr hdr = { >> .type = write ? VIRTIO_BLK_T_OUT : VIRTIO_BLK_T_IN, >> .ioprio = 0, >> @@ -96,6 +96,7 @@ virtio_blk_process_op(struct disk_op_s *op) >> static void >> init_virtio_blk(void *data) >> { >> + u32 i, num_queues = 1; >> struct pci_device *pci = data; >> u8 status = VIRTIO_CONFIG_S_ACKNOWLEDGE | VIRTIO_CONFIG_S_DRIVER; >> dprintf(1, "found virtio-blk at %pP\n", pci); >> @@ -109,10 +110,6 @@ init_virtio_blk(void *data) >> vdrive->drive.cntl_id = pci->bdf; >> >> vp_init_simple(&vdrive->vp, pci); >> - if (vp_find_vq(&vdrive->vp, 0, &vdrive->vq) < 0 ) { >> - dprintf(1, "fail to find vq for virtio-blk %pP\n", pci); >> - goto fail; >> - } >> >> if (vdrive->vp.use_modern) { >> struct vp_device *vp = &vdrive->vp; >> @@ -156,6 +153,11 @@ init_virtio_blk(void *data) >> vp_read(&vp->device, struct virtio_blk_config, heads); >> vdrive->drive.pchs.sector = >> vp_read(&vp->device, struct virtio_blk_config, sectors); >> + >> + num_queues = vp_read(&vp->common, virtio_pci_common_cfg, >> num_queues); >> + if (num_queues < 1 || num_queues > MAX_NUM_QUEUES) { >> + num_queues = 1; >> + } >> } else { >> struct virtio_blk_config cfg; >> vp_get_legacy(&vdrive->vp, 0, &cfg, sizeof(cfg)); >> @@ -178,6 +180,13 @@ init_virtio_blk(void *data) >> vdrive->drive.pchs.sector = cfg.sectors; >> } >> >> + for (i = 0; i < num_queues; i++) { >> + if (vp_find_vq(&vdrive->vp, i, &vdrive->vq[i]) < 0 ) { >> + dprintf(1, "fail to find vq %u for virtio-blk %pP\n", i, pci); >> + goto fail_vq; >> + } >> + } >> + >> char *desc = znprintf(MAXDESCSIZE, "Virtio disk PCI:%pP", pci); >> boot_add_hd(&vdrive->drive, desc, bootprio_find_pci_device(pci)); >> >> @@ -185,9 +194,12 @@ init_virtio_blk(void *data) >> vp_set_status(&vdrive->vp, status); >> return; >> >> +fail_vq: >> + for (i = 0; i < num_queues; i++) { >> + free(vdrive->vq[i]); >> + } >> fail: >> vp_reset(&vdrive->vp); >> - free(vdrive->vq); >> free(vdrive); >> } >> >> diff --git a/src/hw/virtio-ring.h b/src/hw/virtio-ring.h >> index 8604a01..3c8a2d1 100644 >> --- a/src/hw/virtio-ring.h >> +++ b/src/hw/virtio-ring.h >> @@ -21,6 +21,7 @@ >> #define VIRTIO_F_IOMMU_PLATFORM 33 >> >> #define MAX_QUEUE_NUM (128) >> +#define MAX_NUM_QUEUES (128) >> >> #define VRING_DESC_F_NEXT 1 >> #define VRING_DESC_F_WRITE 2 >> diff --git a/src/hw/virtio-scsi.c b/src/hw/virtio-scsi.c >> index a87cad8..d08643f 100644 >> --- a/src/hw/virtio-scsi.c >> +++ b/src/hw/virtio-scsi.c >> @@ -148,9 +148,10 @@ virtio_scsi_scan_target(struct pci_device *pci, struct >> vp_device *vp, >> static void >> init_virtio_scsi(void *data) >> { >> + u32 i, num_queues = 3; >> struct pci_device *pci = data; >> dprintf(1, "found virtio-scsi at %pP\n", pci); >> - struct vring_virtqueue *vq = NULL; >> + struct vring_virtqueue *vq[MAX_NUM_QUEUES]; >> struct vp_device *vp = malloc_high(sizeof(*vp)); >> if (!vp) { >> warn_noalloc(); >> @@ -175,29 +176,38 @@ init_virtio_scsi(void *data) >> dprintf(1, "device didn't accept features: %pP\n", pci); >> goto fail; >> } >> + >> + num_queues = vp_read(&vp->common, virtio_pci_common_cfg, >> num_queues); >> + if (num_queues < 3 || num_queues > MAX_NUM_QUEUES) { >> + num_queues = 3; >> + } >> } >> >> - if (vp_find_vq(vp, 2, &vq) < 0 ) { >> - dprintf(1, "fail to find vq for virtio-scsi %pP\n", pci); >> - goto fail; >> + for (i = 0; i < num_queues; i++) { >> + if (vp_find_vq(vp, i, &vq[i]) < 0 ) { >> + dprintf(1, "fail to find vq %u for virtio-scsi %pP\n", i, pci); >> + goto fail; >> + } >> } >> >> status |= VIRTIO_CONFIG_S_DRIVER_OK; >> vp_set_status(vp, status); >> >> - int i, tot; >> + int tot; >> for (tot = 0, i = 0; i < 256; i++) >> - tot += virtio_scsi_scan_target(pci, vp, vq, i); >> + tot += virtio_scsi_scan_target(pci, vp, vq[2], i); >> >> if (!tot) >> - goto fail; >> + goto fail_vq; >> >> return; >> - >> +fail_vq: >> + for (i = 0; i < num_queues; i++) { >> + free(vq[i]); >> + } >> fail: >> vp_reset(vp); >> free(vp); >> - free(vq); >> } >> >> void >> -- >> 1.9.3 > > > _______________________________________________ > SeaBIOS mailing list > SeaBIOS(a)seabios.org > https://mail.coreboot.org/mailman/listinfo/seabios >

2 1

[PATCH] virtio-blk/scsi: enable multi-queues support when starting device
by Changpeng Liu 26 Sep '18

26 Sep '18

QEMU will not start all the queues since commit fb20fbb76 "vhost: avoid to start/stop virtqueue which is not read", because seabios only use one queue when starting, this will not work for some vhost slave targets which expect the exact number of queues defined in virtio-pci configuration space, while here, we also enable those queues in the BIOS phase. Signed-off-by: Changpeng Liu <changpeng.liu(a)intel.com> --- src/hw/virtio-blk.c | 26 +++++++++++++++++++------- src/hw/virtio-ring.h | 1 + src/hw/virtio-scsi.c | 28 +++++++++++++++++++--------- 3 files changed, 39 insertions(+), 16 deletions(-) diff --git a/src/hw/virtio-blk.c b/src/hw/virtio-blk.c index 88d7e54..79638ec 100644 --- a/src/hw/virtio-blk.c +++ b/src/hw/virtio-blk.c @@ -25,7 +25,7 @@ struct virtiodrive_s { struct drive_s drive; - struct vring_virtqueue *vq; + struct vring_virtqueue *vq[MAX_NUM_QUEUES]; struct vp_device vp; }; @@ -34,7 +34,7 @@ virtio_blk_op(struct disk_op_s *op, int write) { struct virtiodrive_s *vdrive = container_of(op->drive_fl, struct virtiodrive_s, drive); - struct vring_virtqueue *vq = vdrive->vq; + struct vring_virtqueue *vq = vdrive->vq[0]; struct virtio_blk_outhdr hdr = { .type = write ? VIRTIO_BLK_T_OUT : VIRTIO_BLK_T_IN, .ioprio = 0, @@ -96,6 +96,7 @@ virtio_blk_process_op(struct disk_op_s *op) static void init_virtio_blk(void *data) { + u32 i, num_queues = 1; struct pci_device *pci = data; u8 status = VIRTIO_CONFIG_S_ACKNOWLEDGE | VIRTIO_CONFIG_S_DRIVER; dprintf(1, "found virtio-blk at %pP\n", pci); @@ -109,10 +110,6 @@ init_virtio_blk(void *data) vdrive->drive.cntl_id = pci->bdf; vp_init_simple(&vdrive->vp, pci); - if (vp_find_vq(&vdrive->vp, 0, &vdrive->vq) < 0 ) { - dprintf(1, "fail to find vq for virtio-blk %pP\n", pci); - goto fail; - } if (vdrive->vp.use_modern) { struct vp_device *vp = &vdrive->vp; @@ -156,6 +153,11 @@ init_virtio_blk(void *data) vp_read(&vp->device, struct virtio_blk_config, heads); vdrive->drive.pchs.sector = vp_read(&vp->device, struct virtio_blk_config, sectors); + + num_queues = vp_read(&vp->common, virtio_pci_common_cfg, num_queues); + if (num_queues < 1 || num_queues > MAX_NUM_QUEUES) { + num_queues = 1; + } } else { struct virtio_blk_config cfg; vp_get_legacy(&vdrive->vp, 0, &cfg, sizeof(cfg)); @@ -178,6 +180,13 @@ init_virtio_blk(void *data) vdrive->drive.pchs.sector = cfg.sectors; } + for (i = 0; i < num_queues; i++) { + if (vp_find_vq(&vdrive->vp, i, &vdrive->vq[i]) < 0 ) { + dprintf(1, "fail to find vq %u for virtio-blk %pP\n", i, pci); + goto fail_vq; + } + } + char *desc = znprintf(MAXDESCSIZE, "Virtio disk PCI:%pP", pci); boot_add_hd(&vdrive->drive, desc, bootprio_find_pci_device(pci)); @@ -185,9 +194,12 @@ init_virtio_blk(void *data) vp_set_status(&vdrive->vp, status); return; +fail_vq: + for (i = 0; i < num_queues; i++) { + free(vdrive->vq[i]); + } fail: vp_reset(&vdrive->vp); - free(vdrive->vq); free(vdrive); } diff --git a/src/hw/virtio-ring.h b/src/hw/virtio-ring.h index 8604a01..3c8a2d1 100644 --- a/src/hw/virtio-ring.h +++ b/src/hw/virtio-ring.h @@ -21,6 +21,7 @@ #define VIRTIO_F_IOMMU_PLATFORM 33 #define MAX_QUEUE_NUM (128) +#define MAX_NUM_QUEUES (128) #define VRING_DESC_F_NEXT 1 #define VRING_DESC_F_WRITE 2 diff --git a/src/hw/virtio-scsi.c b/src/hw/virtio-scsi.c index a87cad8..d08643f 100644 --- a/src/hw/virtio-scsi.c +++ b/src/hw/virtio-scsi.c @@ -148,9 +148,10 @@ virtio_scsi_scan_target(struct pci_device *pci, struct vp_device *vp, static void init_virtio_scsi(void *data) { + u32 i, num_queues = 3; struct pci_device *pci = data; dprintf(1, "found virtio-scsi at %pP\n", pci); - struct vring_virtqueue *vq = NULL; + struct vring_virtqueue *vq[MAX_NUM_QUEUES]; struct vp_device *vp = malloc_high(sizeof(*vp)); if (!vp) { warn_noalloc(); @@ -175,29 +176,38 @@ init_virtio_scsi(void *data) dprintf(1, "device didn't accept features: %pP\n", pci); goto fail; } + + num_queues = vp_read(&vp->common, virtio_pci_common_cfg, num_queues); + if (num_queues < 3 || num_queues > MAX_NUM_QUEUES) { + num_queues = 3; + } } - if (vp_find_vq(vp, 2, &vq) < 0 ) { - dprintf(1, "fail to find vq for virtio-scsi %pP\n", pci); - goto fail; + for (i = 0; i < num_queues; i++) { + if (vp_find_vq(vp, i, &vq[i]) < 0 ) { + dprintf(1, "fail to find vq %u for virtio-scsi %pP\n", i, pci); + goto fail; + } } status |= VIRTIO_CONFIG_S_DRIVER_OK; vp_set_status(vp, status); - int i, tot; + int tot; for (tot = 0, i = 0; i < 256; i++) - tot += virtio_scsi_scan_target(pci, vp, vq, i); + tot += virtio_scsi_scan_target(pci, vp, vq[2], i); if (!tot) - goto fail; + goto fail_vq; return; - +fail_vq: + for (i = 0; i < num_queues; i++) { + free(vq[i]); + } fail: vp_reset(vp); free(vp); - free(vq); } void -- 1.9.3

2 1

Re: [SeaBIOS] [PATCH v2 1/1] SeaVGABios/cbvga: Fix bpp for coreboot framebuffer
by Kevin O'Connor 19 Sep '18

19 Sep '18

On Tue, Sep 11, 2018 at 09:29:39PM -0500, Matt DeVillier wrote: > Commit 4b42cc4 [SeaVGABios/cbvga: Advertise correct pixel format] neglected > to wrap the cbfb mask size components in GET_FARVAR(), which resulted in a > bogus value for bpp, breaking output on most/all devices. Fix this by > adding GET_FARVAR() as appropriate. > > Additionally, some newer ChromeOS devices still fail even with this fix, > so fall back to using the coreboot reported bit depth if the calculated > valid is invalid. Thanks. I committed this change. -Kevin

1 0

[PATCH] - Add total usable memory to startup console output
by Damien Zammit 15 Sep '18

15 Sep '18

Hi folks, I want to put forth this patch for your review. In my opinion, it is very useful to know just after your machine has POSTed how much system RAM the machine has access to. This patch prints out to the screen just under the UUID the following line: System RAM: X MB where X is the number of whole megabytes available to the system. Since the memory map is already available to SeaBIOS, I think it makes sense to total up the sizes of regions marked as E820_RAM and print the grand total. I have tested this on a coreboot QEMU bios with custom SeaBIOS built: SeaBIOS (version rel-1.11.0-46-g18e193d) System RAM: 1022 MB When I tried flashing a compatible image to my Lenovo X220 laptop it bricked it. I'm not sure why, maybe I compiled it wrong or inserted it into my image wrongly with cbfstool. Cheers, Damien

2 1

[PATCH v3 0/3] pci: resource reserve capability found
by Jing Liu 14 Sep '18

14 Sep '18

This patch serial is about QEMU resource reserve capability finding in firmware. Firstly, this fixes a logic bug. When the capability is truncated, return zero instead of the truncated offset. Secondly, this modified the debug messages when the capability is not found and when the vendor ID or device Id doesn't match REDHAT special ones. Last, this enables the firmware recongizing the REDHAT PCI BRIDGE device ID, and changes the debug level to 3 when it is non-qemu bridge. Change Log: v2 -> v1 * Add two patches for fixing small bugs v3 -> v2 * Change the debug level Jing Liu (3): pci: fix the return value for truncated capability pci: clean up the debug message for pci capability found pci: recognize RH PCI legacy bridge resource reservation capability src/fw/pciinit.c | 45 ++++++++++++++++++++++++++++----------------- src/hw/pci_ids.h | 1 + 2 files changed, 29 insertions(+), 17 deletions(-) -- 1.8.3.1

6 12

[PATCH v2 1/1] SeaVGABios/cbvga: Fix bpp for coreboot framebuffer
by Matt DeVillier 12 Sep '18

12 Sep '18

>From 3e41f058836cd920ab67463d361b11a11729b390 Mon Sep 17 00:00:00 2001 From: Matt DeVillier <matt.devillier(a)puri.sm> Date: Tue, 11 Sep 2018 16:54:53 -0500 Subject: [PATCH v2 1/1] SeaVGABios/cbvga: Fix bpp for coreboot framebuffer Commit 4b42cc4 [SeaVGABios/cbvga: Advertise correct pixel format] neglected to wrap the cbfb mask size components in GET_FARVAR(), which resulted in a bogus value for bpp, breaking output on most/all devices. Fix this by adding GET_FARVAR() as appropriate. Additionally, some newer ChromeOS devices still fail even with this fix, so fall back to using the coreboot reported bit depth if the calculated valid is invalid. TEST: build/boot a variety of devices (google/[reef,eve], purism/librem_skl) using coreboot framebuffer init, verify SeaBIOS boot menu prompt visible. Signed-off-by: Matt DeVillier <matt.devillier(a)puri.sm> --- vgasrc/cbvga.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/vgasrc/cbvga.c b/vgasrc/cbvga.c index 859524c..438d8fd 100644 --- a/vgasrc/cbvga.c +++ b/vgasrc/cbvga.c @@ -312,11 +312,17 @@ cbvga_setup(void) } u64 addr = GET_FARVAR(0, cbfb->physical_address); - u8 bpp = cbfb->blue_mask_size + cbfb->green_mask_size - + cbfb->red_mask_size + cbfb->reserved_mask_size; + u8 bpp = GET_FARVAR(0, cbfb->blue_mask_size) + + GET_FARVAR(0, cbfb->green_mask_size) + + GET_FARVAR(0, cbfb->red_mask_size) + + GET_FARVAR(0, cbfb->reserved_mask_size); u32 xlines = GET_FARVAR(0, cbfb->x_resolution); u32 ylines = GET_FARVAR(0, cbfb->y_resolution); u32 linelength = GET_FARVAR(0, cbfb->bytes_per_line); + //fall back to coreboot reported bpp if calculated value invalid + if (bpp != 15 && bpp != 16 && bpp != 24 && bpp != 32) + bpp = GET_FARVAR(0, cbfb->bits_per_pixel); + dprintf(1, "Found FB @ %llx %dx%d with %d bpp (%d stride)\n" , addr, xlines, ylines, bpp, linelength); -- 2.17.1

1 0

[PATCH 1/1] SeaVGABios/cbvga: Fix bpp for coreboot framebuffer
by Matt DeVillier 12 Sep '18

12 Sep '18

>From 52191d4f83fe9e3fa47ec2f9ee98aec83304a8f6 Mon Sep 17 00:00:00 2001 From: Matt DeVillier <matt.devillier(a)puri.sm> Date: Tue, 11 Sep 2018 16:54:53 -0500 Subject: [PATCH 1/1] SeaVGABios/cbvga: Fix bpp for coreboot framebuffer Commit 4b42cc4 [SeaVGABios/cbvga: Advertise correct pixel format] neglected to wrap the cbfb mask size components in GET_FARVAR(), which resulted in a bogus value for bpp, breaking output on most/all devices. Fix this by adding GET_FARVAR() as appropriate. TEST: build/boot a variety of devices (google/fizz, purism/librem_skl) using coreboot for display init, verify SeaBIOS banner and boot menu prompt visible. Signed-off-by: Matt DeVillier <matt.devillier(a)puri.sm> --- vgasrc/cbvga.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/vgasrc/cbvga.c b/vgasrc/cbvga.c index 859524c..d64625e 100644 --- a/vgasrc/cbvga.c +++ b/vgasrc/cbvga.c @@ -312,8 +312,10 @@ cbvga_setup(void) } u64 addr = GET_FARVAR(0, cbfb->physical_address); - u8 bpp = cbfb->blue_mask_size + cbfb->green_mask_size - + cbfb->red_mask_size + cbfb->reserved_mask_size; + u8 bpp = GET_FARVAR(0, cbfb->blue_mask_size) + + GET_FARVAR(0, cbfb->green_mask_size) + + GET_FARVAR(0, cbfb->red_mask_size) + + GET_FARVAR(0, cbfb->reserved_mask_size); u32 xlines = GET_FARVAR(0, cbfb->x_resolution); u32 ylines = GET_FARVAR(0, cbfb->y_resolution); u32 linelength = GET_FARVAR(0, cbfb->bytes_per_line); -- 2.17.1

1 0

Re: [SeaBIOS] Failure to detect high-capacity SD card
by Kevin O'Connor 04 Sep '18

04 Sep '18

On Fri, Aug 24, 2018 at 10:45:55AM -0400, Chris wrote: > On Fri, Aug 24, 2018 at 10:28 AM, Kevin O'Connor <kevin(a)koconnor.net> wrote: > > On Fri, Aug 24, 2018 at 09:48:27AM -0400, Chris wrote: > >> On Fri, Aug 24, 2018 at 9:28 AM, Chris <coderight(a)gmail.com> wrote: > >> > So far it has worked on the first attempt every time. So it needs only > >> > the delay and nothing else. > >> > > >> > I still need to test with all my SD cards. Though I only have a 64GB > >> > Sandisk and a handful of 32GB Samsung. The question is whether or not > >> > the delay is dependent on the card type or if it's just the controller > >> > that needs to stabilize. > >> > >> OK, I tested all the cards I have and everything works. Attached is > >> the simplified patch. Hopefully someone can test other cards. I'm > >> interested to know if 128+GB and 16GB works. > > > > Thanks. If you increase SDHCI_POWER_ON_TIME instead, does that also > > work? > > > > -Kevin > > Yes. Seems to work the same so far using the same delay (5). Thanks. I committed this change. -Kevin

2 1

Error Data Hob
by zahra rahimkhani 30 Aug '18

30 Aug '18

Hello Friends , I compiled Coreboot 4.5 and seabios for Minnow board max and see this message in consol. "Memory Configure Data Hob is not present. Not updating MRC data in flash." what is Data Hob? what is MRC data؟ Cold you help me how to solve it? Best wishes , Zhara

1 0

Backport request for 8c3f57ea12
by Wei Liu 29 Aug '18

29 Aug '18

Hello I notice 1.11.2 was only released a few weeks ago so it is probably too early for another release, but can maintainers at least consider backporting 8c3f57ea12 to 1.11-stable branch? Thanks, Wei.

2 2

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS