Dear coreboot folks,
Trying to finish the Asus F2A85-M PRO coreboot port (AMD Family 15h/Hudson), the internal network device does not work with the state from [1].
With the vendor firmware 6601, it is
04:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 09)
behind PCI bridge 00:15.2.
-[0000:00]-+-00.0 +-00.2 +-01.0 +-01.1 +-10.0 +-10.1 +-11.0 +-12.0 +-12.2 +-13.0 +-13.2 +-14.0 +-14.2 +-14.3 +-14.4-[01]-- +-15.0-[02]-- +-15.1-[03]----00.0 +-15.2-[04]----00.0 +-18.0 +-18.1 +-18.2 +-18.3 +-18.4 -18.5
In the current state [1], coreboot says device 00:15.2 is disabled
Show all devs... After init. Root Device: enabled 1 CPU_CLUSTER: 0: enabled 1 DOMAIN: 0000: enabled 1 APIC: 10: enabled 1 PCI: 00:00.0: enabled 1 PCI: 00:00.2: enabled 1 PCI: 00:01.0: enabled 1 PCI: 00:01.1: enabled 1 PCI: 00:02.0: enabled 0 PCI: 00:03.0: enabled 0 PCI: 00:04.0: enabled 0 PCI: 00:05.0: enabled 0 PCI: 00:06.0: enabled 0 PCI: 00:07.0: enabled 0 PCI: 00:08.0: enabled 0 PCI: 00:10.0: enabled 1 PCI: 00:10.1: enabled 1 PCI: 00:11.0: enabled 1 PCI: 00:12.0: enabled 1 PCI: 00:12.2: enabled 1 PCI: 00:13.0: enabled 1 PCI: 00:13.2: enabled 1 PCI: 00:14.0: enabled 1 PCI: 00:14.1: enabled 0 PCI: 00:14.2: enabled 1 PCI: 00:14.3: enabled 1 PCI: 00:14.4: enabled 1 PCI: 00:14.7: enabled 0 PCI: 00:15.0: enabled 1 PCI: 00:15.1: enabled 1 PCI: 00:15.2: enabled 0 PCI: 00:18.0: enabled 1
But it is enabled in the devicetree `src/mainboard/asus/f2a85-m/devicetree_f2a85-m_pro.cb`.
device pci 15.2 on end # PCI bridge
Please find the spew log attached. Any help is appreciated.
Kind regards,
Paul
[1]: https://review.coreboot.org/c/coreboot/+/46021/ "mb/asus/f2a85-m_pro: Enable super-i/o LDNs 0x0f and 0x14"
Paul Menzel wrote:
With the vendor firmware 6601, it is
04:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd.RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 09)
behind PCI bridge 00:15.2.
..
In the current state [1], coreboot says device 00:15.2 is disabled
Show all devs... After init.
..
PCI: 00:15.0: enabled 1 PCI: 00:15.1: enabled 1 PCI: 00:15.2: enabled 0
But it is enabled in the devicetree `src/mainboard/asus/f2a85-m/devicetree_f2a85-m_pro.cb`.
device pci 15.2 on end # PCI bridge
spew log
..
Enabling cache Setting up local APIC... apic_id: 0x11 done. siblings = 01, CPU #1 initialized All AP CPUs stopped (1060 loops) CPU0: stack: 0x5fef4000 - 0x5fef5000, lowest used address 0x5fef455c, stack used: 2724 bytes CPU1: stack: 0x5fef3000 - 0x5fef4000, lowest used address 0x5fef3dbc, stack used: 580 bytes CPU_CLUSTER: 0 init finished in 64 msecs PCI: 00:00.0 init PCI: 00:00.0 init finished in 0 msecs
..
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.
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?
Sorry I can't suggest anything more concrete
//Peter
Hi Peter,
..
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.
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.
Sorry I can't suggest anything more concrete
//Peter _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Best regards,
Hi,
if we are sure it is behind 15.2 - one can also try to make it hidden. This way the device will be enabled no matter what. If that solves the problem - you need to investigate why coreboot does not enable the device.
Best,
Chris
On 10/16/20 3:05 PM, Peter Stuge wrote:
Paul Menzel wrote:
With the vendor firmware 6601, it is
04:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd.RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 09)
behind PCI bridge 00:15.2.
..
In the current state [1], coreboot says device 00:15.2 is disabled
Show all devs... After init.
..
PCI: 00:15.0: enabled 1 PCI: 00:15.1: enabled 1 PCI: 00:15.2: enabled 0
But it is enabled in the devicetree `src/mainboard/asus/f2a85-m/devicetree_f2a85-m_pro.cb`.
device pci 15.2 on end # PCI bridgespew log
..
Enabling cache Setting up local APIC... apic_id: 0x11 done. siblings = 01, CPU #1 initialized All AP CPUs stopped (1060 loops) CPU0: stack: 0x5fef4000 - 0x5fef5000, lowest used address 0x5fef455c, stack used: 2724 bytes CPU1: stack: 0x5fef3000 - 0x5fef4000, lowest used address 0x5fef3dbc, stack used: 580 bytes CPU_CLUSTER: 0 init finished in 64 msecs PCI: 00:00.0 init PCI: 00:00.0 init finished in 0 msecs
..
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.
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?
Sorry I can't suggest anything more concrete
//Peter _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Christian Walter wrote:
if we are sure it is behind 15.2 - one can also try to make it hidden.
Sounds like that's worth a try. How to do that?
//Peter
Dear Peter, dear Michal,
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.
Kind regards,
Paul
[1]: https://www.amd.com/system/files/TechDocs/51205_Bolton_FCH_BIOS_Dev_Guide.pd... [2]: https://www.amd.com/system/files/TechDocs/51191_Bolton_FCH_RPR.pdf [3]: https://review.coreboot.org/plugins/gitiles/coreboot/+/6147314344ae257081ec9...
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
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
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
-
Christian Walter -
Michal Zygowski -
Nico Huber -
Paul Menzel -
Peter Stuge