[SeaBIOS] [PATCH v2 1/3] tpm: Wait for tpmRegValidSts flag on CRQ interface before probing
pmenzel at molgen.mpg.de
Mon Mar 26 13:20:15 CEST 2018
On 03/26/18 12:44, Stefan Berger wrote:
> On 03/25/2018 07:46 PM, Kevin O'Connor wrote:
>> On Sun, Mar 25, 2018 at 07:17:33PM -0400, Stefan Berger wrote:
>>> On 03/25/2018 11:45 AM, Kevin O'Connor wrote:
>>>> On Thu, Mar 22, 2018 at 08:19:09AM -0400, Stefan Berger wrote:
>>>>> The timeout to wait for the register change is 30ms. We
>>>>> yield() while waiting, so we don't block everything
>>>>> entirely... Is the error message misleading and we should
>>>>> print out that a device was not detected or print out if it
>>>>> is detected instead?
>>>> Unfortunately, although the TPM code calls yield(), there
>>>> isn't anything else running at that point, so the delay still
>>>> directly impacts the total boot time. It's not easy to push
>>>> back the TPM initialization so that other "threads" are running
>>>> in parallel, because the TPM code wants to be initialized prior
>>>> to running option roms and other devices.
>>>> Could we do something like the below (completely untested)? I
>>>> don't think we have to wait for the TPM device to report ready,
>>>> because in a real world scenario it would take an x86 cpu
>>>> hundreds of milliseconds from power on to get to this point of
>>>> the code anyway.
>>> I had thought about something like that also. Do we have the time
>>> in milliseconds since power-on or reset? We could subtract the
>>> timeout values you are discarding below from it and wait for the
>>> time difference, ignoring negative values of course.
>>> TIS_DEFAULT_TIMEOUT_A is 750ms, so more critical than
>>> TIS2_DEFAULT_TIMEOUT_D with 30ms.
>> Unfortunately, we don't have that info. It's not easy to get it
>> because the clock detection code doesn't run until we're nearly at
>> the tpmhw_probe() code anyway.
>> That said, for tis_probe() is there any harm in moving the didvid
>> check up? I understand it theoretically isn't setup yet, but I'd
>> imagine in practice it always would be. Just as, in practice, I
>> suspect the tpm would always be ready by the time we got to the
>> tpmhw_probe() code. See below.
> It's hard to say without testing this with real hardware. When I had
> the Acer, it was working quite reliably without waiting for the flag
> to be set. Though the Acer only used one certain manufacturer's TPM.
> Other TPMs may behave differently. Maybe Stephen can give it a try?
Can’t you get some hardware to test this? For example an old laptop with
a TPM? If you work in this area, that might be a good idea.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 5174 bytes
Desc: S/MIME Cryptographic Signature
More information about the SeaBIOS