On 03/07/2018 12:41 PM, Kevin O'Connor wrote:
On Wed, Mar 07, 2018 at 12:33:36PM -0500, Stephen Douthit wrote:
On 03/07/2018 10:33 AM, Paul Menzel wrote:
Dear Stephen,
Thank you for your quick response.
Am Dienstag, den 06.03.2018, 11:57 -0500 schrieb Stephen Douthit:
On 03/06/2018 11:04 AM, Paul Menzel wrote:
On 03/02/18 17:31, Kevin O'Connor wrote:
On Tue, Feb 27, 2018 at 02:17:08PM -0500, Stephen Douthit wrote:
[…]
Thanks. I committed this series.
The second commit introduced a regression with coreboot on the
ASRock E350M1. There are a bunch of time-outs, causing the startup
to be really slow. With no serial console, the user thinks, it’s
not working and start to debug.
Looking through the the user manual for that board I don't see that it
has a TPM, or even the header for one, so a timeout seems correct.
Indeed, no TPM is present.
Thanks for confirming.
Multiple 750ms timeouts does seem pretty painful though. I hadn't
considered that tis_probe() would be called multiple times if no TPM
was present.
What's the preferred way to have a probe function run and bail before
rerunning the timeout? Just put a static flag in tis_probe()? The
attached patch takes that approach. Please let me know if that fixes
the issue for you, or if there's some other preferred pattern I should
use here.
Unfortunately, that didn’t help.
```
$ git log --oneline -2
fd1cbb4 (HEAD -> master, origin/master, origin/HEAD) tpm: Save tis_probe()
result to avoid a reun of lengthy timeouts
5adc8bd tpm: Handle unimplemented TIS_REG_IFACE_ID in tis_get_tpm_version()
```
And the time-outs seem to be around 20 seconds or more. Please find the
log with time stamps attached (`sudo ./readserial.py /dev/ttyUSB0`).
Yikes, 20 seconds is the medium duration timeout, not the default A
timeout of 750ms. I was poking the wrong area with the last patch.
It looks like tis_probe() is propagating the return from
tis_wait_access() in the no device present case.
FYI, even adding 5ms to the boot time is unacceptable. Is there
anyway to verify the hardware exists before waiting for it to be
ready?
The only way I know of would be to check if we have TCPA or TPM2 ACPI
tables, and only attempt to probe for a TPM if those are present.
Attached patch should do that, and it's probably a good idea
independent of any of my other patches.
>From f02f25e56915727e761dc7b8b0f12321441e8537 Mon Sep 17 00:00:00 2001
From: Stephen Douthit <steph...@silicom-usa.com>
Date: Wed, 7 Mar 2018 13:17:36 -0500
Subject: [PATCH] tpm: Check for TPM related ACPI tables before attempting hw
probe
Signed-off-by: Stephen Douthit <steph...@silicom-usa.com>
---
src/tcgbios.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/src/tcgbios.c b/src/tcgbios.c
index 40b3028..24846d3 100644
--- a/src/tcgbios.c
+++ b/src/tcgbios.c
@@ -968,6 +968,13 @@ tpm_setup(void)
if (!CONFIG_TCGBIOS)
return;
+ int ret = tpm_tpm2_probe();
+ if (ret) {
+ ret = tpm_tcpa_probe();
+ if (ret)
+ return;
+ }
+
TPM_version = tpmhw_probe();
if (TPM_version == TPM_VERSION_NONE)
return;
@@ -976,13 +983,6 @@ tpm_setup(void)
"TCGBIOS: Detected a TPM %s.\n",
(TPM_version == TPM_VERSION_1_2) ? "1.2" : "2");
- int ret = tpm_tpm2_probe();
- if (ret) {
- ret = tpm_tcpa_probe();
- if (ret)
- return;
- }
-
TPM_working = 1;
if (runningOnXen())
--
2.14.3
_______________________________________________
SeaBIOS mailing list
SeaBIOS@seabios.org
https://mail.coreboot.org/mailman/listinfo/seabios
