|
SeaBIOS was lagging a lot, on startup and when executing
almost any payload, especially when doing anything in the
ESC menu.
I set the debug level to *21*, and thoroughly analysed the
logs. I found entries such as this:
Checking for bootsplash
WARNING - Timeout at wait_reg8:81!
TCGBIOS: Return value from sending TPM2_CC_StirRandom = 0x00000000
WARNING - Timeout at wait_reg8:81!
TCGBIOS: Return value from sending TPM2_CC_GetRandom = 0x00000000
WARNING - Timeout at wait_reg8:81!
TCGBIOS: Return value from sending TPM2_CC_HierarchyChangeAuth = 0x00000000
WARNING - Timeout at wait_reg8:81!
TCGBIOS: LASA = 0x7a9fc000, next entry = 0x7a9fc16e
WARNING - Timeout at wait_reg8:81!
TCGBIOS: LASA = 0x7a9fc000, next entry = 0x7a9fc1c5
WARNING - Timeout at wait_reg8:81!
TCGBIOS: LASA = 0x7a9fc000, next entry = 0x7a9fc211
WARNING - Timeout at wait_reg8:81!
TCGBIOS: LASA = 0x7a9fc000, next entry = 0x7a9fc25d
WARNING - Timeout at wait_reg8:81!
TCGBIOS: LASA = 0x7a9fc000, next entry = 0x7a9fc2a9
WARNING - Timeout at wait_reg8:81!
TCGBIOS: LASA = 0x7a9fc000, next entry = 0x7a9fc2f5
WARNING - Timeout at wait_reg8:81!
TCGBIOS: LASA = 0x7a9fc000, next entry = 0x7a9fc341
WARNING - Timeout at wait_reg8:81!
TCGBIOS: LASA = 0x7a9fc000, next entry = 0x7a9fc38d
WARNING - Timeout at wait_reg8:81!
TCGBIOS: LASA = 0x7a9fc000, next entry = 0x7a9fc3d9
Searching bootorder for: HALT
Mapping hd drive 0x000f49e0 to 0
I'm not quite certain what the problem is, but disabling TPM2
made the problem go away; SeaBIOS is snappy again.
TPM is security threatre anyway.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
The Libreboot 20241206 release provided FSP pre-assembled
and inserted into the ROM images; the only file inserted
by vendor.sh was the Intel ME.
Direct distribution of an unmodified FSP image is permitted
by Intel, provided that the license notice is given among
other requirements. Due to how coreboot works, it must split
up the FSP into subcomponents, and adjust certain pointers
within the -M component (for raminit).
Such build-time modifications are perfectly fine in a coreboot
context, where it is expected that you are building from source.
The end result is simply what you use.
In a distribution such as Libreboot, where we provide pre-built
images, this becomes problematic. It's a technicality of the
license, and it seems that Intel themselves probably intended
for Libreboot to use the FSP this way anyway, since it is they
who seem to be the author of SplitFspBin.py, which is the
utility that coreboot uses for splitting up the FSP image.
Due to the technicality of the licensing, the FSP shall now
be scrubbed from releases, and re-inserted.
Coreboot was inserting the -S component with LZ4 compression,
which is bad news for ./mk inject beacuse the act of compression
is currently not reproducible. Therefore, coreboot has been
modified not to compress this section, and the inject command
doesn't compress it either. This means that the S file is using
about 180KB in flash, instead of about 140KB. This is totally OK.
The _fsp targets are retained, but set to release=n, because these
targets *still* don't scrub fsp.bin; if released, they would
include fsp files, so they've been set to release=n. These can
be used on older Libreboot release archives, for compatibility.
The new ROM images released for the affected machines are:
t480_vfsp_16mb
t480s_vfsp_16mb
dell3050micro_vfsp_16mb
Note the use of _vfsp instead of _fsp. These images are released,
unlike _fsp, and they lack fspm/fsps in the image. FSP S/M must
be inserted using ./mk inject.
This has been tested and confirmed to boot just fine.
The 20241206 images will be re-compiled and re-uploaded with this
and other recent changes, to make Libreboot 20241206 rev8.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
