Re: [coreboot] AMD IMC open source firmware replacement
by Rudolf Marek
Dne 30.5.2018 v 16:06 Mike Banon napsal(a):
> Hi Rudolf,
>
> Regarding this part:
> " To check if IMC is active check if PCI 0:14.3 0x40 bit7 set. "
> what command do I need to use to check this?
Try:
sudo setpci -s 14.3 40.b
Despite command name, it will print the value.
Thanks
Rudolf
1 week, 3 days
Lenovo T410 Coreboot
by A. Veek
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi @ all,
is there a Coroboot for the Lenovo T410 Laptop?
Greetings
Alex Veek
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iF4EAREIAAYFAlNxKzsACgkQ53cWmi2XuzOOXAD8CNLPoycJNftQzeHnMQbl8ZG9
4y2SPIHwLota1/Gsfm0BAJzhG2M+MKXDBJgazHjt/HM2DyAeHi6S24sGcwd1W2GN
=sFKM
-----END PGP SIGNATURE-----
1 month
FOSDEM Hardware Enablement Devroom
by Paul Kocialkowski
A Hardware Enablement devroom will be taking place at FOSDEM this year,
on Sunday 10 December 2017. This newly-created devroom is the result of
3 proposals that were merged together. It is co-organized by several
individuals.
The devroom covers all aspects related to hardware enablement and
support with free software, including aspects related to boot software,
firmwares, drivers and userspace tools and adaptation.
Proposals for talks related to these topics are welcome and can be
submitted until Sunday 26 November 2017 via the pentabarf interface.
Short talks are encouraged over longer ones in order to cover a wide
range of topics.
The announcement for the devroom, that contains all the useful
information, was published at:
https://lists.fosdem.org/pipermail/fosdem/2017-October/002649.html
Cheers and see you at FOSDEM!
--
Paul Kocialkowski, developer of free digital technology and hardware
support
Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/
1 month, 2 weeks
Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board
by Jonathan Neuschäfer
On Fri, Jun 22, 2018 at 03:04:06PM +0800, Shawn wrote:
> Hi Jonathan,
>
> On Thu, Jun 21, 2018 at 7:48 PM, Jonathan Neuschäfer
[...]
> > With the unfinished coreboot port, I want it to look like this (although
> > *a lot* of work has to be done on coreboot first, and I'm currently not
> > actively working on that, for a few months):
> >
> > MSEL (ROM0) -> ZSBL (ROM1) -> coreboot (+bbl?) -> Linux, or
> > MSEL (ROM0) -> coreboot (+bbl?) -> Linux
> >
> > ZSBL can be skipped, so you don't need to run closed source ROM code, at
> > least as far as the hardware is concerned.
> >
> Is ZSBL really can be skipped? I thought it was part of internal ROM
> inside the chip.
Yes. If you set the MSEL switches to 0001, the code in the MSEL ROM
(aka. ROM0) jumps directly into the memory-mapped SPI flash, instead of
into the big ROM1, where ZSBL is.
Coreboot doesn't yet support this mode, but the hardware allows it.
> > (And note that this is just the situation on this particular SoC. Other
> > SoCs from SiFive or other vendors may boot differently.)
> >
> Well, if FSBL is the place where coreboot comes into play, we might
> only have two options: 1, Reversing the FSBL which is ~9k assembly LOC
> 2, SiFive make the FSBL open source( I don't see any reason why they
> don't do it if they intend to build an open eco-system for RISC-V).
A high-level list of tasks that FSBL performs is in the manual[1]:
• Switch core frequency to 1 GHz (or 500 MHz if TLCLKSEL =1) by
configuring and running off the on-chip PLL
• Configure DDR PLL, PHY, and controller
• Set GEM GXL TX PLL to 125 MHz and reset it
• If there is an external PHY, reset it
• Download BBL from a partition with GUID type
2E54B353-1271-4842-806F-E436D6AF69851
• Scan the OTP for the chip serial number
• Copy the embedded DTB to DDR, filling in FSBL version, memory
size, and MAC address
• Enable 15 of the 16 L2 ways (this removes almost all of the L2
LIM memory)
• Jump to DDR memory (0x8000_0000)
Initializing the PLLs and reading the OTP ROM should be easy enough
because both are documented in, I think, sufficient detail.
Section 20.3 describes the initialization sequence for the DRAM
controller, but leaves out the values for the register for "memory
timing settings, PAD mode configuration, initialization, and training."
It says: "Please contact SiFive directly to determine the complete
register settings for your application."
I will ask on the forum.
Assuming that SiFive will tell us the values of the missing
configuration registers, I don't think we need to reverse-engineer FSBL.
Greetings,
Jonathan Neuschäfer
[1]: https://www.sifive.com/documentation/chips/freedom-u540-c000-manual/
4 months, 1 week
Re: [coreboot] POWER9 / Talos II coreboot support?
by Timothy Pearson
As of late last week:
W have the processor user guide, full register documentation, and a
smattering of other resources released publicly [1]. The PHB
documentation is still in process and still moving forward, along with
the electrical datasheet.
If you are interested in documentation that isn't already available and
isn't on the to-do list, please let me know. My understanding is that
the list above should be pretty much everything needed for firmware work.
[1] https://wiki.raptorcs.com/wiki/Category:Documentation
On 06/07/2018 08:05 PM, ron minnich wrote:
> where are we on the docs at this point
>
>
> On Thu, Jun 7, 2018 at 5:59 PM Timothy Pearson
> <tpearson(a)raptorengineering.com <mailto:tpearson@raptorengineering.com>>
> wrote:
>
> For anyone wanting a more affordable development platform for POWER9,
> check out the Talos II Lite:
>
> https://raptorcs.com/TALOSIILITE/
>
> Hopefully we're getting down to a price point where coreboot development
> becomes more practical (if still a bit painful)?
>
> Looking forward to seeing coreboot on ppc64el systems!
>
> On 05/29/2018 03:45 PM, Timothy Pearson wrote:
>> Sorry, can't add today....it's a little over 6,000 pages of new
>> documentation. Still, hardly light reading!
>
>> On 05/29/2018 03:39 PM, Timothy Pearson wrote:
>>> Register documentation was published today. Links to the three
> volumes
>>> (over 7000 pages of documentation!)
>
>>>
> https://wiki.raptorcs.com/wiki/File:POWER9_Registers_vol1_version1.1_pub.pdf
>
>>>
> https://wiki.raptorcs.com/wiki/File:POWER9_Registers_vol2_version1.2_pub.pdf
>
>>>
> https://wiki.raptorcs.com/wiki/File:POWER9_Registers_vol3_version1.2_pub.pdf
>
>>> That leaves only the PHB documentation in process at this point.
> Almost
>>> there....
>
>>> On 05/12/2018 02:34 AM, Timothy Pearson wrote:
>>>> On 05/03/2018 06:02 PM, ron minnich wrote:
>
>
>>>>> On Thu, May 3, 2018 at 1:20 PM Timothy Pearson
>>>>> <tpearson(a)raptorengineering.com
> <mailto:tpearson@raptorengineering.com>
> <mailto:tpearson@raptorengineering.com
> <mailto:tpearson@raptorengineering.com>>>
>>>>> wrote:
>
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA256
>
>>>>> I think I was being a bit pessimistic / too careful here.
> We're close
>>>>> to getting the docs publicly released, but that doesn't
> help anyone
>>>>> wanting access right now, which is why I mentioned the
> other route.
>>>>> IBM's committed to getting the documentation released,
> they're just
>>>>> making sure that what they release is actually correct for
> the products
>>>>> it covers.
>
>>>>> It might make sense to get our "working group" together
> over the next
>>>>> few weeks, by which time the documentation should be
> available in public
>>>>> form.
>
>>>>> Are you interested in joining? :-)
>
>
>>>>> of course, but not until those docs are freed up.
>
>
>>>> We're getting there. First manual to be released is the
> processor user
>>>> guide. More to follow, including register documentation, in
> around a week.
>
>>>> Users guide:
>
>>>>
> https://wiki.raptorcs.com/wiki/File:POWER9_um_OpenPOWER_v20GA_09APR2018_p...
>
>>>>> Context: I've been trying for 2 years now to get OPAL released
> under
>>>>> dual gpl2 licensing with the current apache2 license, apache2
> and gpl2
>>>>> are not compatible, so we'd be in a bit of a mess should we use
> OPAL
>>>>> code in coreboot, and it would be easiest if we were able to
> use some of
>>>>> that code.
>
>>>>> The first response from IBM was "why do you think you need
> coreboot?" I
>>>>> worked through that, and there was agreement in the end it ought to
>>>>> happen, said agreement reached about 2 years ago. Stuff Would
> Happen, I
>>>>> was told. After that, silence.
>
>>>> We've reignited this. It's underway. :-)
>
>>>>> This is pretty much par for the course with Power. In 1990 I
> spent two
>>>>> years getting an agreement that would allow me to .... get more
> agreements.
>
>>>> We've plowed through this already and are at the action point.
> For the
>>>> most part, just let me know what you need and I'll see if we can
> get it
>>>> published.
>
>>>>> So close doesn't count. Once I see the kind of docs I need to
> see, not
>>>>> requiring a clickwrap, and covering all aspects of every chip
> on your
>>>>> board, I'm in: I'll order a board. Until then, I can't really
> do much.
>
>>>> Is the NIC an issue? There are several people working on REing the
>>>> hardware with some great progress [1][2], but there's really no
> way to
>>>> get Broadcom to ever release official documentation. Everything
> else on
>>>> the libre-friendly non-SAS version either has docs available or
> we are
>>>> close to getting them published.
>
>>>>> Thanks for your efforts on Power!
>
>>>> No problem! We still consider Power the best path forward for
> powerful
>>>> libre systems at this point, getting really tired of the other
> vendors
>>>> actively working against efforts to create open firmware (this
> includes
>>>> SiFive at this point).
>
>>>> Will keep you posted as we get more docs published online, but
> thought
>>>> you and the others here might at least be interested in the
> users guide.
>
>>>>> ron
>
>
>
>>>> [1] https://wiki.raptorcs.com/wiki/BCM5719
>>>> [2] IRC discussions on #talos-workstation
>
>
>
>
--
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
5 months, 2 weeks
Re: [coreboot] [RFH] Native AMD fam10-15 support
by Taiidan＠gmx.com
On 06/15/2018 03:33 AM, Kyösti Mälkki wrote:
> On Fri, Jun 15, 2018 at 8:58 AM, Taiidan(a)gmx.com <Taiidan(a)gmx.com> wrote:
>
>> On 06/14/2018 08:42 PM, Kyösti Mälkki wrote:
>>> On Thu, Jun 14, 2018 at 4:38 AM, qtux <mail(a)qtux.eu> wrote:
>>> Now, since commit babb2e6 that claims to add S3 support on kgpe-d16 is
>>> within the latter period, I do not quite see how S3 support could have
>>> worked with that commit on kgpe-d16. Or maybe this feature was never
>>> retested once it was rebased and upstreamed. Nor can I see how it
>>> could have worked for any commit in 4.6
>>
>> I just tested S3 again and it worked fine on my v4.6 D16.
>>
>
> Please state the commit hash of the source tree you built and booted from,
> we don't literally have such tag as "v4.6".
I was using the coreboot-4.6.tar.xz from the coreboot download page
which is why I didn't include the hash.
[ 0.000000] DMI: ASUS KGPE-D16/KGPE-D16, BIOS
4.6-db508565d2483394b709654c57533e55eebace51 07/10/2017
>
> Repeat tests with current master.
Thanks, I will have info for you by the end of the this weekend and I
will also investigate things myself if S3 doesn't work...
6 months, 1 week
Re: [coreboot] RV: Error booting with TPM enabled.
by Nico Huber
Hi,
On 29.06.2018 16:13, Jorge Fernandez Monteagudo wrote:
> In 00730F01/northbridge.c I can see:
> [...]
> static struct device_operations pci_domain_ops = {
> [...]
> and in 00660F01/northbridge.c there is no acpi_name! The most related to the previous one is:
> [...]
> static struct device_operations northbridge_operations =
sorry, I wrote `northbridge device` sometimes, what I really meant is
the `domain device`, hence you have to add it to `pci_domain_ops` just
like in the 00730F01 case.
> On monday I'll try to add the method to 00660F01 code!
Good luck!
Nico
>
> ________________________________
> De: Nico Huber <nico.h(a)gmx.de>
> Enviado: viernes, 29 de junio de 2018 15:47:09
> Para: Jorge Fernandez Monteagudo; coreboot(a)coreboot.org; Zaolin
> Asunto: Re: [coreboot] RV: Error booting with TPM enabled.
>
> On 29.06.2018 12:48, Jorge Fernandez Monteagudo wrote:
>> Ok, I think I've found the problem... If I force in 'src/drivers/pc80/tpm/tis.c'
>>
>> the path value to "\\_SB_.PCI0.LIBR" it works!
>>
>> Now, I'll try to guess from where the "\_SB.\_SB.LIBR" current value comes from...
>> but now it's working.
>
> This is expected if you still haven't implemented `.acpi_name` for
> your northbridge device. In case you haven't tried it yet: Just copy
> what `nb/amd/pi/00730F01/northbridge.c` does about `.acpi_name` to
> `nb/amd/pi/00660F01/northbridge.c`.
>
> Again, if the domain device doesn't implement `.acpi_name`, its parent
> device will be asked. And in this case the parent, the root device,
> always returns `\_SB`.
>
> Nico
>
6 months, 2 weeks
vboot
by Akendo
Hey everyone,
I'm reading through the source code and found vboot. It should standing
for verified boot. However I can't find any documentation(except the
source code). Can anyone provide me with some explanation how to get it
going or to make a little more sense of it?
As far as I understand it needs to verify the signature against a
Key/CA. This key should be located within the TPM. But how should the
key/CA look like? Will be a classic x509 be enough?
best regards,
akendo
6 months, 3 weeks
Re: [coreboot] RV: Error booting with TPM enabled.
by Nico Huber
On 29.06.2018 12:48, Jorge Fernandez Monteagudo wrote:
> Ok, I think I've found the problem... If I force in 'src/drivers/pc80/tpm/tis.c'
>
> the path value to "\\_SB_.PCI0.LIBR" it works!
>
> Now, I'll try to guess from where the "\_SB.\_SB.LIBR" current value comes from...
> but now it's working.
This is expected if you still haven't implemented `.acpi_name` for
your northbridge device. In case you haven't tried it yet: Just copy
what `nb/amd/pi/00730F01/northbridge.c` does about `.acpi_name` to
`nb/amd/pi/00660F01/northbridge.c`.
Again, if the domain device doesn't implement `.acpi_name`, its parent
device will be asked. And in this case the parent, the root device,
always returns `\_SB`.
Nico
6 months, 3 weeks
Re: [coreboot] RV: Error booting with TPM enabled.
by Jorge Fernandez Monteagudo
Ok, I think I've found the problem... If I force in 'src/drivers/pc80/tpm/tis.c'
the path value to "\\_SB_.PCI0.LIBR" it works!
Now, I'll try to guess from where the "\_SB.\_SB.LIBR" current value comes from...
but now it's working.
Thanks!
Changes I've made:
static void lpc_tpm_fill_ssdt(struct device *dev)
{
const char *path = acpi_device_path(dev->bus->dev);
u32 arg;
/*
if (!path) {
path = "\\_SB_.PCI0.LPCB";
printk(BIOS_DEBUG, "Using default TPM ACPI path: '%s'\n", path);
}
*/
path = "\\_SB_.PCI0.LIBR";
printk(BIOS_DEBUG, "Using TPM ACPI path: '%s'\n", path);
________________________________
De: coreboot <coreboot-bounces(a)coreboot.org> en nombre de Jorge Fernandez Monteagudo <jorgefm(a)cirsa.com>
Enviado: viernes, 29 de junio de 2018 11:37:43
Para: Nico Huber; coreboot(a)coreboot.org; Zaolin
Asunto: Re: [coreboot] RV: Error booting with TPM enabled.
Hi!
Booting with acpi=noirq I can run the kernel and the dmesg show the next errors:
[ 0.040912] ACPI: Added _OSI(Module Device)
[ 0.040912] ACPI: Added _OSI(Processor Device)
[ 0.040912] ACPI: Added _OSI(3.0 _SCP Extensions)
[ 0.040912] ACPI: Added _OSI(Processor Aggregator Device)
[ 0.040912] ACPI: Added _OSI(Linux-Dell-Video)
[ 0.041885] ACPI BIOS Error (bug): Failure looking up [\_SB.*SB.LIBR], AE_NOT_FOUND (20180313/dswload2-160)
[ 0.044008] ACPI Error: AE_NOT_FOUND, During name lookup/catalog (20180313/psobject-220)
[ 0.044059] ACPI Error: Method parse/execution failed \, AE_NOT_FOUND (20180313/psparse-516)
[ 0.045344] ACPI Error: Invalid zero thread count in method (20180313/dsmethod-760)
[ 0.045395] ACPI Error: Invalid OwnerId: 0x00 (20180313/utownerid-156)
[ 0.045448] ACPI Error: AE_NOT_FOUND, (SSDT:COREBOOT) while loading table (20180313/tbxfload-197)
[ 0.051635] ACPI Error: 1 table load failures, 3 successful (20180313/tbxfload-215)
[ 0.054040] ACPI: Interpreter enabled
[ 0.054100] ACPI: (supports S0 S1 S4 S5)
[ 0.054144] ACPI: Using PIC for interrupt routing
[ 0.054203] HEST: Table parsing has been initialized.
[ 0.054249] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[ 0.054443] ACPI: Enabled 8 GPEs in block 00 to 1F
[ 0.054857] ACPI BIOS Error (bug): Failure looking up [\_SB.PCI0._CRS.TOM1], AE_NOT_FOUND (20180313/psargs-330)
[ 0.054914] ACPI Error: Method parse/execution failed \_SB.PCI0._CRS, AE_NOT_FOUND (20180313/psparse-516)
[ 0.057653] ACPI BIOS Error (bug): Failure looking up [\_SB.PCI0._CRS.TOM1], AE_NOT_FOUND (20180313/psargs-330)
[ 0.057711] ACPI Error: Method parse/execution failed \_SB.PCI0._CRS, AE_NOT_FOUND (20180313/psparse-516)
[ 0.057770] acpi PNP0A08:00: [Firmware Bug]: no secondary bus range in _CRS
[ 0.057823] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[ 0.057873] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
[ 0.058009] acpi PNP0A08:00: _OSC: OS now controls [PCIeHotplug PME AER PCIeCapability]
[ 0.058083] ACPI BIOS Error (bug): Failure looking up [\_SB.PCI0._CRS.TOM1], AE_NOT_FOUND (20180313/psargs-330)
[ 0.058138] ACPI Error: Method parse/execution failed \_SB.PCI0._CRS, AE_NOT_FOUND (20180313/psparse-516)
[ 0.058194] acpi PNP0A08:00: failed to parse _CRS method, error code -5
[ 0.058240] acpi PNP0A08:00: Bus 0000:00 not present in PCI namespace
[ 0.058329] ACPI: IRQ 3 override to edge, high
[ 0.058428] ACPI: IRQ 4 override to edge, high
[ 0.058527] PCI: setting IRQ 5 as level-triggered
[ 0.058580] ACPI: IRQ 7 override to edge, high
[ 0.058675] ACPI: IRQ 11 override to edge, high
[ 0.058770] ACPI: IRQ 10 override to edge, high
Now, I'll try to patch the kernel to show all the symbols parsed...
Any hint is welcome!
Regards
________________________________
De: coreboot <coreboot-bounces(a)coreboot.org> en nombre de Jorge Fernandez Monteagudo <jorgefm(a)cirsa.com>
Enviado: jueves, 28 de junio de 2018 9:36:15
Para: Nico Huber; coreboot(a)coreboot.org; Zaolin
Asunto: Re: [coreboot] RV: Error booting with TPM enabled.
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(a)gmx.de>
Enviado: sábado, 23 de junio de 2018 12:28:05
Para: Jorge Fernandez Monteagudo; coreboot(a)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
6 months, 3 weeks
