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
[1]: https://review.coreboot.org/c/coreboot/+/46527/3
_______________________________________________
coreboot mailing list -- [email protected]
To unsubscribe send an email to [email protected]
