XIO2001 PCI bridge fails

Hello,

Asserting /GRST will cause the bridge to re-train the link. There is no internal bit that could cause an internal reset. Is the PCI clock running?

Can you send your schematics for review.

Regards.

Attached the basic schematics relevant for DM642 and XIO2001 connections. Attached also some of "lspci" for the bridge's configuration area and some boot messages regarding the brdige configuration.

I have set all corresponding pullups/pulldowns for the xio2001 and the DM642 to work at 66 Mhz, as well a at 33 MHZ with no difference (the DM642 is still not seen after the bridge). The clock (66 or 33) is visible and has "good" shapes. I had enabled CLKRUN_EN and later disabled the CLKRUN_EN in the xio2001 (removing R27 in my schematics)  with no significant difference (when CLKRUN_EN is enabled the CLOCKOUT6 does not show the clock signal, when CLKRUN_EN is disabled the clock at CLOCKOUT6 is correct and always applied).

What I observe is that I need to keep the GPRST of the xio2001 low so that the system starts booting, else the boot process (BIOS) is even not started (at least no BIOS output at the screen). That is , it is not sufficient just to reset the xio2001 , I have to keep it in reset for a while. I suspect that the BIOS hangs within the link training of the bridge, and keeping it in reset allows BIOS to continue. Then with Grub the Linux kernel is loaded and started. During Linux boot Linux can always find the bridge, but nothing behind the bridge. What is not clear for me is: does the BIOS need to pre-configure anything in the bridge before Linux can use it ? No EEPROM is connected to the bridge right now, so the configuration is the <default> configuration.

Linux is using the pci_bios_..  functions to scan the system for PCI devices. What is not clear for me is if the bridge must be "pre-configured" so that downstream devices can be found with configuration cycles ?

regards

sven

Hello Sven,

The BIOS can configure some settings on the bridge, it is possible that the kernel is initializing some registers with wrong values. Have you tried with another version of linux?

I recommend you asking to the linux community for some issues on the PCI-to-PCI Bridge driver of the kernel.

Your schematic looks correct, below are some recommendations just to double-check.

Are you following the power-up sequence? This is also required for the correct initialization.

Is your design ready for an external EEPROM? If so, you can test if setting the registers externally help?

Regards.

Make sure JTAG_TRST and JTAG_TCK are connected to ground.
Disable the clk run protocol by floating CLKRUN_EN.
Select the internal arbiter by floating EXTARB_EN.
Make sure that the combination of terminals M66EN and PCLK66_EN match with your configuration.
Make sure the AC coupling capacitors on PCIE_TX lines are the correct value (0.1uF)

Hi Elias,

thank you for your response. Here are some news:

From the following boot extract I saw that Linux finds the bridge without problems. However, the Xio2001 is behind another PCI bridge (pci0000:00:1a.0) and this bridge is/was configured to be a bridge from bus 00 to bus 05, but with the maximum secondary bus number to be 05. Linux then finds the xio2001 bridge and configures this correctly to be a bridge from bus 05 to bus 06. However, as the bridge that is before the xio2001 is configured (probably by the BIOS) to bridge from 00 to 05 with maximum secondary bus number also set to 05, there is no way to scan devices on bus 06. because it will be filtered by this bridge. Therefore the statement in the dmesg output "[bus 06-06] partially hidden behind bridge 0000:05 [bus 05-05]"

[    0.921249] pci 0000:05:00.0: [104c:8240] type 1 class 0x000604
[    0.921500] pci 0000:05:00.0: supports D1 D2
[    0.921641] pci 0000:00:1a.0: PCI bridge to [bus 05-05]
[    0.921704] pci 0000:00:1a.0:   bridge window [io  0xf000-0x0000] (disabled)
[    0.921739] pci 0000:00:1a.0:   bridge window [mem 0xfff00000-0x000fffff] (disabled)
[    0.921773] pci 0000:00:1a.0:   bridge window [mem 0xfff00000-0x000fffff pref] (disabled)
[    0.922110] pci 0000:05:00.0: PCI bridge to [bus 06-ff]
[    0.922178] pci 0000:05:00.0:   bridge window [io  0x0000-0x0000] (disabled)
[    0.922211] pci 0000:05:00.0:   bridge window [mem 0x00000000-0x000fffff] (disabled)
[    0.922251] pci 0000:05:00.0:   bridge window [mem 0x00000000-0x000fffff pref] (disabled)
[    0.922291] pci_bus 0000:06: [bus 06-06] partially hidden behind bridge 0000:05 [bus 05-05]

What I did then was configuring manually the 00:1a.0 bridge to allow bus 06 request to pass this bridge (setting the secondary maximum bus number to 06). This way I can scan devices on bus 06. I did this and the system freezes. I  use the x86 register 0xfe8 and io-output to scan the pci system. As soon as I scan bus 06 the system hangs up and I need to reboot. I know that it has to do with the xio2001. When I reconfigure the xio2001 (within Linux) setting the secondary bus of the xio2001 to 05 so that bus 06 requests are not passed by the xio2001, the system will not hang. The first bridge 00:1a.0 passes the bus06 configuration request to the xio2001 and the xio2001 simply does not pass the request further downstream. But as soon as I allow the xio2001 (and the 00:1a bridge) to pass bus 06 downstrream transactions, the system hangs up when I do so.

What I already noted is that the BIOS won't load or run (no BIOS screen) unless I keep the xio2001 in reset. Now I suspect the following:

a) When I do not keep the xio2001 in reset after power On:

BIOS loads and scans the pci bus. It finds the xio2001 , configures it and tries to scan behind the xio2001 bridge-->the system hangs and BIOS does not proceed.

b) When I keep the xio2001 in reset during BIOS loading:

BIOS loads and scans the pci bus. It does not find the xio2001 (as it is in reset) and thus no need to scan further downstream. Then, it configures the 00:1a bridge (that is upstream of the xio2001) correctly as bridge from 00 to 05 with max. bus number downstream 05 (as it has not found the xio2001).

When Linux boots the xio2001 was already out of reset and Linux finds the 00:1a bridge and finds the xio2001 downstream. But, as the upstream bridge 00:1a was already configured by the BIOS, Linux does not reconfigure the bus settings of this bridge. It scans behind this bridge, find the xio2001 bridge but cannot scan behind this bridge because of the configuration setting of the upstream bridge.

It seems very clear now for me that the problem is somewhere in the xio2001, specially in the downstream PCI bus. It seems that every intent to scan behind the xio2001 (on the PCI bus side) yields to system hang-up.

What can be the cause of this ? I have tried to look at the [CBe0:CBE3], FRAME or IDSEL signals behind the xio2001 when I theoretically make a downstream configuration read-cycle with the xio2001 (reconfigure the upstream bridge and using io-port 0xfe8), but I cannot see any activity there as the system hangs up.

The PCIExpress side of the xio2001 works fine, as I can read/write the configuration registers without any problem. The system alway hangs when I make a configuration-read cycle downstrwam the xio2001.

Any idea of what can this be or how could I debug it (JTag of the xio2001) ?

best regards

Sven

Problem is solved by the moment.

The reason was the arbiter settings of the XIO2001. I had a pullup at the EXTARBEN pin but obviously did not have an external arbiter in the PCI side. Disabling the external arbiter and using the Xio2001 internal arbiter solved the problem.

Thanks for your support..

sven