[SeaBIOS] Long delay: WARNING - Timeout at wait_reg8:81!

[Kevin O'Connor]

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