On 23.06.2018 07:58, Jorge Fernandez Monteagudo wrote:
I guess it's used, but you need an acpi name for all devices along the path. "LIBR" is the name for the LPC device, there should also be one for the PCI bus/domain. I would try `src/northbridge/amd/pi/00660F01/ northbridge.c`.
Could you point me to an example to know what I have to look for, p.e, to a good supported board or something related. I'm still introducing me in the coreboot world :)
Didn't use a TPM with coreboot so far, so I don't know full working examples (but there are some, I'm sure).
Regarding the domain, the code for 00730F01 looks like what I had in mind: `src/northbridge/amd/pi/00730F01/northbridge.c:813`.
Background: the TPM driver calls acpi_device_path() which walks the devicetree hierarchy up and asks every device for its acpi_name(). If you look at your devicetree, there is above your TPM, the `device pci 14.3` (LIBR), then `device domain 0` (PCI0) and finally an implicit root device (_SB_). The latter is hardcoded for all of coreboot.
Now this acpi_name() has one peculiarity: When one device doesn't have this function, its parent's acpi_name() function is queried. That is why the acpi_name() implementations don't just `return "...";` but check for what device they were called, first.
The names returned have to match the names in the static ACPI tables. See your board's `dsdt.asl` and what it includes.
Nico
Hi!
I'm still trying to boot the linux kernel when the TPM is enabled...
Background: the TPM driver calls acpi_device_path() which walks the devicetree hierarchy up and asks every device for its acpi_name(). If you look at your devicetree, there is above your TPM, the `device pci 14.3` (LIBR), then `device domain 0` (PCI0) and finally an implicit root device (_SB_). The latter is hardcoded for all of coreboot.
Now this acpi_name() has one peculiarity: When one device doesn't have this function, its parent's acpi_name() function is queried. That is why the acpi_name() implementations don't just `return "...";` but check for what device they were called, first.
I can see the TPM is initialized ok
agesawrapper_amdinitenv() returned AGESA_SUCCESS TPM initialization. TPM: Init Found TPM SLB9660 TT 1.2 by Infineon TPM: Open TPM: Startup TPM: command 0x99 returned 0x0 TPM: OK. Timestamp - end of romstage: 7155473845
Lately, when the ACPI table is written I can see:
ACPI: Writing ACPI tables at 8fdc6000. ACPI: * FACS ACPI: * DSDT ACPI: * FADT pm_base: 0x0800 ACPI: added table 1/32, length now 40 ACPI: * SSDT CBFS: 'Master Header Locator' located CBFS at [200:7fffc0) CBFS: Locating 'pci1002,9874.rom' CBFS: Found @ offset b7e00 size fc00 Mapping PCI device 10029874 to 10029870 In CBFS, ROM address for PCI: 00:01.0 = ff8b8048 PCI expansion ROM, signature 0xaa55, INIT size 0xfc00, data ptr 0x01c0 PCI ROM image, vendor ID 1002, device ID 9870, PCI ROM image, Class Code 030000, Code Type 00 PCI: 00:01.0: Missing ACPI scope _SB._SB.LIBR.TPM: LPC TPM PNP: 0c31.0 ACPI: added table 2/32, length now 44 ACPI: * MCFG ACPI: * TCPA TCPA log created at 8fdb6000 ACPI: added table 3/32, length now 48 ACPI: * MADT ACPI: added table 4/32, length now 52 current = 8fdc8050 CBFS: 'Master Header Locator' located CBFS at [200:7fffc0) CBFS: Locating 'pci1002,9874.rom' CBFS: Found @ offset b7e00 size fc00 Mapping PCI device 10029874 to 10029870 In CBFS, ROM address for PCI: 00:01.0 = ff8b8048 PCI expansion ROM, signature 0xaa55, INIT size 0xfc00, data ptr 0x01c0 PCI ROM image, vendor ID 1002, device ID 9870, PCI ROM image, Class Code 030000, Code Type 00 ACPI: * VFCT at 8fdc8050 Copying initialized VBIOS image from 000c0000 ACPI: added table 5/32, length now 56 ACPI: * HPET ACPI: added table 6/32, length now 60 ACPI: added table 7/32, length now 64 ACPI: * IVRS at 8fdd7d28 AGESA IVRS table NULL. Skipping. ACPI: * SRAT at 8fdd7d28 AGESA SRAT table NULL. Skipping. ACPI: * SLIT at 8fdd7d28 AGESA SLIT table NULL. Skipping. ACPI: * AGESA ALIB SSDT at 8fdd7d30 ACPI: added table 8/32, length now 68 ACPI: * SSDT at 8fde0470 ACPI: added table 9/32, length now 72 ACPI: * SSDT for PState at 8fde0cc4 ACPI: done. ACPI tables: 109776 bytes. smbios_write_tables: 8fdb5000
Where the path to TPM is:
_SB._SB.LIBR.TPM: LPC TPM PNP: 0c31.0
It seems all ok for coreboot (device detected, initialized, no error messages, etc) but the linux kernel complains...
Is there some tool to analyze the ACPI table from coreboot to extract paths or anything relevant in order to know
what it's not working?
The names returned have to match the names in the static ACPI tables. See your board's `dsdt.asl` and what it includes.
My board's dsdt.asl is the src/mainboard/amd/bettong/dsdt.asl from repository. I'm using that board to
do my testing, if you should take a look.
Attached is the trace log I get from coreboot.
Thanks for your help!
Jorge
________________________________ De: Nico Huber nico.h@gmx.de Enviado: sábado, 23 de junio de 2018 12:28:05 Para: Jorge Fernandez Monteagudo; coreboot@coreboot.org; Zaolin Asunto: Re: [coreboot] RV: Error booting with TPM enabled.
On 23.06.2018 07:58, Jorge Fernandez Monteagudo wrote:
I guess it's used, but you need an acpi name for all devices along the path. "LIBR" is the name for the LPC device, there should also be one for the PCI bus/domain. I would try `src/northbridge/amd/pi/00660F01/ northbridge.c`.
Could you point me to an example to know what I have to look for, p.e, to a good supported board or something related. I'm still introducing me in the coreboot world :)
Didn't use a TPM with coreboot so far, so I don't know full working examples (but there are some, I'm sure).
Regarding the domain, the code for 00730F01 looks like what I had in mind: `src/northbridge/amd/pi/00730F01/northbridge.c:813`.
Background: the TPM driver calls acpi_device_path() which walks the devicetree hierarchy up and asks every device for its acpi_name(). If you look at your devicetree, there is above your TPM, the `device pci 14.3` (LIBR), then `device domain 0` (PCI0) and finally an implicit root device (_SB_). The latter is hardcoded for all of coreboot.
Now this acpi_name() has one peculiarity: When one device doesn't have this function, its parent's acpi_name() function is queried. That is why the acpi_name() implementations don't just `return "...";` but check for what device they were called, first.
The names returned have to match the names in the static ACPI tables. See your board's `dsdt.asl` and what it includes.
Nico
-
Jorge Fernandez Monteagudo -
Nico Huber