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.
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. /
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:
In this case, it should be
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
> 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
> 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:
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.
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
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
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
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  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.)
Hi SeaBIOS expert
If we have some issue about SeaBIOS, do we need to open a ticket or just use email?
10F, No.392, Ruiguang Rd.
Neihu Dist., Taipei City 11492
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.
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
If my understanding is right, we may need some other logic of the memory
allocation in seabios?
Looking forward to the advice.
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?