Hi Kyösti,
Thank you for the hints. I have some comments below.
On Sat, Jan 13, 2018 at 8:59 PM, Kyösti Mälkki kyosti.malkki@gmail.com wrote:
Hi
On Sat, Jan 13, 2018 at 8:51 PM, Hal Martin hal.martin@gmail.com wrote:
Hi all,
Is there any documentation around describing how coreboot scans for PCI Express buses and devices?
Don't know of one. It's a recursive walk of the PCI tree, with the assigned bus number incremented for every detected PCI bridge. How vendor firmware does assignment may be different.
I have an expansion module for the Intense PC I'd like to get working
with
Coreboot. The expansion module adds 4 Intel Gigabit Ethernet interfaces (82574L) via PCI Express 4 PCIe ports. All interfaces are on the same physical FACE module.
In the vendor firmware, all four cards are properly detected: 01:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection 03:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection 06:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection 07:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
But in coreboot, only the first two cards are detected: 01:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection 03:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
It seems from the coreboot uart output that coreboot isn't scanning PCIe buses 6 & 7. Looking at pci_scan_bus in src/device/pci_device.c it seems coreboot should be recursively scanning PCI bridges for any devices
behind
them. The lspci output from the vendor firmware and coreboot lists the
same
number of PCI bridges: 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core
processor
PCI Express Root Port (rev 09) 00:01.1 PCI bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core
processor
PCI Express Root Port (rev 09)
Can you send 'lspci -tnv' output and 'sudo lspci -xxxx' from vendor firmware boot. Same for coreboot and perhaps the complete log. There are more PCIe root ports on device 0:1c.0, some of those you have marked disabled in devicetree.cb.
Just to verify again, I enabled all the PCI Express devices in the devicetree.cb to see if the missing devices would appear. Unfortunately they didn't.
I am wondering though, all of these devices share the same PCIe clock signal, which goes through a differential clock driver which according to the manufacturer's documentation: "The device distributes a differential input clock to four differential pairs of clock outputs either with or without PLL. The clock outputs are controlled by input selection of several static control signals and Host SMBus interface. The device oriented and designed for PCI Express applications."
I used `i2cdetect -l` on the stock firmware and in coreboot, but nothing for SMBus appeared. I'm wondering if perhaps the issue is that this Pericom PI6C20400 clock driver is only providing clock to two of the devices and needs further configuration via SMBus? i2c-3 i2c i915 gmbus dpc I2C adapter i2c-1 i2c i915 gmbus vga I2C adapter i2c-6 i2c DPDDC-C I2C adapter i2c-4 i2c i915 gmbus dpb I2C adapter i2c-2 i2c i915 gmbus panel I2C adapter i2c-0 i2c i915 gmbus ssc I2C adapter i2c-7 i2c DPDDC-D I2C adapter i2c-5 i2c i915 gmbus dpd I2C adapter
The information about the module I am using can be found on pages 36-40 of this document: http://fit-pc.com/download/face-modules/documents/face- modules-hw-specifications.pdf
The lspci output would make this email ~450KB, so I'll only link to them:
Vendor firmware lspci -tnv: https://watchmysys.com/ files/3f6e6fb3-8231-4320-905b-94b11a88d09d/lspci-tnv_compulabfw.txt
Vendor firmware lspci -xxxx: https://watchmysys.com/ files/3f6e6fb3-8231-4320-905b-94b11a88d09d/lspci-xxxx_compulabfw.txt
coreboot lspci -tnv: https://watchmysys.com/files/3f6e6fb3-8231-4320-905b- 94b11a88d09d/lspci-tnv_coreboot.txt
coreboot lspci -xxxx: https://watchmysys.com/files/3f6e6fb3-8231-4320-905b- 94b11a88d09d/lspci-xxxx_coreboot.txt
coreboot cbmem log: https://watchmysys.com/files/3f6e6fb3-8231-4320-905b- 94b11a88d09d/fm4lan_cbmem_console.txt
Thanks, Hal
From the boot logs, it seems that coreboot stops scanning after PCI bus
05:
Default limit should be 63 for sandy/ivy and you could increase it to 127 or 255.
Kyösti