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
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
I reference the Bolton FCH datasheets , as I couldn’t find one for
A85X (Hudson-3) specifically.
The AGESA vendor code has `PreInitGppLink()` in
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
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 .
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