SeaBIOS

seabios@seabios.org

4 participants
3800 discussions

acer c720 microcode
by Roberto Simonini 22 Aug '18

22 Aug '18

I have acer c720 with seabios and ubuntu both wifi and lan no longer work since then I do not have the network able to flash the seabios. is there a ROM version that can be downloaded but flash without a network? I also have the following message at startup: ...tsc-to deadline disable due to errata ...update microcode...unable to read hardware clock grazie robrto simonini

1 0

Boot failed: could not read from CDROM-Blu-ray Disc
by CarlosGonzalez 22 Aug '18

22 Aug '18

Hello there I am using seabios with coreboot, but I have an issue on booting CD-ROM. I have a CD-ROM-Blu-ray-Disc the problem is when is booting seabios this is showing an error message on CD-ROM then I need fix that ugly message. Seabios detect my CD-ROM y booting as well but I do not know why is showing the "failed to learn CD_ROM". Will nice fix the issue Thanks . ##this screenshot is when the cd-driver NOT have a cd-image inserted## [20180714_172630.jpg] ##this screenshot is when the cd-driver have a cd-image inserted## [20180822_124130.jpg]

1 0

Re: [SeaBIOS] acer c720 microcode
by Matt DeVillier 22 Aug '18

22 Aug '18

I think you're conflating a lot of different things here. I'm assuming you are running a 3rd party firmware on your device which boots SeaBIOS as its payload. Wifi/LAN not working are unlikely to be firmware related, so flashing something else isn't going to help. The 'update microcode' message is just that, Linux is updating your microcode as part of booting. There's no problem which needs fixing. Assuming the problem you are trying to solve is lack of network connectivity on your device, the best resource for that is going to be some place that deals with hacking Chromebooks, like https://www.reddit.com/r/chrultrabook/. But it's not a SeaBIOS issue in any way. On Wed, Aug 22, 2018 at 10:03 AM Roberto Simonini <robertosimonini(a)gmail.com> wrote: > I have acer c720 with seabios and ubuntu both wifi and lan no longer work since then > I do not have the network able to flash the seabios. is there a ROM version that can be downloaded but flash without a network? > I also have the following message at startup: ...tsc-to deadline disable due to errata ...update microcode...unable to read hardware clock > > grazie robrto simonini > > _______________________________________________ > SeaBIOS mailing list > SeaBIOS(a)seabios.org > https://mail.coreboot.org/mailman/listinfo/seabios

1 0

Re: [SeaBIOS] [SEABIOS] [PATCH 1/1] nvme: fix I/O queue length calculation overflow
by Matt DeVillier 21 Aug '18

21 Aug '18

>From 2741d96d07855c3bc904d6ce47c82391039bca87 Mon Sep 17 00:00:00 2001 From: Matt DeVillier <matt.devillier(a)puri.sm> Date: Tues, 21 Aug 2018 10:00:53 -0500 Subject: [PATCH v2 1/1] nvme: fix I/O queue length calculation overflow Commit cd47172 changed the I/O queue length calculation to use the Maximum Queue Entries Supported (MQES) value from the capabilities register, plus one, with a maximum value of NVME_PAGE_SIZE. An unintended effect from this is that due to length being an unsigned 16-bit int, a MQES value of 0xFFFF yields a length of zero, resulting in the queue allocation failing. Fix this by changing length to a u32. TEST: build/boot on a Purism Librem13v2 with a MyDigitalSSD BPX NVMe drive, which reports a MQES of 0xFFFF. Verify NVMe drive present in boot menu and OS boots successfully. Signed-off-by: Matt DeVillier <matt.devillier(a)puri.sm> --- src/hw/nvme.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/hw/nvme.c b/src/hw/nvme.c index e6d739d..2e3aa38 100644 --- a/src/hw/nvme.c +++ b/src/hw/nvme.c @@ -318,7 +318,7 @@ nvme_create_io_cq(struct nvme_ctrl *ctrl, struct nvme_cq *cq, u16 q_idx) { int rc; struct nvme_sqe *cmd_create_cq; - u16 length = 1 + (ctrl->reg->cap & 0xffff); + u32 length = 1 + (ctrl->reg->cap & 0xffff); if (length > NVME_PAGE_SIZE / sizeof(struct nvme_cqe)) length = NVME_PAGE_SIZE / sizeof(struct nvme_cqe); @@ -362,7 +362,7 @@ nvme_create_io_sq(struct nvme_ctrl *ctrl, struct nvme_sq *sq, u16 q_idx, struct { int rc; struct nvme_sqe *cmd_create_sq; - u16 length = 1 + (ctrl->reg->cap & 0xffff); + u32 length = 1 + (ctrl->reg->cap & 0xffff); if (length > NVME_PAGE_SIZE / sizeof(struct nvme_cqe)) length = NVME_PAGE_SIZE / sizeof(struct nvme_cqe); -- 2.17.1 On Tue, Aug 21, 2018 at 6:52 AM Matt DeVillier <matt.devillier(a)gmail.com> wrote: > On Mon, Aug 20, 2018 at 11:16 PM Kevin O'Connor <kevin(a)koconnor.net> > wrote: > >> On Sun, Aug 12, 2018 at 03:42:40PM -0500, Matt DeVillier wrote: >> > Commit cd47172 changed the I/O queue length calculation to use the >> > Maximum Queue Entries Supported (MQES) value from the capabilities >> > register, plus one, with a maximum value of NVME_PAGE_SIZE. >> > >> > An unintended effect from this is that a MQES value of 0xFFFF yields >> > a length of zero, resulting in the queue allocation failing. Fix this >> > by checking for a zero length when checking that the length exceeds >> > NVME_PAGE_SIZE, and setting to NVME_PAGE_SIZE. >> > >> > TEST: build/boot on a Purism Librem13v2 with a MyDigitalSSD BPX NVMe >> > drive, which reports a MQES of 0xFFFF. Verify NVMe drive present in >> > boot menu and OS boots successfully. >> > >> > Signed-off-by: Matt DeVillier <matt.devillier(a)gmail.com> >> > --- >> > src/hw/nvme.c | 4 ++-- >> > 1 file changed, 2 insertions(+), 2 deletions(-) >> > >> > diff --git a/src/hw/nvme.c b/src/hw/nvme.c >> > index e6d739d..c2d6863 100644 >> > --- a/src/hw/nvme.c >> > +++ b/src/hw/nvme.c >> > @@ -319,7 +319,7 @@ nvme_create_io_cq(struct nvme_ctrl *ctrl, struct >> > nvme_cq *cq, u16 q_idx) >> > int rc; >> > struct nvme_sqe *cmd_create_cq; >> > u16 length = 1 + (ctrl->reg->cap & 0xffff); >> > - if (length > NVME_PAGE_SIZE / sizeof(struct nvme_cqe)) >> > + if (length == 0 || length > NVME_PAGE_SIZE / sizeof(struct >> nvme_cqe)) >> > length = NVME_PAGE_SIZE / sizeof(struct nvme_cqe); >> >> Thanks. Instead of changing the if statement, could we just change >> length here to a u32 to avoid this issue? >> > > I can't think of why not, I'll test this method and submit an updated > patchset if so - thanks! > > >> >> > >> > rc = nvme_init_cq(ctrl, cq, q_idx, length); >> > @@ -363,7 +363,7 @@ nvme_create_io_sq(struct nvme_ctrl *ctrl, struct >> > nvme_sq *sq, u16 q_idx, struct >> > int rc; >> > struct nvme_sqe *cmd_create_sq; >> > u16 length = 1 + (ctrl->reg->cap & 0xffff); >> > - if (length > NVME_PAGE_SIZE / sizeof(struct nvme_cqe)) >> > + if (length == 0 || length > NVME_PAGE_SIZE / sizeof(struct >> nvme_cqe)) >> > length = NVME_PAGE_SIZE / sizeof(struct nvme_cqe); >> > >> > rc = nvme_init_sq(ctrl, sq, q_idx, length, cq); >> > -- >> > 2.17.1 >> >> -Kevin >> >

1 0

Certificate expired for https://git.seabios.org
by Wei Liu 21 Aug '18

21 Aug '18

Hello In case nobody noticed: the certificate for git.seabios.org has expired during the weekend. Maybe certbot is on vacation? :-) Regards, Wei.

3 5

Re: [SeaBIOS] [SEABIOS] [PATCH 1/1] nvme: fix I/O queue length calculation overflow
by Kevin O'Connor 21 Aug '18

21 Aug '18

On Sun, Aug 12, 2018 at 03:42:40PM -0500, Matt DeVillier wrote: > Commit cd47172 changed the I/O queue length calculation to use the > Maximum Queue Entries Supported (MQES) value from the capabilities > register, plus one, with a maximum value of NVME_PAGE_SIZE. > > An unintended effect from this is that a MQES value of 0xFFFF yields > a length of zero, resulting in the queue allocation failing. Fix this > by checking for a zero length when checking that the length exceeds > NVME_PAGE_SIZE, and setting to NVME_PAGE_SIZE. > > TEST: build/boot on a Purism Librem13v2 with a MyDigitalSSD BPX NVMe > drive, which reports a MQES of 0xFFFF. Verify NVMe drive present in > boot menu and OS boots successfully. > > Signed-off-by: Matt DeVillier <matt.devillier(a)gmail.com> > --- > src/hw/nvme.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/src/hw/nvme.c b/src/hw/nvme.c > index e6d739d..c2d6863 100644 > --- a/src/hw/nvme.c > +++ b/src/hw/nvme.c > @@ -319,7 +319,7 @@ nvme_create_io_cq(struct nvme_ctrl *ctrl, struct > nvme_cq *cq, u16 q_idx) > int rc; > struct nvme_sqe *cmd_create_cq; > u16 length = 1 + (ctrl->reg->cap & 0xffff); > - if (length > NVME_PAGE_SIZE / sizeof(struct nvme_cqe)) > + if (length == 0 || length > NVME_PAGE_SIZE / sizeof(struct nvme_cqe)) > length = NVME_PAGE_SIZE / sizeof(struct nvme_cqe); Thanks. Instead of changing the if statement, could we just change length here to a u32 to avoid this issue? > > rc = nvme_init_cq(ctrl, cq, q_idx, length); > @@ -363,7 +363,7 @@ nvme_create_io_sq(struct nvme_ctrl *ctrl, struct > nvme_sq *sq, u16 q_idx, struct > int rc; > struct nvme_sqe *cmd_create_sq; > u16 length = 1 + (ctrl->reg->cap & 0xffff); > - if (length > NVME_PAGE_SIZE / sizeof(struct nvme_cqe)) > + if (length == 0 || length > NVME_PAGE_SIZE / sizeof(struct nvme_cqe)) > length = NVME_PAGE_SIZE / sizeof(struct nvme_cqe); > > rc = nvme_init_sq(ctrl, sq, q_idx, length, cq); > -- > 2.17.1 -Kevin

2 1

Fwd: Fwd: [RFC 0/2] (Ongoing)Support multiple pci domains in pci_device
by Zihan Yang 21 Aug '18

21 Aug '18

---------- Forwarded message --------- From: Zihan Yang <whois.zihan.yang(a)gmail.com> Date: 2018年8月21日周二上午10:34 Subject: Re: [SeaBIOS] Fwd: [RFC 0/2] (Ongoing)Support multiple pci domains in pci_device To: Kevin OConnor <kevin(a)koconnor.net> Kevin O'Connor <kevin(a)koconnor.net> 于2018年8月21日周二上午4:24写道： > > On Thu, Aug 09, 2018 at 07:44:22AM +0800, Zihan Yang wrote: > > Kevin O'Connor <kevin(a)koconnor.net> 于2018年8月8日周三下午10:14写道： > > > On Thu, Aug 02, 2018 at 10:39:13AM +0800, Zihan Yang wrote: > > > > NOTE: This patch set is still ongoing and does not fully function > > > > as its goal. But it involves some API changes, therefore I post them for > > > > comments before moving on to make sure I'm on the right path. > > > > > > > > The corresponding qemu part can be found at > > > > https://gitlab.com/WhoisZihan/qemu-pci-domain/tree/master/qemu > > > > I will submit it to qemu list later. > > > > > > > > Currently seabios assumes there is only one pci domain(0), and almost > > > > everything operates on pci domain 0 by default. This patch aims to add > > > > multiple pci domain support for pci_device, while reserve the original > > > > API for compatibility. > > > > > > Thanks. I understand the desire to support multiple PCI domains in > > > QEMU and the guest OS. However, what is the high level reason for > > > wanting the BIOS to be able to interact with the secondary PCI > > > domains? > > > > The pxb-pcie host bus is put into a separated domain, so are the devices > > under the pxb host bus. I think we should also initialize busses in other > > domains and probe those devices during bios initialization. But currently > > qemu only binds port 0xcf8 and 0xcfc to q35 host's conf_mem and data_mem, > > if we want to read the config space of pxb host, we should use another port. > > I use port range 0x1000 and 0x1004 for a temporary workaround because they > > seem to be 'free' now. > > The patchset is quite large and touches a large amount of code in > different parts of SeaBIOS. I'd like to understand the high-level, > user-visible, reason for making the change. What important > capabilities will a user be unable to accomplish if we don't make this > change? The restriction is that pcie topology limits one pcie device per bus, and there are at most 256 buses in a pci domain/segment. Currently the pxb host are still inside the same domain with q35, and the buses will run out if there are many pcie devices. This patch set aims to let users be able to put these 'extra' devices into separate pci domains to overcome the limitation of bus numbers in a single domain. > As far as I know, there is no standard for accessing PCI besides the > main one at cf8/cfc - so I'm not sure there is a good solution to this > problem. Perhaps it would be easier for users to always put their > boot devices on the main PCI. Yes, seabios reads pci config space only through 0xcf8/0xcfc, it seems currently seabios does not seperate pcie devices from pci devices. This patch is just an temporary workaround, maybe we can replace it with mmio later but I think that would involve many changes to seabios too. > Thanks, > -Kevin

1 0

Re: [SeaBIOS] Fwd: [RFC 0/2] (Ongoing)Support multiple pci domains in pci_device
by Kevin O'Connor 21 Aug '18

21 Aug '18

On Thu, Aug 09, 2018 at 07:44:22AM +0800, Zihan Yang wrote: > Kevin O'Connor <kevin(a)koconnor.net> 于2018年8月8日周三下午10:14写道： > > On Thu, Aug 02, 2018 at 10:39:13AM +0800, Zihan Yang wrote: > > > NOTE: This patch set is still ongoing and does not fully function > > > as its goal. But it involves some API changes, therefore I post them for > > > comments before moving on to make sure I'm on the right path. > > > > > > The corresponding qemu part can be found at > > > https://gitlab.com/WhoisZihan/qemu-pci-domain/tree/master/qemu > > > I will submit it to qemu list later. > > > > > > Currently seabios assumes there is only one pci domain(0), and almost > > > everything operates on pci domain 0 by default. This patch aims to add > > > multiple pci domain support for pci_device, while reserve the original > > > API for compatibility. > > > > Thanks. I understand the desire to support multiple PCI domains in > > QEMU and the guest OS. However, what is the high level reason for > > wanting the BIOS to be able to interact with the secondary PCI > > domains? > > The pxb-pcie host bus is put into a separated domain, so are the devices > under the pxb host bus. I think we should also initialize busses in other > domains and probe those devices during bios initialization. But currently > qemu only binds port 0xcf8 and 0xcfc to q35 host's conf_mem and data_mem, > if we want to read the config space of pxb host, we should use another port. > I use port range 0x1000 and 0x1004 for a temporary workaround because they > seem to be 'free' now. The patchset is quite large and touches a large amount of code in different parts of SeaBIOS. I'd like to understand the high-level, user-visible, reason for making the change. What important capabilities will a user be unable to accomplish if we don't make this change? As far as I know, there is no standard for accessing PCI besides the main one at cf8/cfc - so I'm not sure there is a good solution to this problem. Perhaps it would be easier for users to always put their boot devices on the main PCI. Thanks, -Kevin

1 0

Re: [SeaBIOS] enable log path of devices in seabios
by Kevin O'Connor 21 Aug '18

21 Aug '18

On Thu, Aug 09, 2018 at 12:00:49AM -0300, zahra rahimkhani wrote: > Hello Friends > > I want to enable a log that show path of devices that by seabios was > recognize . > this paths are different from boot default paths. > > Could you suggest me a advice? There's some info on generating a log file at: https://www.seabios.org/Debugging -Kevin

1 0

Re: [SeaBIOS] [Qemu-devel] [PATCH v2 0/3] hw/pci: PCI resource reserve capability
by Laszlo Ersek 17 Aug '18

17 Aug '18

Hi, On 08/16/18 11:28, Jing Liu wrote: > This patch serial is about PCI resource reserve capability. > > First patch refactors the resource reserve fields in GenPCIERoorPort > structure out to another new structure, called "PCIResReserve". Modify > the parameter list of pci_bridge_qemu_reserve_cap_init(). > > Then we add the teardown function called pci_bridge_qemu_reserve_cap_uninit(). > > Last we enable the resource reserve capability for legacy PCI bridge > so that firmware can reserve additional resources for the bridge. > > Change Log: > v2 -> v1 > * add refactoring patch > * add teardown function > * some other fixes > > Jing Liu (3): > hw/pci: factor PCI reserve resources to a separate structure > hw/pci: add teardown function for PCI resource reserve capability > hw/pci: add PCI resource reserve capability to legacy PCI bridge > > hw/pci-bridge/gen_pcie_root_port.c | 32 +++++++++++++------------- > hw/pci-bridge/pci_bridge_dev.c | 25 ++++++++++++++++++++ > hw/pci/pci_bridge.c | 47 +++++++++++++++++++++----------------- > include/hw/pci/pci_bridge.h | 18 +++++++++++---- > 4 files changed, 80 insertions(+), 42 deletions(-) > just some meta comments for now: - I've added Marcel; please keep him CC'd on this set (and the SeaBIOS counterpart, [SeaBIOS] [PATCH v2 0/3] pci: resource reserve capability found) - my task queue has blown up and I'm unsure when I'll get to reviewing this set. The same applies to the SeaBIOS counterpart. This is just to say that you should feel free to go ahead and work with the (sub)maintainers; I'll try to get back to this as time allows, but don't wait for me. If further versions are necessary, I'd appreciate being CC'd on those, just so I know what to look at when I find the time again. Thanks! Laszlo

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS