SeaBIOS

seabios@seabios.org

4 participants
3801 discussions

SeaBIOS recognising USB 3.0 on boot works - partly
by edward wandasiewicz 29 Nov '15

29 Nov '15

Running SeaBIOS on a Chromebook Pixel 2015, by default, does not recognise a plugged in USB 3.0 device attached to a USB 3.0 port or Type C port. As of 28 Nov, I ran ./flash_chromebook_rom.sh from https://johnlewis.ie/custom-chromebook-firmware/rom-download/ to get Johns most current SeaBIOS which will overwrite the RW_LEGACY slot. This will recognise some but not all USB devices. It would see my USB Phillips drive, just the once, but not the Mushkin drive at all. I then tried reverting the SeaBIOS back to Google's version. Running Google's ChromeOS recovery, for some reason, does not write or touch the RW_LEGACY slot at all. John Lewis SeaBIOS was still there after a ChromeOS recovery. Hmm... I later found out, other Google ChromeOS recovery images do touch and overwrite the RW_LEGACY slot, but not for the Pixel 2015 SAMUS for some reason - bug maybe in the recovery? With some help from John to extract the shell-ball and manually overwrite the RW_LEGACY slot from the binary inside the ChromeOS recovery image by following the instructions at https://johnlewis.ie/extracting-the-shell-ball-rom-using-a-chromeos-image/ Write the hardware ID to get future ChromeOS updates $ ./gbb_utility --set --hwid="SAMUS XXX-YYY-ZZZ" bios.bin bios.hwid.bin # dd out 2 megs of the ROM at 4 megs in $ dd bs=1M skip=4 count=2 if=bios.hwid.bin of=rwlegacy.cbfs Using the flashrom from John's site as upstream doesn't know anything about flashmap. $ wget https://johnlewis.ie/Chromebook-ROMs/utils/flashrom -O flashrom.jlewis $ sudo ./flashrom.jlewis -w -i RW_LEGACY:rwlegacy.cbfs We now have our original Google version SeaBIOS. But what's this... Before with Google's SeaBIOS, I had no USB 3.0 device got recognised. Now it's recognising all of them, all of the time. But not quite... I have one USB device, a Philips USB 3.0 device, which for some reason, is appearing not once, but twice in the list of bootable devices, yet only one and only one Philips USB drive is attached. So it appears, we have half a working solution from Google's own RW_LEGACY, and half a working solution from John's RW_LEGACY. *********************************************************************** USB 3.0 Devices attached directly to USB 3.0 ports or Type C *********************************************************************** One - Philips USB 3.0 Flash drive One - Mushkin Ventura Ulta ***************** Google Output ***************** SeaBIOS (version -20150402_151143-build122-m2) Press ESC for boot menu. Select boot device: 1. USB MSC Drive Philips USB Flash Drive PMAP 2 AHCI/O: KINGSTON RBU-SUS151S364GD ATA-10 Hard-Disk (61057 M 3. USB MSC Drive Philips USB Flash Drive PMAP 4. USB MSC Drive Mushkin Ventura Ultra ********************** John Lewis Output ********************** Press ESC for boot menu. Select boot device: 1. USB MSC Drive Philips USB Flash Drive PMAP 2 AHCI/O: KINGSTON RBU-SUS151S364GD ATA-10 Hard-Disk (61057 M Edward

1 0

Qemu-kvm VM halt at allocate VGA stack when continuously reset VM
by Xulei (Stone) 28 Nov '15

28 Nov '15

Hi, Recently, i use a script to continuously reset a VM and i found my VM frequently halts at "Attempting to allocate VGA stack via pmm call". After analyzing, i think it may be a problem of SeaBIOS. From the log(attached below), we can see handle_post() executes twice and this makes the destination address of "Relocating init" change when the 2nd reset command comes. This also influences on the source address of "Copying MPTABLE". At last, the VM will be stuck at attempting to allocate VGA stack via pmm call. Could you offer me a solution to fix this problem? ==============bad SeaBIOS log====== SeaBIOS (version rel-1.8.1-0-g4adadbd-20151127_220019-UVP) No Xen hypervisor found. Running on QEMU (i440fx) Running on KVM RamSize: 0xc0000000 [cmos] Now vcpu cpu_id = 0 <<========= i add Static seabios entry times =1 <<========= i add Relocating init from 0x000dbb30 to 0xbffad2c0 (size 76928) Found QEMU fw_cfg SeaBIOS (version rel-1.8.1-0-g4adadbd-20151127_220019-UVP) <<========= handle_post() execute again? No Xen hypervisor found. Running on QEMU (i440fx) Running on KVM RamSize: 0xc0000000 [cmos] Now vcpu cpu_id = 0 <<========= i add Static seabios entry times =2 <<========= i add Relocating init from 0x000dbb30 to 0xbff997b0 (size 76928) <<========= here, the dest address has been changed! Found QEMU fw_cfg RamBlock: addr 0x0000000000000000 len 0x00000000c0000000 [e820] RamBlock: addr 0x0000000100000000 len 0x0000000240000000 [e820] Moving pm_base to 0x600 boot order: 1: /pci@i0cf8/ide@1,1/drive@0/disk@0 2: HALT CPU Mhz=2406 === PCI bus & bridge init === PCI: pci_bios_init_bus_rec bus = 0x0 === PCI device probing === Found 11 PCI devices (max PCI bus is 00) === PCI new allocation pass #1 === PCI: check devices === PCI new allocation pass #2 === PCI: IO: c000 - c1cf PCI: 32: 00000000c0000000 - 00000000fec00000 PCI: map device bdf=00:1f.0 bar 0, addr 0000c000, size 00000100 [io] PCI: map device bdf=00:03.0 bar 0, addr 0000c100, size 00000040 [io] PCI: map device bdf=00:04.0 bar 0, addr 0000c140, size 00000040 [io] PCI: map device bdf=00:01.2 bar 4, addr 0000c180, size 00000020 [io] PCI: map device bdf=00:05.0 bar 0, addr 0000c1a0, size 00000020 [io] PCI: map device bdf=00:01.1 bar 4, addr 0000c1c0, size 00000010 [io] PCI: map device bdf=00:03.0 bar 6, addr feb80000, size 00040000 [mem] PCI: map device bdf=00:02.0 bar 6, addr febc0000, size 00010000 [mem] PCI: map device bdf=00:02.0 bar 1, addr febd0000, size 00001000 [mem] PCI: map device bdf=00:03.0 bar 1, addr febd1000, size 00001000 [mem] PCI: map device bdf=00:04.0 bar 1, addr febd2000, size 00001000 [mem] PCI: map device bdf=00:05.0 bar 1, addr febd3000, size 00001000 [mem] PCI: map device bdf=00:06.0 bar 0, addr febd4000, size 00001000 [mem] PCI: map device bdf=00:02.0 bar 0, addr fa000000, size 02000000 [prefmem] PCI: map device bdf=00:06.0 bar 2, addr fc000000, size 01000000 [prefmem] PCI: init bdf=00:00.0 id=8086:1237 PCI: init bdf=00:01.0 id=8086:7000 PIIX3/PIIX4 init: elcr=00 0c PCI: init bdf=00:01.1 id=8086:7010 PCI: init bdf=00:01.2 id=8086:7020 PCI: init bdf=00:01.3 id=8086:7113 Using pmtimer, ioport 0x608 PCI: init bdf=00:02.0 id=1013:00b8 PCI: init bdf=00:03.0 id=1af4:1000 PCI: init bdf=00:04.0 id=1af4:1004 PCI: init bdf=00:05.0 id=1af4:1003 PCI: init bdf=00:06.0 id=1af4:1110 PCI: init bdf=00:1f.0 id=1af4:8888 PCI: Using 00:02.0 for primary VGA handle_smp: apic_id=1 handle_smp: apic_id=4 handle_smp: apic_id=7 handle_smp: apic_id=5 handle_smp: apic_id=6 handle_smp: apic_id=2 handle_smp: apic_id=3 Found 8 cpu(s) max supported 8 cpu(s) Copying PIR from 0xbffbea18 to 0x000f5460 Copying MPTABLE from 0x00006e30/bff90570 to 0x000f5360 <<========== here, the src address is different from normal Copying SMBIOS entry point from 0x00006e11 to 0x000f5180 Scan for VGA option rom Running option rom at c000:0003 Start SeaVGABIOS (version rel-1.8.1-0-g4adadbd-20151127_220021-UVP) enter vga_post: a=00000010 b=0000ffff c=00000000 d=0000ffff ds=0000 es=f000 ss=0000 si=00000000 di=00005540 bp=00000000 sp=00006dbe cs=f000 ip=d2c4 f=0000 cirrus init cirrus init 2 Attempting to allocate VGA stack via pmm call to f000:d369 <<=========== here, always halt! ============end===========

1 0

bug: incorrect uuid in seabios output
by Cole Robinson 27 Nov '15

27 Nov '15

Hi, The UUID seabios reports in its boot output doesn't match what is passed via qemu -uuid option. An example is reported here: https://bugzilla.redhat.com/show_bug.cgi?id=1284259 This is due to: commit caad057bb6ce86a9cb71520af395fd0bd04a659f Author: Eduardo Habkost <ehabkost(a)redhat.com> Date: Wed Oct 29 11:26:08 2014 -0200 smbios: Encode UUID according to SMBIOS specification Differently from older versions, SMBIOS version 2.6 is explicit about the encoding of UUID fields: > Although RFC 4122 recommends network byte order for all fields, the PC > industry (including the ACPI, UEFI, and Microsoft specifications) has > consistently used little-endian byte encoding for the first three fields: > time_low, time_mid, time_hi_and_version. The same encoding, also known as > wire format, should also be used for the SMBIOS representation of the UUID. > > The UUID {00112233-4455-6677-8899-AABBCCDDEEFF} would thus be represented > as 33 22 11 00 55 44 77 66 88 99 AA BB CC DD EE FF. The dmidecode tool implements this and decodes the above "wire format" when SMBIOS version >= 2.6. We moved from SMBIOS version 2.4 to 2.8 when we started building the SMBIOS entry point inside QEMU, on commit c97294ec1b9e36887e119589d456557d72ab37b5. seabios doesn't seem to handle this special UUID format when reading from smbios. Thanks, Cole

4 3

USB3 problems
by Wim Vervoorn 24 Nov '15

24 Nov '15

Hello, I am running into issues when using USB3 sticks in a system (on an XHCI controller). When I am using a single USB3 stick it gets detected properly. When I am using 2 USB3 sticks only one is detected. When using one USB3 and a USB2 stick it depends on the slots. In one case both are detected in the other case only the USB2 stick. I was first blaming this on the XHCI controller initialization but I have now reproduced this same issue on two completely different systems. One base on AMD Steppe Eagle and the other on an Intel Braswell. Does this sound familiar? Has anyone run into this before. (I am using two ADAT CI03 sticks) The SeaBIOS version I am using is 9efbc0f43d0b50a0f314cff98c3b612e5dfb3ed5 Best Regards, Wim Vervoorn

2 11

[PATCH 0/8] Further TPM cleanups
by Kevin O'Connor 23 Nov '15

23 Nov '15

This series implements some further cleanups I saw while reviewing the TPM code. Some of the TPM functions take several parameters and this series attempts to simplify that. I've only compile tested this. The series is also available at: https://github.com/KevinOConnor/seabios/tree/testing -Kevin Kevin O'Connor (8): tpm: Don't pass entry_count around in parameters to/from tpm_extend_acpi_log() tpm: There is no need to pass pcrindex to hash_log_extend_event() tpm: Perform hashing separately from logging tpm: Use pcpes->event[] to pass data to tpm_extend_acpi_log() tpm: Avoid scatter-gather copying in build_and_send_cmd() tpm: Don't implement scatter-gather in transmit() tpm: Merge tpm_log_event() and tpm_extend_acpi_log() tpm: Merge tpm_log_extend_event() and tpm_extend(); extend before logging src/std/tcg.h | 6 +- src/tcgbios.c | 257 ++++++++++++++++++++-------------------------------------- src/tcgbios.h | 8 -- 3 files changed, 87 insertions(+), 184 deletions(-) -- 2.5.0

2 11

[PATCH v3 0/5] TPM cleanup
by Stefan Berger 21 Nov '15

21 Nov '15

The following series addresses Kevin's recent comments about the TPM driver. It also continues the refactoring of those functions called by the BIOS interrupt. Regards, Stefan Stefan Berger (5): tpm: Drop code using the TPM for sha1 tpm: Set timeouts and durations to microsecond values tpm: Cache all log related pointers in tpm_state tpm: Refactor pass_through_to_tpm tpm: Rename remaining interrupt functions src/hw/tpm_drivers.c | 32 +++-- src/hw/tpm_drivers.h | 26 ++-- src/std/tcg.h | 15 --- src/tcgbios.c | 352 ++++++++++++++++++--------------------------------- 4 files changed, 154 insertions(+), 271 deletions(-) -- 2.4.3

1 5

[PATCH v2 0/5] TPM cleanup
by Stefan Berger 21 Nov '15

21 Nov '15

The following series addresses Kevin's recent comments about the TPM driver. It also continues the refactoring of those functions called by the BIOS interrupt. Regards, Stefan Stefan Berger (5): tpm: Drop code using the TPM for sha1 tpm: Set timeouts and durations to microsecond values tpm: Cache all log related pointers in tpm_state tpm: Refactor pass_through_to_tpm tpm: Rename remaining interrupt functions src/hw/tpm_drivers.c | 12 +- src/hw/tpm_drivers.h | 26 ++-- src/std/tcg.h | 15 --- src/tcgbios.c | 352 ++++++++++++++++++--------------------------------- 4 files changed, 140 insertions(+), 265 deletions(-) -- 2.4.3

2 6

[PATCH 0/3] TPM cleanup
by Stefan Berger 21 Nov '15

21 Nov '15

The following series addresses 3 out of the 4 comments from Kevin from his email today. Regards, Stefan Stefan Berger (3): tpm: Drop code using the TPM for sha1 tpm: Introduce a cache variable for TCPA table pointer tpm: Set timeouts and durations to default values src/hw/tpm_drivers.c | 1 - src/hw/tpm_drivers.h | 26 +++++++------- src/tcgbios.c | 97 ++++++++-------------------------------------------- 3 files changed, 28 insertions(+), 96 deletions(-) -- 2.4.3

2 5

Re: [SeaBIOS] Questions on SeaBIOS TPM
by Kevin O'Connor 20 Nov '15

20 Nov '15

On Fri, Nov 20, 2015 at 10:31:35PM +0000, Stefan Berger wrote: > "Kevin O'Connor" <kevin(a)koconnor.net> wrote on 11/20/2015 12:26:08 PM: > > Oh, so the code could assume that the tcpa table is not moved nor > > modified _and_ that the BIOS is also the only writer to the log? > > Unless there is way that the bootloader could give back control to the > BIOS, the BIOS would be the only writer to the log. Well, the bootloader could call HashLogEvent or HashLogExtendEvent via the 16bit BIOS interface. Does the code have to worry about a bootloader (or OS) that manually adds entries to the acpi tcpa table and then calls one of the HashLogEvent bios functions? It sounds like this table is owned by the BIOS and thus the BIOS could fully cache the last pointer. -Kevin

1 0

Re: [SeaBIOS] Questions on SeaBIOS TPM
by Kevin O'Connor 20 Nov '15

20 Nov '15

On Fri, Nov 20, 2015 at 05:09:07PM +0000, Stefan Berger wrote: > "Kevin O'Connor" <kevin(a)koconnor.net> wrote on 11/20/2015 11:12:53 AM: > > I don't understand the error handling in tpm_extend_acpi_log() and > > tpm_extend(). Why does a log overflow in tpm_extend_acpi_log() > > shutdown the tpm chip (via tpm_set_failure() )? In particular, > > tpm_extend_acpi_log can be called from clients via the 16bit BIOS > > interface, and it's the only way a client could cause the tpm chip to > > shutdown. Why does tpm_extend() call reset_acpi_log() on failure? It > > seems odd that a failure in communication with the TPM chip would > > result in an ACPI log reset - no other TPM chip failure does that. > > The intention here was to invalidate the log that is supposed to be > written along with PCR extensions, resulting in attestation not being > possible due to a failure in the extend. Okay - so there isn't a specific need to handle a failure in tpm_extend_acpi_log() differently from a failure in tpm_extend()? That is, the goal is just to prevent attestation after a failed request? > > Is it expected that the tcpa ACPI table could move or be modified at > > runtime? The code rescans for the table twice on every call to > > tpm_extend_acpi_log() - if it can't move or be modified then I think > > it would be simpler to cache the values. > > I will have a look whether we can cache that. I guess for as long as it's > scanned for 'early' we are not write-protected, yet. You may have seen I > am also rescanning the log every time something is appended to it. Here > the reason was that we are running in ROM mode and I cannot write to > static variables anymore that would allow to set the pointer to the last > entry. So back when I wrote this I handled the ACPI table in the same way > - rescanning. Oh, so the code could assume that the tcpa table is not moved nor modified _and_ that the BIOS is also the only writer to the log? BTW, to make a global variable read/writable at runtime, one can add the VARLOW attribute to the variable. Thanks, -Kevin

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS