On 19.10.20 19:06, Paul Menzel wrote:
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
This enables resources for the bridge as well as for downstream devices, and bus mastering. It needs the whole log to see if the allocation is alright. It's not unlikely that the problem is related to the downstream device.
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.
`hidden` has semantics tailored to specific Intel devices (that are active, don't show their VID/DID and are _not_ PCI bridges). It also basically disables all device operations in coreboot. Probably the same as if you set it to `off` in the devicetree.
Nico