coreboot

Walter Sonius wrote in #note-3:

Thanks for the comprehensive report, a fraction can be understood where Bus 01 claims a unlimited big space while it overlaps with part of Bus 00 already claimed MMIO space.

While I'm trying to understand the rest of the report I made another log set zbox-ci320nano-mmio-pm02-patch-no000.zip in which the 00.0 device was removed from devicetree.cb, can you spot anything obvious there since it still gives the wifi PCI bus 0xfffffff issue and blocks the driver from loading?

for some reason Linux doesn't see the PCIe RP on 1c.2 at all, which causes PCI bus 01 to not have a parent bridge, and the resources to conflict (since Linux is treating it as a peer rather than a subordinate). If I had to guess, it's because 1c.0 is being disabled, and you're not supposed to disable function 0 if there are other enabled functions (normally, you would remap 1c.2 to 1c.0).
I would probably add some more debug output to src/soc/intel/baytrail/pcie.c so we can see exactly what paths are being taken for each PCIe root port. definitely print the strap output and ensure that the PCIe bifurcation matches the layout of your board. It could be that the vendor BIOS was ignoring/overriding that strapping

Are the following tips/hacks applied to devicetree.cb and or *.asl files within the port its source code?

Ensure bridge 00:1c.2 is properly declared with subordinate bus
Define bridge window in _CRS method

those are addressed simply by removing the static declaration for the PCI bus in DT.

The dsdt grep values PNP/RP are 1 and 4, which are the same as for the OEM dsdt. Is it allowed to post the OEM BIOS dsdt.dsl for further analysis?

I don't believe this is an ACPI issue

After searching for reg_script_run I edited line 182 and 186 dev->enabled = 0; to dev->enabled = 1;. Now in the OS the 4 Rootports 1c.0-3 are listed with lspci and miniPCIe 1c.2 intel wifi works again and is correctly listed as PCI device 3 (with your recent MMIO 4G PM02 patch included).

that's great!

However the onboard Realtek NIC is still not listed... but this is of course just still a hack. Besides these PCIe bus setup issue I'm starting to think the Realtek may also has some GPIO / resetpin issue itself?

possibly, or a misconfigured CLK_REQ line. I see you have all 4 configured with 20k PU, try without - just use GPIO_FUNC1, for all 4

Altering the SCORE GPIO values 3-6 for CLK_REQ didn't make a difference, however I found some interesting logs on www.linux-hardware.org which remembered me of a BIOS update long long ago which may have altered the PCIe device numbering to its current location or maybe its a revision thing?

#device 16 see url
  SysFS ID: /devices/pci0000:00/0000:00:1c.0/0000:01:00.0
  SysFS BusID: 0000:01:00.0
  Hardware Class: network
  Model: "Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller"
  Vendor: pci 0x10ec "Realtek Semiconductor Co., Ltd."
  Device: pci 0x8168 "RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller"
  SubVendor: pci 0x19da "ZOTAC International (MCO) Ltd."
  SubDevice: pci 0x8168 
  Revision: 0x07
  Driver: "r8169"
  Driver Modules: "r8169"
  Device File: enp1s0

#device 15 see url
  SysFS ID: /devices/pci0000:00/0000:00:1c.1/0000:02:00.0
  SysFS BusID: 0000:02:00.0
  Hardware Class: network
  Model: "Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller"
  Vendor: pci 0x10ec "Realtek Semiconductor Co., Ltd."
  Device: pci 0x8168 "RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller"
  SubVendor: pci 0x19da "ZOTAC International (MCO) Ltd."
  SubDevice: pci 0x8168 
  Revision: 0x07
  Driver: "r8169"
  Driver Modules: "r8169"
  Device File: enp2s0

device 16
device 15

The coreboot Asrock H110M-DVS port has the SuperIO nuvoton GPIOs under suspicion for keeping the Realtek NIC in a permanent reset state. I know my port reuses the nct6776 code since the nct5577d share the same id but is really a smaller chip with less features. May try to alter those GPIO's and do some more superiotool logging to match it up with OEM values.