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? -Kevin _______________________________________________ SeaBIOS mailing list SeaBIOS@seabios.org https://mail.coreboot.org/mailman/listinfo/seabios
