Dear Nico,
Am 22.10.20 um 22:37 schrieb Nico Huber:
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.
Looking at this again, it actually does not seem to hang here, but only serial console stops working. It hangs later in SeaBIOS, but without serial console, I do not know where.
Can the serial console be enabled again so I can get a whole log? (`CONFIG_HUDSON_LEGACY_FREE` is already unset.)
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.
Indeed, I used `off` now in patch set 3 [1].
Kind regards,
Paul