SeaBIOS July 2018

seabios@seabios.org

14 participants
14 discussions

Re: [SeaBIOS] [coreboot] Upgrade the 12 years old LZMA libraries - should we do it?

by Carl-Daniel Hailfinger

Hi Ivan, On 03.04.2018 20:03, Ivan Ivanov wrote: > I have noticed that both coreboot and seabios are using the very old > versions of LZMA SDK. True. I introduced the lzma code in coreboot (back when it was called LinuxBIOS) when we were working on OLPC XO-1 support. > If we will upgrade our LZMA libraries from the > outdated-by-12-years 4.42 to the current version 18.04 , speed and > compression ratio should improve and maybe a few bugs will be fixed. Do you have any numbers for this? An improved compression ratio and improved speed would be nice indeed, but how does the size of the decompression code change? If the decompression code grows more than the size reduction from better compression, it would be a net loss. A significantly reduced decompression speed would also be a problem. Decompression speed would have to be measured both for stream decompression (i.e. the decompressor gets the compressed data in single-byte or multibyte chunks) as well as full-size decompression (i.e. the decompressor can access all compressed data at once). We also have to make sure that stream decompression still works after the change. > Do you think it should be done, or you are OK with using such an > outdated version? A size benefit for the resulting image is a good reason to switch. Regards, Carl-Daniel

2 years, 5 months

TPM 2.0 with SeaBIOS

by Piotr Kubaj

Hi, I use SeaBIOS 1.11.2 as payload with 4.8-835-g113f670baa on ASUS KGPE-D16 board. I also have ASUS TPM-L R2.0 module with Infineon SLB9665 chip. TPM is correctly detected by both Linux and FreeBSD. It's also detected by coreboot in debug console. But SeaBIOS doesn't cooperate with it - there's no TPM menu. In serial console, I get: TCGBIOS: Detected a TPM 1.2. rsdp=0x000f1930 rsdt=0xbf4b9030 table(41504354)=0xbf4bf460 TCGBIOS: Starting with TPM_Startup(ST_CLEAR) Return from tpm_simple_cmd(99, 1) = 1e TCGBIOS: TPM malfunctioning (line 874). Return from tpm_simple_cmd(73, 0) = 1e Note that SeaBIOS detects it as TPM 1.2, even though it's TPM 2.0. -- _________________________________________ / I find this corpse guilty of carrying a \ | concealed weapon and I fine it $40. | | | | -- Judge Roy Bean, finding a pistol and | | $40 on a man he'd | | | \ just shot. / ----------------------------------------- \ ^__^ \ (oo)\_______ (__)\ )\/\ ||----w | || ||

2 years, 11 months

Re: [SeaBIOS] Marvell 88SE9230 passthrough in KVM takes long time to boot

by Laszlo Ersek

side comment: On 07/29/18 21:43, Konrad Eisele wrote: > changed /usr/bin/kvm (which > libvirtd is calling at boot) > qemu-system-x86_64 -enable-kvm -bios /usr/lib/qemu/bios.bin "$@" This should not be necessary. Libvirt lets you specify the desired firmware in the domain XML: https://libvirt.org/formatdomain.html#elementsOSBIOS In this case, it should be <os> <loader>/path/to/your/bios.bin</loader> </os> Thanks Laszlo

2 years, 11 months

Re: [SeaBIOS] Marvell 88SE9230 passthrough in KVM takes long time to boot

by Kevin O'Connor

On Sun, Jul 29, 2018 at 01:49:10PM +0200, Konrad Eisele wrote: > I'm passing through a Marvell 88SE9230 card to a KVM guest under > Ubuntu 18.04. The card is a Sata controller with 4 ports. > The option rom of the Marvell 88SE9230 card shows on a normal boot a > bios screen. When pressing CTRL-m quick enough, you can interrupt the > bootprocess and enter a menue wherer you can define raid > arrays. > > When booting seabios inside KVM the bootprocess is very slow. > There is a 1 min holdtime where the cpu is about 30%. The screen is > black with only the seabios version string shown. I suspect that > the passed-through Marvell 88SE9230 cards option roms causes this > behaviour. > Maybe the scanning for option rom cause the slow bootprocess? > > In the seabios boot case no bios menue is shown, after > around 1 min the boot continues. > > Is it possible to disable the options rom processing? Is there some > documentation about this (How can I configure it for Ubuntu) ? The list of runtime SeaBIOS settings is at: https://www.seabios.org/Runtime_config You could try playing with the etc/pci-optionrom-exec setting. See QEMU's -fw_cfg command line option. You'll need to pass in a binary integer zero or binary integer one to control that setting. -Kevin

2 years, 11 months

Marvell 88SE9230 passthrough in KVM takes long time to boot

by Konrad Eisele

I'm passing through a Marvell 88SE9230 card to a KVM guest under Ubuntu 18.04. The card is a Sata controller with 4 ports. The option rom of the Marvell 88SE9230 card shows on a normal boot a bios screen. When pressing CTRL-m quick enough, you can interrupt the bootprocess and enter a menue wherer you can define raid arrays. When booting seabios inside KVM the bootprocess is very slow. There is a 1 min holdtime where the cpu is about 30%. The screen is black with only the seabios version string shown. I suspect that the passed-through Marvell 88SE9230 cards option roms causes this behaviour. Maybe the scanning for option rom cause the slow bootprocess? In the seabios boot case no bios menue is shown, after around 1 min the boot continues. Is it possible to disable the options rom processing? Is there some documentation about this (How can I configure it for Ubuntu) ? // Greetings Konrad

2 years, 12 months

Re: [SeaBIOS] Seabios issue

by Paul Menzel

Dear Lucien, Am 23.07.2018 um 08:06 schrieb Lucien Jheng: > If we have some issue about SeaBIOS, do we need to open a ticket or > just use email? Please use this mailing list. Use a descriptive subject and include all necessary information like version, log files and the configuration. Note, that there is no guarantee to get an answer or that your problem will be solved. For that to happen, you need to be support from your distribution and use the distribution channels, like the Red Hat bug tracker [1] for Red Hat, to get it fixed. (Not to mention, that your company and you should somehow spend money on free software nevertheless, if you use it, so that the developers can afford a living and work on the project.) Kind regards, Paul [1]: https://bugzilla.redhat.com/

3 years

Seabios issue

by Lucien Jheng

Hi SeaBIOS expert If we have some issue about SeaBIOS, do we need to open a ticket or just use email? Thanks you. Best regards, LITEON Corp. SLA/NA SW 鄭祥鈞Lucien Jheng Office:+886-2-87982888#5233 Fax:+886-2-8793-6887 11492台北市內湖區瑞光路392號10樓 10F, No.392, Ruiguang Rd. Neihu Dist., Taipei City 11492 Taiwan Confidential Information:This message is sent to the intended recipient and may contain privileged or confidential information. If you received this transmission in error, please notify the sender with a replying e-mail and delete the message and any attachment.Transmission Caveat and Virus Alert: Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions.

3 years

hotplug failure issue on pci-bridge

by Liu, Jing2

Hi, Recently, we tried some hotplug issues. The case is: when hotplug a device (e.g. iGPU) onto pci-bridge after guest booting up, guest reports "BAR 2: no space for [mem size 0x40000000 64bit pref]" etc. Seabios checks all the devices under the pci-bridge when qemu launching the guest, and only allocates "size=ALIGN(sum, align)" of memory space for pci-bridge mem and pref-mem windows. So if we hotplug a big pci device like Intel GPU which needs 256M mem/pref-mem or bigger, it will fail. If my understanding is right, we may need some other logic of the memory allocation in seabios? Looking forward to the advice. Thanks, Jing

3 years

seabios fails to build with current IASL

by Michael Tokarev

Here's the debian bugreport https://bugs.debian.org/901462 with the patch. Thanks! /mjt

3 years

seabios fails to build with current IASL

by Vivia Nikolaidou

Hi, Thanks for taking action on this bug that I reported. This is a follow-up from https://mail.coreboot.org/pipermail/seabios/2018-July/012353.html - I just subscribed to the mailing list and I don't have an easy way to reply to that email directly. On Mon, Jul 02, 2018 at 09:10:34AM +0200, Gerd Hoffmann wrote: > > If you don't want use the prebuilt tables I think the sane options are > (a) use a older iasl compiler, or (b) flip ACPI_DSDT to "n" and drop > support for qemu 1.3 + older. Since (a) isn't an option in Debian, I tried going for (b) (did it directly in debian/rules when generating .config, without adding a patch for it). It still failed to compile without the patch that truncates the Table ID in the DefinitionBlock. Removing the prebuilt tables before compilation also didn't work, as they are used quite extensively in acpi.c. I'm not sure I haven't misunderstood something here, but when you say that flipping ACPI_DSDT to "n" would make it not use the prebuilt tables, what exactly do you mean? That said, would the combination of the truncating patch + flipping ACPI_DSDT to "n" be an acceptable solution to fix the build in Debian? Best regards, Vivia

3 years

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS July 2018