SeaBIOS

seabios@seabios.org

3783 discussions

Re: [SeaBIOS] [PATCH 3/3] tpm: Add a menu for TPM configuration
by Kevin O'Connor 01 Dec '15

01 Dec '15

On Mon, Nov 30, 2015 at 10:23:28AM -0500, Stefan Berger wrote: > "Kevin O'Connor" <kevin(a)koconnor.net> wrote on 11/30/2015 10:05:22 AM: > > Are the above definitions part of the standard, or internal to the > > implementation? If the latter, they should go into tcgbios.[ch] > > These are actually the 'message codes' from the physical presence > interface spec that can be sent from the OS > to the BIOS and on which the BIOS is supposed to act upon reboot. You may > remember the ACPI patches I had for QEMU > where ACPI would write one of the above number into an allocated memory > area for the BIOS to find. I also built > the menu using those 'message codes'. Okay, thanks. > > > +typedef struct { > > > + u8 op; > > > +} tpm_bios_cfg; > > > > What is the purpose of this struct? > > > > This datatype is used to send messages from menu item selections to the > part that processes above 'message codes'. Right, but why does it pass a pointer to the struct instead of just passing the u8 directly? > > > +extern void reset_vector(void) __noreturn; > > > > The code should use reset() (defined in stacks.h). Directly calling > > reset_vector() in 32bit mode isn't strictly correct. > > Ok, will change it. (Worked so far...) It works because it likely causes a machine exception which also ends up in a reboot. So, not as nice. Thanks, -Kevin

1 0

Re: [SeaBIOS] SeaBIOS recognising USB 3.0 on boot works - partly
by Kevin O'Connor 01 Dec '15

01 Dec '15

On Sun, Nov 29, 2015 at 01:40:08AM +0000, edward wandasiewicz wrote: > 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. In order for us to investigate an issue, we need to see the debug log. For chromebooks, this is normally obtained by booting a Linux OS from SeaBIOS and running "cbmem -c". It will likely be necessary to download and compile the cbmem utility from the coreboot source code. Once you have the log, please email both a success and failure case to this mail list. There is also some info at: http://www.seabios.org/Debugging -Kevin

2 1

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 28 Nov '15

28 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 22 Nov '15

22 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 22 Nov '15

22 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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS