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