Hi all
I'm working on porting Coreboot v2 to the MSC-CXB-CD945 com express card (http://www.msc-ge.com/frame/en/produkte/com/com_express/cxb_cd945.html). The design is close to the Kontron 986LCD-M, so it won't be too hard.
This board has an Infineon SLB 9635 TPM 1.2 chip, on the LPC bridge, for all the TCPA stuffs. I'd like to support this chip (I need it for applicaitons we developped on the board), and in a general way, try to add TCPA support in coreboot.
The TCG ACPI Specification tells us :
"A TCG platform MAY provide an ACPI device object representing the TPM in the ACPI namespace, if the bus where the TPM is located is not PNP capable or the bus is not exposed to the OS for PNP operations."
I will not focus too much on the ACPI table at first but I'd like to add the device in the Config.lb. I'd like to have confirmation on the syntax I'll have to use in the Config.lb file.
Here is the result of lspnp :
00:08 IFX0102 Infineon Trusted Platform Module state = active io 0x4e-0x4f io 0x1670-0x167f mem 0xfed40000-0xfed44fff irq 11
The device is a PNP device : if I don't add an entry for this device in the Config.lb file, will coreboot be able to read and allocate himself the resources ?
If I add an entry, I was thinking about this :
device pci 1f.0 on # LPC bridge chip drivers/tpm/slb9635 end end
Then I define resources functions in my driver.
Do I need to add an entry like this "device pnp ... on end" ? I don't really understand how this works. It only seems suitable for super i/o logical functions.
By the way I (of course) don't have the datasheet of the component, just the TPM linux driver source code from trust.rub.de, and traces from acpidump, lspnp...
Last question : when the board will be supported, I'll send patches to the mailing list. The original bios was developped by phoenix. For my personnal usage, I may re-use ACPI and SMBIOS tables extracted from this bios. But, for the patches I'll send, am I allowed to use them ?
Regards, Thomas
PS : this thread is not meant to become a fight between DRM / free software. I don't like DRM and stuffs like this but I must admit that the TPM chip is usefull for some kind of applications.
On Sun, Nov 23, 2008 at 2:09 AM, Thomas Jourdan tjourdan@neuf.fr wrote:
00:08 IFX0102 Infineon Trusted Platform Module state = active io 0x4e-0x4f io 0x1670-0x167f mem 0xfed40000-0xfed44fff irq 11
The device is a PNP device : if I don't add an entry for this device in the Config.lb file, will coreboot be able to read and allocate himself the resources ?
If I add an entry, I was thinking about this :
device pci 1f.0 on # LPC bridge chip drivers/tpm/slb9635 end end
Then I define resources functions in my driver.
should work fine.
Last question : when the board will be supported, I'll send patches to the mailing list. The original bios was developped by phoenix. For my personnal usage, I may re-use ACPI and SMBIOS tables extracted from this bios. But, for the patches I'll send, am I allowed to use them ?
I don't know.
ron
ron minnich wrote:
Last question : when the board will be supported, I'll send patches to the mailing list. The original bios was developped by phoenix. For my personnal usage, I may re-use ACPI and SMBIOS tables extracted from this bios. But, for the patches I'll send, am I allowed to use them ?
I don't know.
There is some question as to the legal status of re-using tables - in the absence of any clear legal guidance I think that we should err on the side of safety and not allow tables from commercial BIOSen.
Jordan
There is some question as to the legal status of re-using tables - in the absence of any clear legal guidance I think that we should err on the side of safety and not allow tables from commercial BIOSen.
It wont work because lot of I/O resources is static in the ACPI. Creating some minimalistic ACPI tables should not be too difficult.
http://www.coreboot.org/ACPI_in_coreboot
Rudolf
Le lundi 24 novembre 2008 à 20:45 +0100, Rudolf Marek a écrit :
There is some question as to the legal status of re-using tables - in the absence of any clear legal guidance I think that we should err on the side of safety and not allow tables from commercial BIOSen.
It wont work because lot of I/O resources is static in the ACPI. Creating some minimalistic ACPI tables should not be too difficult.
http://www.coreboot.org/ACPI_in_coreboot
Rudolf
I added basic support to create a TCPA ACPI table. The TCPA table have 2 specific fields : log_address and max_log_length. The log address should point to a buffer of max_log_length bytes (0x10000 in my case) in the ACPI Non-volatile Storage.
I guess this is the responsability of coreboot to reserve a portion of RAM for the ACPI NV Storage. I'm interested in adding this functionnality in coreboot but how usefull is it ?
Thomas
Thomas Jourdan wrote:
I guess this is the responsability of coreboot to reserve a portion of RAM for the ACPI NV Storage. I'm interested in adding this functionnality in coreboot but how usefull is it ?
We need that anyway for suspend.
Also I know there are other people using TPMs with coreboot, so I'm sure there is synergy possible.
//Peter
Le lundi 24 novembre 2008 à 07:26 -0800, ron minnich a écrit :
On Sun, Nov 23, 2008 at 2:09 AM, Thomas Jourdan tjourdan@neuf.fr wrote:
00:08 IFX0102 Infineon Trusted Platform Module state = active io 0x4e-0x4f io 0x1670-0x167f mem 0xfed40000-0xfed44fff irq 11
The device is a PNP device : if I don't add an entry for this device in the Config.lb file, will coreboot be able to read and allocate himself the resources ?
If I add an entry, I was thinking about this :
device pci 1f.0 on # LPC bridge chip drivers/tpm/slb9635 end end
Then I define resources functions in my driver.
should work fine.
I implemented the driver but unfortunately, I won't be able to test it before a couple of weeks.
I needed to define a fixed memory resource, I guess it will not be allocated / handled properly (see my other post : Possible bug in resources allocation). By the way I see have the issue is already known (coreboot v3, northbridge.c for i945).
Thomas
-
Jordan Crouse -
Peter Stuge -
ron minnich -
Rudolf Marek -
Thomas Jourdan