SeaBIOS

seabios@seabios.org

4 participants
3801 discussions

Current tip not booting from USB or SD cards
by Stefan Berger 10 Sep '14

10 Sep '14

Hello! The current git tip does not boot from USB or SD cards on an Acer C720. The issue seems to stem from: ab9d771ce14d5b8d38cde373d15a51b45efb99c6 is the first bad commit commit ab9d771ce14d5b8d38cde373d15a51b45efb99c6 Author: Kevin O'Connor <kevin(a)koconnor.net> Date: Sat Jun 14 12:48:35 2014 -0400 ehci: Update usb command timeouts to use usb_xfer_time() Signed-off-by: Kevin O'Connor <kevin(a)koconnor.net> :040000 040000 4fcdb230f8fcffc0d8256225eb3c3220bd2293d4 78b62cb78cc3537da5a2ce1f1417fb1e0a571ba1 M src Regards, Stefan

2 2

[PATCH 1/2] usb: Fix usb_xfer_time() to work when called in 16bit mode.
by Kevin O'Connor 10 Sep '14

10 Sep '14

Make sure to wrap accesses to the usb_pipe struct with GET_LOWFLAT so that it works in 16bit mode. This bug impacts both ehci and uhci usb controllers (it should not impact ohci and xhci as those never call the function in 16bit mode). Signed-off-by: Kevin O'Connor <kevin(a)koconnor.net> --- src/hw/usb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/hw/usb.c b/src/hw/usb.c index 46b46be..930b5d9 100644 --- a/src/hw/usb.c +++ b/src/hw/usb.c @@ -195,7 +195,7 @@ usb_xfer_time(struct usb_pipe *pipe, int datalen) // set_address commands where we don't want to stall the boot if // the device doesn't actually exist. Add 100ms to account for // any controller delays. - if (!pipe->devaddr) + if (!GET_LOWFLAT(pipe->devaddr)) return USB_TIME_STATUS + 100; return USB_TIME_COMMAND + 100; } -- 1.9.3

2 2

Re: [SeaBIOS] EHCI boot problems
by Kevin O'Connor 10 Sep '14

10 Sep '14

On Tue, Sep 09, 2014 at 04:08:25PM -0600, Dave Frodin wrote: > Kevin, > With your patch I'm not seeing that timeout message get displayed. > I also forgot to mention that the USB thumbdrive will always get identified > by SeaBIOS and will be listed as a boot device but will hang as soon as it > is selected in the F12 boot menu. The activity LED on the thumbdrive only > flashes when Seabios is identifying it. I was able to reproduce the problem on my c720. The patch below seems to fix it for me (but I'm still running tests). I'm not sure why this problem didn't show up on my other test machine (e350m1). -Kevin --- a/src/hw/usb.c +++ b/src/hw/usb.c @@ -195,7 +195,7 @@ usb_xfer_time(struct usb_pipe *pipe, int datalen) // set_address commands where we don't want to stall the boot if // the device doesn't actually exist. Add 100ms to account for // any controller delays. - if (!pipe->devaddr) + if (!GET_LOWFLAT(pipe->devaddr)) return USB_TIME_STATUS + 100; return USB_TIME_COMMAND + 100; }

2 1

Re: [SeaBIOS] EHCI boot problems
by Kevin O'Connor 10 Sep '14

10 Sep '14

On Tue, Sep 09, 2014 at 01:15:04PM -0600, Dave Frodin wrote: > I'm seeing a problem booting from USB thumbdrives with commit ab9d771ce > ehci: Update usb command timeouts to use usb_xfer_time() > > I'm not quite sure what the problem is other than it not liking the new > timeouts. > I couldn't see any problems with the ehci_control() calls to ehci_wait_td(). > But the ehci_send_bulk() only allows the system to boot if I change > int ret = ehci_wait_td(pipe, td, end); > to > int ret = ehci_wait_td(pipe, td, timer_calc(5000)); > > One potential problem is that the "end" value is calculated once and reused > multiple times in the functions. Prior to the commit the timeout value was > passed > to the ehci_wait_td() function. Now the final "end" time is passed. So it > looks like > once the end timeout is reached in one of the loops that calls > ehci_wait_td() the > timer will always be expired for any other calls from that function. > > One solution might be to get rid of the "end" variable and change the calls > from > ret = ehci_wait_td(pipe, td, end); > to > ret = ehci_wait_td(pipe, td, timer_calc(usb_xfer_time(p, datasize))); > > Making the above change didn't have any impact on my booting problem until > I forced the ehci_send_bulk() timeouts to 5000. Hi Dave, Stefan Burger reported a similar problem with that commit. However, I'm puzzled what would be causing such a regression - five seconds should be more then enough time to complete a single usb transaction. Do you have serial debugging (or similar) available on the device you are working with? If you could provide the output from the debugging patch below it may help diagnose the issue. I also got my Acer c720 back, and will run some tests on it. -Kevin --- a/src/hw/usb-ehci.c +++ b/src/hw/usb-ehci.c @@ -629,6 +629,7 @@ ehci_send_bulk(struct usb_pipe *p, int dir, void *data, int datasize) , &pipe->qh, dir, data, datasize); // Allocate 4 tds on stack (with required alignment) + u32 starttime = timer_calc(0); u32 end = timer_calc(usb_xfer_time(p, datasize)); u8 tdsbuf[sizeof(struct ehci_qtd) * STACKQTDS + EHCI_QTD_ALIGN - 1]; struct ehci_qtd *tds = (void*)ALIGN((u32)tdsbuf, EHCI_QTD_ALIGN); @@ -642,7 +643,7 @@ ehci_send_bulk(struct usb_pipe *p, int dir, void *data, int datasize) struct ehci_qtd *td = &tds[tdpos++ % STACKQTDS]; int ret = ehci_wait_td(pipe, td, end); if (ret) - return -1; + goto fail; struct ehci_qtd *nexttd_fl = MAKE_FLATPTR(GET_SEG(SS) , &tds[tdpos % STACKQTDS]); @@ -662,10 +663,15 @@ ehci_send_bulk(struct usb_pipe *p, int dir, void *data, int datasize) struct ehci_qtd *td = &tds[tdpos++ % STACKQTDS]; int ret = ehci_wait_td(pipe, td, end); if (ret) - return -1; + goto fail; } return 0; +fail: + dprintf(1, "timeout: start=%x end=%x cur=%x time=%d devaddr=%x datasize=%d\n" + , starttime, end, timer_calc(0) + , usb_xfer_time(p, datasize), p->devaddr, datasize); + return -1; } int

2 1

EHCI boot problems
by Dave Frodin 09 Sep '14

09 Sep '14

I'm seeing a problem booting from USB thumbdrives with commit ab9d771ce ehci: Update usb command timeouts to use usb_xfer_time() I'm not quite sure what the problem is other than it not liking the new timeouts. I couldn't see any problems with the ehci_control() calls to ehci_wait_td(). But the ehci_send_bulk() only allows the system to boot if I change int ret = ehci_wait_td(pipe, td, end); to int ret = ehci_wait_td(pipe, td, timer_calc(5000)); One potential problem is that the "end" value is calculated once and reused multiple times in the functions. Prior to the commit the timeout value was passed to the ehci_wait_td() function. Now the final "end" time is passed. So it looks like once the end timeout is reached in one of the loops that calls ehci_wait_td() the timer will always be expired for any other calls from that function. One solution might be to get rid of the "end" variable and change the calls from ret = ehci_wait_td(pipe, td, end); to ret = ehci_wait_td(pipe, td, timer_calc(usb_xfer_time(p, datasize))); Making the above change didn't have any impact on my booting problem until I forced the ehci_send_bulk() timeouts to 5000. Thanks in advance for any advice anyone can offer, Dave

1 0

Problems with Linux payload
by Curt Brune 28 Aug '14

28 Aug '14

Hello - First time poster, so take it easy on me :) This is a great project -- I was able to get a kvm+coreboot+SeaBIOS environment going pretty easily. I started with the master branch of coreboot and went from there. I am having a problem trying to load a Linux kernel+initramfs payload from SeaBIOS. I can successfully boot the same kernel+initramfs straight from coreboot (without SeaBIOS) as a payload. Also I can boot the same kernel+initramfs from the hard disk using SeaBIOS when GRUB is installed on the hard disk. So I'm pretty sure my kernel+initramfs is OK. My rom looks like this: coreboot.rom: 16384 kB, bootblocksize 1416, romsize 16777216, offset 0x0 alignment: 64 bytes Name Offset Type Size cmos_layout.bin 0x0 cmos_layout 1160 fallback/romstage 0x4c0 stage 19569 fallback/ramstage 0x5180 stage 55849 config 0x12c00 raw 3132 fallback/payload 0x13880 payload 57928 vgaroms/sgabios.bin 0x21b00 raw 4096 etc/boot-menu-wait 0x22b40 raw 8 etc/boot-menu-key 0x22b80 raw 8 etc/boot-menu-message 0x22bc0 raw 34 etc/screen-and-debug 0x22c40 raw 8 img/LINUX 0x22c80 payload 8474826 (empty) 0x837d80 null 8158360 When I break into SeaBIOS during the boot I get this menu: Select boot device: 1. DVD/CD [ata1-0: QEMU DVD-ROM ATAPI-4 DVD/CD] 2. Virtio disk PCI:0:4 3. Legacy option rom 4. iPXE (PCI 00:03.0) 5. Payload [LINUX] When I select "5" I get this: Searching bootorder for: HALT drive 0x000f4d50: PCHS=16383/16/63 translation=lba LCHS=1024/255/63 s=33554432 Running option rom at cc80:0003 Booting from CBFS... Run img/LINUX Calling addr 0x00040000 ... [System Reboots] I turned on some debug in coreboot and SeaBIOS and compared the successful boot (coreboot+Linux) to the unsuccessful boot (coreboot+SeaBIOS+Linux). I compared the segment offsets and sizes between the two cases and they were the same. Also the 0x00040000 entry point was the same. I am mostly stuck now. Is this even a supported boot option? I'm new to SeaBIOS, so any help is much appreciated. Thanks again for a great project -- I had pretty smooth sailing up to this point. Cheers, Curt

4 9

[PATCH v8 0/8] Add TPM support to SeaBIOS
by Stefan Berger 28 Aug '14

28 Aug '14

This is a repost of a series of patches providing TPM support to SeaBIOS. As an addition, this patch series now works on the Acer C720 Chromebook with limitations (S3 not getting invoked; no logging into TCPA table). The patch series cleanly applies to a checkout of tags/rel-1.7.5. The following set of patches add TPM and Trusted Computing support to SeaBIOS. In particular the patches add: - a TPM driver for the Qemu's TPM TIS emulation (not yet in Qemu git) - ACPI support for the TPM device (SSDT table) - ACPI support for measurement logging (TCPA table) - Support for initialzation of the TPM - Support for the TCG BIOS extensions (1ah handler [ah = 0xbb]) (used by trusted grub; http://trousers.sourceforge.net/grub.html) - Static Root of Trusted for Measurement (SRTM) support - Support for S3 resume (sends command to TPM upon resume) - TPM-specific menu for controlling aspects of the TPM All implementations necessarily follow specifications. When all patches are applied the following services are available - SSDT ACPI table for TPM support - initialization of the TPM upon VM start and S3 resume - Static root of trust for measurements (SRTM) that measures (some) data of SeaBIOS in TCPA ACPI table - 1ah interrupt handler offering APIs for measuring and sending commands to the TPM (trusted grub uses them) - User menu for controlling aspects of the state of the TPM Stefan Berger (8): Add an implementation of a TPM TIS driver Provide ACPI SSDT table for TPM device + S3 resume support Implementation of the TCG BIOS extensions Support for BIOS interrupt handler Add 'measurement' code to the BIOS Add a menu for TPM control Add a menu item for displaying TPM diagnostics Make the TPM menu work on a Chromebook (Acer C720) Makefile | 12 +- src/Kconfig | 15 + src/boot.c | 28 +- src/cdrom.c | 10 + src/clock.c | 12 + src/config.h | 1 + src/fw/acpi-tpm-ssdt.dsl | 24 + src/fw/acpi-tpm-ssdt.hex | 27 + src/fw/acpi.c | 41 + src/hw/tpm_drivers.c | 273 ++++++ src/hw/tpm_drivers.h | 91 ++ src/optionroms.c | 4 + src/post.c | 9 + src/resume.c | 2 + src/sha1.c | 145 +++ src/sha1.h | 8 + src/std/acpi.h | 20 + src/tcgbios.c | 2208 ++++++++++++++++++++++++++++++++++++++++++++++ src/tcgbios.h | 431 +++++++++ src/util.h | 32 + 20 files changed, 3388 insertions(+), 5 deletions(-) create mode 100644 src/fw/acpi-tpm-ssdt.dsl create mode 100644 src/fw/acpi-tpm-ssdt.hex create mode 100644 src/hw/tpm_drivers.c create mode 100644 src/hw/tpm_drivers.h create mode 100644 src/sha1.c create mode 100644 src/sha1.h create mode 100644 src/tcgbios.c create mode 100644 src/tcgbios.h -- 1.8.1.4

4 26

Re: [SeaBIOS] [PATCH v8 0/8] Add TPM support to SeaBIOS
by Kevin O'Connor 26 Aug '14

26 Aug '14

On Tue, Aug 26, 2014 at 03:13:11PM -0400, Stefan Berger wrote: > "Kevin O'Connor" <kevin(a)koconnor.net> wrote on 08/26/2014 12:49:57 PM: > > On Tue, Aug 26, 2014 at 12:07:54PM -0400, Stefan Berger wrote: > > > The other aspect is that this extension propagates all the way into > higher > > > layers: libvirt would need an API and command > > > line tool extension just to set this flag and presumably use the QEMU > > > > monitor with a new command to indicate it. > > > You want to be able to do this in a cloud environment, you need > another > > > API and/or GUI support in your cloud stack for doing > > > just this... I doesn't seem to become a lot easier this way. > > > > Not easier. But I don't think adding this menu to SeaBIOS is the > > solution either. As before, for the bulk of users it's just cryptic, > > and for those rare users that do need it, it is not in a place they > > want it. > > Let me approach this all the way from the cloud user perspective: > > One can add a TPM to a VM via an attribute to the image one wants to > deploy. So having a TPM attached to a VM > would be an option. Libvirt can then create a slightly different XML that > instructs QEMU to show the SeaBIOS menu > IF a TPM is attached. If no TPM is attached, no menu is shown, so no > changes here. I find this a useable solution > that helps those that want a TPM to be attached to the VM and leaves > things as they are for those that don't. If you're going to update libvirt (and cloud stack) for a "show the TPM menu" flag. Might as well just update libvirt (and stack) to set the TPM enable/disable/clear setting directly. >Besides that root gets too much > control over VMs with attached TPMs running on a system if libvirt > was to be extended with this kind of support. You could then set the > above mentioned flags and see what happens when the VM gives up > ownership the next time it boots... I don't understand the above. Root on the guest would have no such ability. Root on the host can't be stopped anyway.. -Kevin

1 0

Re: [SeaBIOS] [PATCH v8 0/8] Add TPM support to SeaBIOS
by Kevin O'Connor 26 Aug '14

26 Aug '14

On Tue, Aug 26, 2014 at 12:07:54PM -0400, Stefan Berger wrote: > "Kevin O'Connor" <kevin(a)koconnor.net> wrote on 08/26/2014 11:19:14 AM: > > If this is the intent, can't we just pass a flag (via fw_cfg) from > > QEMU command line to SeaBIOS to force a clear? That is, the guest > > software can't manipulate the QEMU command line (or its fw_cfg > > entries) and so the ability to set a flag there is proof of physical > > presence. (Access to the virtual machine disk images and virtual > > machine command line is as close to "physical" as one can get.) > > One would need at least a flag to indicate that the BIOS automatically > give up ownership of the TPM. > Giving up ownership also means that the device automatically becomes > disabled and deactivated. The BIOS would then > presumably automatically have to enabled and activate the TPM again > without user interaction. Off the top of my head, I would think one could use a single multi-purpose state indicator (eg, "TPM is enabled, active, ownable", "TPM is enabled, active, non-ownable", "TPM is disabled, deactivated, cleared, unownable", etc.). I'd guess there are several permutations that wouldn't make sense and the total list could be simplified. > The other aspect is that this extension propagates all the way into higher > layers: libvirt would need an API and command > line tool extension just to set this flag and presumably use the QEMU > monitor with a new command to indicate it. > You want to be able to do this in a cloud environment, you need another > API and/or GUI support in your cloud stack for doing > just this... I doesn't seem to become a lot easier this way. Not easier. But I don't think adding this menu to SeaBIOS is the solution either. As before, for the bulk of users it's just cryptic, and for those rare users that do need it, it is not in a place they want it. > > On coreboot, a similar solution could be accomplished by setting a > > flag in CBFS (the flash). Granted, one doesn't need to be physically > > present to reprogram the flash, but if one can reprogram the flash, > > they could just as easily reprogram SeaBIOS anyway. > > I am not so familiar with how CBFS is handled. Is it at least > access-restricted to root? I guess one would need a tool > to write the above flag(s) into the flash at the right position. Yes, at a minimum it would require super-user access. (Some hardware platforms introduce additional restrictions.) -Kevin

2 1

New stable release for Intel CRBs with coreboot/FSP?
by Paul Menzel 26 Aug '14

26 Aug '14

Dear SeaBIOS folks, Martin Roth submitted the following patch to coreboot for review [1]. src/Kconfig: Select SeaBIOS master branch by default if desired This just adds a way to select the SeaBIOS master branch by default if desired. The Intel CRBs I'm adding have a single switch to set up the configuration the way that Intel desires. This allows that switch to set the platform to use the master branch. The problem is that some patches from SeaBIOS’ master branch are needed, which are not yet in the SeaBIOS 1.7.5. Martin, could you please list the needed patches so that Gerd can take a look if a release is possible? Thanks, Paul [1] http://review.coreboot.org/6365/

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS