|
From: Steve T. <sr...@cs...> - 2005-09-13 16:46:18
|
I updated the BIOS, and still no TPM device in the device table. I've
got a big "however" for this below, but first I'll tell you I've never
worked with ACPI before, so I'm not absolutely certain what I'm
looking at. I've used both "acpidump" and "iasl" from Intel --
neither show a device that's clearly the TPM. In the DSL file
produced from the DSDT dump, here's the closest I get:
Device (IOCM)
{
Name (_HID, EisaId ("PNP0C02"))
Name (_UID, 0x03)
Name (_CRS, ResourceTemplate ()
{
Memory32Fixed (ReadOnly, 0xF0000000, 0x04000000)
Memory32Fixed (ReadOnly, 0xFED13000, 0x00001000)
Memory32Fixed (ReadOnly, 0xFED14000, 0x00004000)
Memory32Fixed (ReadOnly, 0xFED18000, 0x00001000)
Memory32Fixed (ReadOnly, 0xFED19000, 0x00001000)
Memory32Fixed (ReadOnly, 0xFED1C000, 0x00004000)
* Memory32Fixed (ReadOnly, 0xFED20000, 0x00080000)
Memory32Fixed (ReadOnly, 0x000C0000, 0x00020000)
Memory32Fixed (ReadOnly, 0x000E0000, 0x00020000)
})
}
Notice that the memory-mapped I/O address space for the TPM is within
the line I've marked with the *. But this seems to be for a much more
general device (the complete I/O controller is my guess).
Now the "however" -- However, the acpidump program does show, in
addition to the DSDT table, an entire table that's labeled the "TCPA"
table. Here are the first few lines:
TCPA @ 0x3f6a8010
0000: 54 43 50 41 b9 0a 00 00 01 34 49 4e 54 45 4c 20 TCPA.....4INTEL
0010: 54 49 41 4e 4f 20 20 20 02 00 00 00 4d 53 46 54 TIANO ....MSFT
0020: 13 00 00 01 00 00 01 00 01 02 00 00 00 00 00 00 ................
0030: 01 00 00 00 14 00 00 00 c1 a1 5f 80 41 cb 83 bc .........._.A...
0040: 40 ae 38 16 eb 43 2c 67 a3 29 19 c6 00 00 00 00 @.8..C,g.)......
0050: 01 02 00 00 00 00 00 00 06 00 00 00 14 00 00 00 ................
0060: f2 25 82 48 bb 87 a7 dd 1b fd a9 72 2e 35 19 39 .%.H.......r.5.9
0070: 96 3e 3b e0 26 00 00 00 0b 00 00 00 1e 00 00 00 .>;.&...........
0080: 49 4e 54 45 4c 20 45 46 49 32 2e 30 20 54 43 47 INTEL EFI2.0 TCG
0090: 31 2e 32 20 43 6f 6d 70 6c 69 61 6e 74 00 01 02 1.2 Compliant...
00a0: 00 00 00 00 00 00 01 00 00 00 14 00 00 00 dd cb ................
....
I can't find any documentation on what the TCPA table is, or how it's
formatted. Only the existence of this table is mentioned in the ACPI
spec. And looking at the binary data, I can't find anything that
looks like resources in this entry (no "fed4...." words), so I'm not
sure how "plug-and-play" is supposed to know the resources required by
the TPM. Any pointers on how to deal with this would be appreciated.
I've got some ideas on how I can make it work, without breaking the
existing code -- basically a "force" switch that can be a command-line
argument when loading the module. If it sees this, then it does
basically what I did in my driver -- register with the platform bus,
grabbing the appropriate resources. I won't get to that today, but
hopefully I'll get to it soon. Does this sound compatible with how
you want the driver to work?
--
Steve
On Tue, 13 Sep 2005, Kylene Jo Hall wrote:
> On Mon, 2005-09-12 at 19:35 -0500, Steve Tate wrote:
>> The code in the new driver looks good, but unfortunately, it doesn't
>> work for me. I had looked before, and have now verified with updated
>> ACPI tools, and the TPM in this system (an Intel D945GTP motherboard)
>> isn't registered as a distinct device in the ACPI device table. The
>> memory range for the TPM is part of the memory range reserved for the
>> I/O controller (device IOCM), but there's no entry for the TPM itself.
>>
>> I see that there's a BIOS update on Intel's web site, so I'll try
>> that, but do you have any other ideas?
>
> If you can't find an ACPI entry that will work we can add something like
> the platform bus registration that you suggested in parrallel with the
> ACPI stuff, however, I'd like to avoid this if possible as 1.2 is really
> supposed to get this right. We should let Intel know if it is still not
> fixed in the newest BIOS because that is a deviation from the
> specification.
>
>>
>> Incidentally, please do go back and look through the tpm.c patches
>> that I submitted -- the bugs with the bitmask handling are still there
>> (and why is this there anyway? Is it really possible for a system to
>> have more than one TPM?).
>
> I will do that. Yes it is possible to think of scenarios like this
> though we haven't seen it yet. The kernel folks were fairly adament
> that we didn't just arbtrarily support only one.
>
> Thanks,
> Kylie
>
>>
>> --
>>
>> Steve
>>
>>
>>
>> On Mon, 12 Sep 2005, Kylene Jo Hall wrote:
>>
>>> Hello-
>>>
>>> I just wanted to make you all aware that I have uploaded a 1.2 TPM
>>> device driver into cvs (note anonymous cvs could take a few hours to
>>> update). The driver still has a ways to go before being LKML ready but
>>> I wanted you to have access to something that should at least be
>>> functional. The device discovery is based on ACPI entries per the 1.2
>>> TCG Specification. I have entered the values the I knew or thought I
>>> knew but would love to add more. If you find the device ID for another
>>> device I'd be happy to add it just email it to me.
>>>
>>> I find the ID of the device on your system you can follow these steps
>>> (please update everyone if you know of an easier way):
>>> 1) cat /prco/acpi/dsdt > ~/dsdt.dat
>>> 2) cd ~
>>> 3) isal -d dsdt.dat
>>> 4) look fro TPM in the generated dsdt.dsl file.
>>>
>>> Thanks,
>>> Kylie Hall
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> SF.Net email is Sponsored by the Better Software Conference & EXPO
>>> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
>>> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
>>> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
>>> _______________________________________________
>>> tpmdd-devel mailing list
>>> tpm...@li...
>>> https://lists.sourceforge.net/lists/listinfo/tpmdd-devel
|