My question is pretty much as title. I'll explain my use cases below.
1. https://review.coreboot.org/c/coreboot/+/82633 With this patch, I'm still getting leftover devices messages in the log for devices 0:1.1 and 0:1.2. This is with no card plugged into the PCIe x16 slot. As far as I can tell those devices are for when the Ivy Bridge CPU's PCIe lanes have to run in x8 or x4 mode. I don't know what device 0:4.0 is for. 0:6.0 is for the extra 4 PCIe lanes for Xeon CPUs. None of the Asus P8x7x series boards have them wired up. So is there a way for me to "remove" the latter two devices from chipset.cb with the mainboard devicetree.cb, or do I have to hide them like I did in the patch? How do I completely get rid of leftover devices?
2. https://review.coreboot.org/c/coreboot/+/85413 and https://review.coreboot.org/c/coreboot/+/85768
These boards, as well as p8z77-m_pro (likely any standard ATX board in this family), have one x16 slot and one x8 slot that are both serviced by the 16 PCIe lanes out of the CPU. The card presence pin on the x8 slot activates a CPU hard strap and enables bifurcation, as well as configures a bunch of PCIe mux/switches to send the bifurcated lanes to the x8 slot. Together they reconfigure the CPU's PCIe lanes into two x8 slots.
But wait, there's more.
p8z77-v and sabertooth_z77 have a third PCIe x4 slot serviced by the PCH, but the 4 lanes are shared with some other x1 slots and devices. They can configure the PCIe x4 slot to really be x4, or the 4 lanes can be configured as 4 x1 ports for various x1 slots or onboard devices. This requires changing a soft strap as well as manipulating some GPIOs in the SIO chip, and the devicetree changed to match. I have the SIO GPIO part figured out, the soft strap I can only come to one possible explanation: reflash SPI descriptor with the changed soft strap and force a platform reset. To verify I'll need to get a board and actually check the flash chip for changes.
But how do I manage the devicetree dynamically? Say for sabertooth I'll want to turn on PCH PCIe root port 1 only if it is set for x4, otherwise I'll need all ports 1-4 on so its three PCIe x1 slots can work along with the x4 slot now being x1 only.
Thanks Keith
Hi Keith,
I can't speak to the devicetree stuff, but I did find something interesting regarding the PCH PCIe ports:
p8z77-v and sabertooth_z77 have a third PCIe x4 slot serviced by the PCH, but the 4 lanes are shared with some other x1 slots and devices. They can configure the PCIe x4 slot to really be x4, or the 4 lanes can be configured as 4 x1 ports for various x1 slots or onboard devices. This requires changing a soft strap as well as manipulating some GPIOs in the SIO chip, and the devicetree changed to match. I have the SIO GPIO part figured out, the soft strap I can only come to one possible explanation: reflash SPI descriptor with the changed soft strap and force a platform reset. To verify I'll need to get a board and actually check the flash chip for changes.
Changing the IFD at runtime seems like an impractical way to achieve this, especially since the IFD is normally supposed to be read only. I suspect there's another, undocumented method to change the configuration. On ICH/PCH datasheets, there is an RCBA register (Root Port Configuration Register) that indicates the current port configuration. On the 7 series PCH's, that is at RCBA32(0x400), bits 3:2 for ports 5-8 and bits 1:0 for ports 1:4. However, these bitfields are documented as read only in the public datasheets. However, in the public ICH9 datasheet (and seemingly only the ICH9 datasheet; other datasheets like ICH7, ICH8, ICH10, etc don't have this detail) the equivalent register at RCBA32(0x224) lists the bitfields as R/W, with a note saying that writing to them is for debug/testing and should be treated as read only and modifiable only through hard straps (it seems like ICH9 didn't use IFD soft straps for this). Based on that note, I assume this mechanism is intended for testing different PCH PCIe configurations without reflashing the IFD. I haven't tested this yet on any platform but it does seem plausible that this mechanism exists on chipsets other than ICH9.
Cheers, Nicholas
-
Keith Hui -
Nicholas Chin