Dear Peter, dear Michał,
Am 16.10.20 um 17:05 schrieb Paul Menzel:
Am 16.10.20 um 15:22 schrieb Michal Zygowski:
..
PCI: 00:15.0 init
PCI: 00:15.0 init finished in 0 msecs
PCI: 00:15.1 init
PCI: 00:15.1 init finished in 0 msecs
PCI: 00:18.1 init
PCI: 00:18.1 init finished in 0 msecs
Note that there is no init for 15.2 above. I don't know why, if it's
enabled in the mainboard devicetree file.
15.2 is a PCIe root port, so it is natural that there is no init for it,
if the endpoint device isn't detected. There won't be PCIe root port
because AGESA hides it, if endpoint is not detected.
Do you know, what AGESA code does that?
Another thought - have you compared PCI bus numbers and addresses
between vendor BIOS and coreboot? They can change around, certainly
bus numbers but wasn't there a thread a while back with addresses
being confused too?
This is another thing that can be customized. Each mainboard has an
OemCustomize.c file which defines an array of type
PCIe_PORT_DESCRIPTOR., the 3rd (and 4th on some families) parameter in
PCIE_PORT_DATA_INITIALIZER indicate the device number that will be
assigned to the PCIe engines (lanes). So you can freely route the ports
to device numbers.
But isn’t that just for the lanes of CPU/northbridge devices (numbered
below 00:10.x)?
The bridge 15.2 should be part of the Fusion Controller Hub (FCH), and
the for PCIe general purpose lanes (GPP) can be configured there with
`FchGpp->GppLinkConfig`.
I reference the Bolton FCH datasheets [1][2], as I couldn’t find one for
A85X (Hudson-3) specifically.
The AGESA vendor code has `PreInitGppLink()` in
`src/vendorcode/amd/agesa/f15tn/Proc/Fch/Pcie/GppPortInit.c` [3].
I haven’t found out yet, how to figure the lane configuration out from
the board without schematics or the vendor firmware. I’d assume
PortA2B1C1 or PortA2B1C1. Hardcoding them, some hang the system, but I
forgot the two working ones.
I have to further study and analyze that code. Hints are very much
appreciated.
Looking at the Asus A88XM-E files, it turns out there is a macro
`BLDCFG_FCH_GPP_PORT2_PRESENT` to configure this behavior. Defining this
to `TRUE`, the bridge and ethernet device are detected [4].
Unfortunately, it still hangs, when coreboot tries to configure(?) it.
PCI: 00:14.4 bridge ctrl <- 0013
PCI: 00:14.4 cmd <- 00
PCI: 00:14.5 cmd <- 02
PCI: 00:15.0 bridge ctrl <- 0013
PCI: 00:15.0 cmd <- 00
PCI: 00:15.1 bridge ctrl <- 0013
PCI: 00:15.1 cmd <- 06
PCI: 00:15.2 bridge ctrl <- 0013
PCI: 00:15.2 cmd <- 07
Tagging it as `hidden` in devicetree, the hang is worked around, and the
payload is loaded, and the Linux kernel is able to configure everything
itself. So, thank you for the hints, and hopefully, I’ll figure out, why
it hangs.
Kind regards,
Paul
[1]: https://www.amd.com/system/files/TechDocs/51205_Bolton_FCH_BIOS_Dev_Guide.pdf
[2]: https://www.amd.com/system/files/TechDocs/51191_Bolton_FCH_RPR.pdf
[3]: https://review.coreboot.org/plugins/gitiles/coreboot/+/6147314344ae257081ec91dd709b18da283878fc/src/vendorcode/amd/agesa/f15tn/Proc/Fch/Pcie/GppPortInit.c#160
[4]: https://review.coreboot.org/c/coreboot/+/46527/
_______________________________________________
coreboot mailing list -- [email protected]
To unsubscribe send an email to [email protected]
