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
6 months, 3 weeks
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 |
|| ||
1 year
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
1 year
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
1 year
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/
1 year
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.
1 year
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
1 year
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
1 year, 1 month
