[SeaBIOS] [PATCH v2 1/3] tpm: Wait for tpmRegValidSts flag on CRQ interface before probing

[Paul Menzel]

Dear Stefan,


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.


Kind regards,

Paul

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5174 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.coreboot.org/pipermail/seabios/attachments/20180326/5816d462/attachment.p7s>