|
From: Kylene Jo H. <kj...@us...> - 2005-09-13 17:38:55
|
See my comments inline below. I don't know what to tell you about the
vagueness of this entry.
Thanks,
Kylie
On Tue, 2005-09-13 at 11:45 -0500, Steve Tate wrote:
> 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 don't know where it is documented right off the top of my head but his
is the boot measurements that are loaded into PCRS as the machine boots
to satisfy trusted boot. I am working on code to pull these and make
them accessible from the os.
> 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?
This sounds like a best case for now.
>
> --
>
> 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
>
>
> -------------------------------------------------------
> 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
>
|