SeaBIOS

seabios@seabios.org

3783 discussions

[PATCH v2 0/9] add support for generic lun enumeration
by Roman Kagan 03 May '17

03 May '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 Signed-off-by: Roman Kagan <rkagan(a)virtuozzo.com> --- v1 -> v2: - use malloc_tmp instead of malloc_high - format the retry logic as a regular while{} loop - I left the interface as in v1 as the alternatives looked heavier - patches 1,3-9 are unchanged src/hw/blockcmd.h | 4 +++ src/hw/blockcmd.c | 97 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 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, 236 insertions(+), 64 deletions(-) -- 2.9.3

2 10

[PATCH] coreboot: Adapt to upstream CBMEM console changes
by Julius Werner 26 Apr '17

26 Apr '17

coreboot's CBMEM console format changed with https://review.coreboot.org/#/c/18301. This patch adapts the SeaBIOS implementation to support the new format. (SeaBIOS versions with this patch will continue to work fine with older version of coreboot. SeaBIOS versions without this patch may fail to log messages to the CBMEM console if run with newer versions of coreboot, but should not experience any more serious issues than that.) Signed-off-by: Julius Werner <jwerner(a)chromium.org> --- src/fw/coreboot.c | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-) diff --git a/src/fw/coreboot.c b/src/fw/coreboot.c index 4957b80..7214f8a 100644 --- a/src/fw/coreboot.c +++ b/src/fw/coreboot.c @@ -80,10 +80,12 @@ struct cb_cbmem_ref { #define CB_TAG_CBMEM_CONSOLE 0x17 struct cbmem_console { - u32 buffer_size; - u32 buffer_cursor; - u8 buffer_body[0]; + u32 size; + u32 cursor; + u8 body[0]; } PACKED; +#define CBMC_CURSOR_MASK ((1 << 28) - 1) +#define CBMC_OVERFLOW (1 << 31) static struct cbmem_console *cbcon = NULL; static u16 @@ -220,9 +222,16 @@ void coreboot_debug_putc(char c) return; if (!cbcon) return; - u32 cursor = cbcon->buffer_cursor++; - if (cursor < cbcon->buffer_size) - cbcon->buffer_body[cursor] = c; + u32 cursor = cbcon->cursor & CBMC_CURSOR_MASK; + u32 flags = cbcon->cursor & ~CBMC_CURSOR_MASK; + if (cursor >= cbcon->size) + return; // Old coreboot version with legacy overflow mechanism. + cbcon->body[cursor++] = c; + if (cursor >= cbcon->size) { + cursor = 0; + flags |= CBMC_OVERFLOW; + } + cbcon->cursor = flags | cursor; } /**************************************************************** -- 2.12.2.816.g2cccc81164-goog

2 1

Re: [SeaBIOS] [coreboot] RFC: Changing CBMEM console to run as a persistent ring-buffer
by Paul Menzel 22 Apr '17

22 Apr '17

[For the GRUB folks, this is about coreboot commit d67c6876 (Turn CBMEM console into a ring buffer that can persist across reboots) [1]. Julius’ message can be find in the coreboot list archive [2].] Dear Julius, Am Montag, den 10.04.2017, 15:50 -0700 schrieb Julius Werner: […] > The change may also cause some hiccups if you're using a newer version of > coreboot with an older version of cbmem (or SeaBIOS or whatever else reads > the console): it will not crash and it will still print the whole log, but > if the log has rolled over (into "ring buffer mode") it will print lines > out of order. This is unfortunately the best I can do with the way current > readers are implemented. I'm of course also updating the code for cbmem so > as soon as you deploy the new version it will be able to display buffers > from both old and new coreboot versions correctly. (I'll send patches to > align SeaBIOS and the Linux memconsole driver in the same manner as soon as > the coreboot patch is approved.) Could you please also check, if GRUB’s CBMEM console driver, and the the command cbmemc to display it need any updates? Thanks, Paul PS: Where can I get your S/MIME certificate, used to sign your email? [1] https://review.coreboot.org/18301 [2] https://mail.coreboot.org/pipermail/coreboot/2017-April/083950.html

1 0

PCI regions mapping problem
by Stas Sergeev 22 Apr '17

22 Apr '17

Hello. I tried seabios on an emulator (not qemu) and faced the PCI memory regions overlap. After some debugging I came to the conclusion that seabios simply forgets to align the base addresses, and as the result, when the device aligns the address down by clearing the "dont care" bits, it can overlap the previous region. I fixed the problem with the attached simple patch. Still it is hard to believe such a bug can exist, so I wonder if I am missing something. Any suggestions to where should I dig to narrow the problem further? Or can it be that seabios actually has the bug like that and no one have noticed? :)

2 2

BootDevice description cut off
by Rene Shuster 22 Apr '17

22 Apr '17

Please change line 485 of src/boot.c and increase the BootDevice description length 'char desc' value from [60] to [80]. Right now it's cutting off text for some devices. 80 would most likely fix the issue and provide enough space for very lengthy descriptions. Example shown here: https://github.com/coreboot/seabios/pull/1 Thanks. -- Tech III * AppControl * Endpoint Protection * Server Maintenance Buncombe County Schools Technology Department Network Group ComicSans Awareness Campaign <http://comicsanscriminal.com>

1 0

does virtio-pci support more queues?
by Zhenwei Pi 21 Apr '17

21 Apr '17

Hi, I did a very simple test : 1, modify qemu/hw/block/virtio-blk.c, let virtio-blk use 256 queue: *s->vq = virtio_add_queue(vdev, 128, virtio_blk_handle_output);* --> *s->vq = virtio_add_queue(vdev, 256 , virtio_blk_handle_output);* ** 2, compile qemu and run a VM which boots from virtio-blk disk. The VM can NOT boot because seabios use macro MAX_QUEUE_NUM as 128. So, does virtio-pci support more queues? Looking forward your reply! -- Rather than love ,than money ,than faith,than fame,than fairness,give me truth.

2 1

Re: [SeaBIOS] [coreboot] RFC: Changing CBMEM console to run as a persistent ring-buffer
by Gerd Hoffmann 13 Apr '17

13 Apr '17

Hi, > Right, sorry, I confused something while writing the explanation > there. Nevertheless, the SeaBIOS code will require a small adjustment > (same as the libpayload driver in the patch I linked) to continue > appending correctly after the log has rolled over, and I'll provide > that patch. Is it possible to figure whenever the cbmem buffer supports rollover or not, so a updated seabios version can work correctly with both old and new coreboot? cheers, Gerd

2 1

Re: [SeaBIOS] [coreboot] RFC: Changing CBMEM console to run as a persistent ring-buffer
by Haleigh Novak 12 Apr '17

12 Apr '17

Hello, Will the ability to change the 'Room allocated for console output in CBMEM' size still be available (and functional) for those need to view the full console output due to the addition of debugging/tracing lines? HN ________________________________ From: coreboot <coreboot-bounces(a)coreboot.org> on behalf of Julius Werner via coreboot <coreboot(a)coreboot.org> Sent: Monday, April 10, 2017 3:50 PM To: Coreboot; seabios(a)seabios.org Subject: [coreboot] RFC: Changing CBMEM console to run as a persistent ring-buffer Hi folks, I'm planning to make some changes to coreboot's CBMEM console with https://review.coreboot.org/#/c/18301 that should make it easier to debug problems spanning multiple reboots. I'm trying my best to avoid breaking previous behavior and keeping it compatible with older code, but there'll be some edge cases so Aaron suggested I announce it here. The basic idea is to turn the console into a persistent ring buffer. If coreboot finds an already initialized console in memory during boot, it will just continue appending to it rather than begin writing from the start of the buffer again. This means that if you run cbmem -c, the most recent boot will always be at the bottom of the output, and you can scroll further up to see logs from the boot before that (assuming you didn't lose DRAM power or something). It may also give some runtime firmware components (like we have on ARM64) a good place to log stuff and persist crash dumps in the future. The console buffer will fill up eventually with enough reboots, so when that happens we will start discarding the oldest lines from the log. This means the behavior if the log buffer is too small for even a single full boot will become slightly different: we'll only keep the latest lines, whereas previously we would only keep the earliest lines and a counter of dropped characters. I don't think this should be an issue though, since we normally should have enough buffer to fit a whole boot anyway (the default is currently 128KB which ought to be enough for any board). The change may also cause some hiccups if you're using a newer version of coreboot with an older version of cbmem (or SeaBIOS or whatever else reads the console): it will not crash and it will still print the whole log, but if the log has rolled over (into "ring buffer mode") it will print lines out of order. This is unfortunately the best I can do with the way current readers are implemented. I'm of course also updating the code for cbmem so as soon as you deploy the new version it will be able to display buffers from both old and new coreboot versions correctly. (I'll send patches to align SeaBIOS and the Linux memconsole driver in the same manner as soon as the coreboot patch is approved.) Let me know if you have any concerns about this.

2 1

Re: [SeaBIOS] RFC: Changing CBMEM console to run as a persistent ring-buffer
by Gerd Hoffmann 11 Apr '17

11 Apr '17

Hi, > The change may also cause some hiccups if you're using a newer version > of coreboot with an older version of cbmem (or SeaBIOS or whatever > else reads the console): seabios doesn't read the log, instead it'll append its own messages. Which I expect will continue to work fine, except when it hits the end of the log buffer, where seabios will simply stop logging instead of rolling over. cheers, Gerd

1 0

RFC: Changing CBMEM console to run as a persistent ring-buffer
by Julius Werner 11 Apr '17

11 Apr '17

Hi folks, I'm planning to make some changes to coreboot's CBMEM console with https://review.coreboot.org/#/c/18301 that should make it easier to debug problems spanning multiple reboots. I'm trying my best to avoid breaking previous behavior and keeping it compatible with older code, but there'll be some edge cases so Aaron suggested I announce it here. The basic idea is to turn the console into a persistent ring buffer. If coreboot finds an already initialized console in memory during boot, it will just continue appending to it rather than begin writing from the start of the buffer again. This means that if you run cbmem -c, the most recent boot will always be at the bottom of the output, and you can scroll further up to see logs from the boot before that (assuming you didn't lose DRAM power or something). It may also give some runtime firmware components (like we have on ARM64) a good place to log stuff and persist crash dumps in the future. The console buffer will fill up eventually with enough reboots, so when that happens we will start discarding the oldest lines from the log. This means the behavior if the log buffer is too small for even a single full boot will become slightly different: we'll only keep the latest lines, whereas previously we would only keep the earliest lines and a counter of dropped characters. I don't think this should be an issue though, since we normally should have enough buffer to fit a whole boot anyway (the default is currently 128KB which ought to be enough for any board). The change may also cause some hiccups if you're using a newer version of coreboot with an older version of cbmem (or SeaBIOS or whatever else reads the console): it will not crash and it will still print the whole log, but if the log has rolled over (into "ring buffer mode") it will print lines out of order. This is unfortunately the best I can do with the way current readers are implemented. I'm of course also updating the code for cbmem so as soon as you deploy the new version it will be able to display buffers from both old and new coreboot versions correctly. (I'll send patches to align SeaBIOS and the Linux memconsole driver in the same manner as soon as the coreboot patch is approved.) Let me know if you have any concerns about this.

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS