No response when reading Status and Command Register in PCIE of i.MX7D

[tamotsu]

Hi.

There is no response when reading the Status and Command Register in the PCIE of i.MX7D.

I have the following settings:

RDC_MRCn : (RDC_PDAO45) 0x000000FF

PMU_REG_1P0Dn : 0x00021073

CCM_TARGET_ROOTn : PCIE_CTRL_CLK_ROOT : 0x12000000

                                          PCIEPHY_CLK_ROOT : 0x11000000

CCM_CCGR96 : pcie : 0x00000003

SRC_PCIEPHY_RCR : 0x00000000

Are there any other settings I need to make?

Best regards.

[Zhiming_Liu]

Hi,

Please ensure the clock is not gated and has been generated. If the clock is confirmed to be correct, then check the permission settings in RDC.

Best Regards,
Zhiming

[tamotsu]

Hello Zhiming.

I tried changing the CCM and RCD settings but nothing changed.

So I checked the voltage with an oscilloscope.

The FUSE_FSOURCE voltage is 1.8v.

I set PMU_REG_1P0D to 0x210F3, but the PCIE_VPH terminal and others remained at 0V.

What could be the cause?

Best regards.

[tamotsu]

Hello Zhiming.

There was a mistake in what I wrote yesterday.

When 0x00031077 was written to "PMU_REG_1P0Dn", the "VDD_1P0_CAP" pin output 1.0V.

I cannot find any instructions on how to set the "VDDA_PHY_1P8" switch in Figure 5-23 of the reference manual and on Sheet 5 of the SABRE board schematic. Therefore, "VDDA_PHY_1P8" remains at 0V.

Please give me some advice.

Regarding your advice, "the clock is not gated and has been generated," I have no way to confirm this with an oscilloscope.

Please give me some advice.

Best regards.

[Zhiming_Liu]

Hi @tamotsu 

I know you might be bringing up a baremetal system, but I'd like to discuss what PCIe requires from Linux.

For PCIe itself, needs correct three key resources: clock, power, reset timing.

1.  You need to make sure that these three clocks are generated and ungate.

2. Make sure pcie power domain is opened in GPC.

After doing these two steps, at least the register can be read.

3. Perfom correct reset timing referring the pcie driver: drivers/pci/controller/dwc/pci-imx6.c.

			clocks = <&clks IMX7D_PCIE_CTRL_ROOT_CLK>,
				 <&clks IMX7D_PLL_ENET_MAIN_100M_CLK>,
				 <&clks IMX7D_PCIE_PHY_ROOT_CLK>;
			clock-names = "pcie", "pcie_bus", "pcie_phy";
			assigned-clocks = <&clks IMX7D_PCIE_CTRL_ROOT_SRC>,
					  <&clks IMX7D_PCIE_PHY_ROOT_SRC>;
			assigned-clock-parents = <&clks IMX7D_PLL_ENET_MAIN_250M_CLK>,
						 <&clks IMX7D_PLL_ENET_MAIN_100M_CLK>;

			fsl,max-link-speed = <2>;
			power-domains = <&pgc_pcie_phy>;
			resets = <&src IMX7_RESET_PCIEPHY>,
				 <&src IMX7_RESET_PCIE_CTRL_APPS_EN>,
				 <&src IMX7_RESET_PCIE_CTRL_APPS_TURNOFF>;
			reset-names = "pciephy", "apps", "turnoff";









gpc: gpc@303a0000 {
				compatible = "fsl,imx7d-gpc";
				reg = <0x303a0000 0x10000>;
				interrupt-controller;
				interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
				#interrupt-cells = <3>;
				interrupt-parent = <&intc>;
				fsl,mf-mix-wakeup-irq = <0x54410000 0xc00 0x0 0x1040640>;

				pgc {
					#address-cells = <1>;
					#size-cells = <0>;

					pgc_mipi_phy: power-domain@0 {
						#power-domain-cells = <0>;
						reg = <0>;
						power-supply = <&reg_1p0d>;
					};

					pgc_pcie_phy: power-domain@1 {
						#power-domain-cells = <0>;
						reg = <1>;
						power-supply = <&reg_1p0d>;
					};

					pgc_hsic_phy: power-domain@2 {
						#power-domain-cells = <0>;
						reg = <2>;
						power-supply = <&reg_1p2>;
					};
				};
			};

Best Regards,
Zhiming

[tamotsu]

Hello Zhiming_Liu.

I'm debugging PCIE in u-boot.
u-boot reads the contents of the device tree (fsl, imx6q-pcie) and executes imx_pciw_dm_probe().
The function imx_pciw_dm_probe() jumps to the function imx_pcie_link_up().
At the beginning of this function, there is a process to read the PCIE "Status and Command Register (0x33800004)".
This process results in no response.
The result was the same even with the Device tree information you provided.
The registers did not reflect the contents of the Device tree.

So I set the following registers:
　　PMU_REG_1P0D 0x00021079
　　SRC_PCIEPHY_RCR 0x00000000
　　CCM_TARGET_ROOT PCIE 0x12000000
　　CCM_TARGET_ROOT PHY 0x11000000
　　CCM_CCGR96 0x00000003

I did not change the following registers.
PDC_PDAP45 0x000000FF
PDC_MDA2 0x00000000

Even with this setting, when I load 0x33800000 in the debugger, there is no response.

Next I thought that the reason why "VDDA_PHY_1P8" remained at 0V was related to the GPC.
I set "PGA CPU mapping(0x303a00ec) to 0x09.
I wrote 0x01 to "CPU GPC software power up trigger (0x303a00f0)" but it remained 0x00.
Also, when I wrote 0x02 to "PU GPC software power up trigger (0x303a00f8)", the contents of DRAM changed.

What other registers should I set?

Best regards.

[Zhiming_Liu]

Hi @tamotsu 

You might want to take a look at the patch below for some additional ideas. The overall porting should be based on the software framework rather than directly modifying registers.  It looks like uboot has i.MX7D SRC driver.

https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/Add-i-MX8MPlus-pci-driver-in-uboot/ta-p/...

Best Regards,
Zhiming

[tamotsu]

Hello Zhiming_Liu.
Regarding the support I received from you, I am having trouble with the i.MX8 processing, which is a preliminary step.
I referred to "5.5.9.5 Example Code 4" in the Reference Manual.
reg32_write (GPC_IPS_BASE_ADDR + 0xF8 , *** | 0x2 );
After running this code, the MPU becomes unresponsive.
However, there is no problem with values ​​other than PCIE_PHY.

Could you please tell me what to set and how to set it before running u-boot/drivers/pci/pcie_imx.c@probe(struct udevice *dev)?

Best Regards.

[tamotsu]

Hello Zhiming_Liu.

The IMX7DSABRE has a Mini PCIE port.
I am wondering why u-boot does not have the source code to set the PCIE clock, power, etc. of the IMX7DSABRE.

Best Regards.

[Zhiming_Liu · Accepted solution]

Hi @tamotsu 

The PCIe driver is maintained by mainline, not NXP, so missing some code is normal. You can refer the i.MX7D Linux PCIe driver to port it in uboot. The pci_imx.c also refers the Linux kernel driver.

Best Regards,
Zhiming

[tamotsu]

Hello Zhiming_Liu.

I finally found out why it wasn't responding.
I made the SABRE circuit's "SW2_1V8" to "VDDA_1P8_01(pin-V6)" the same, but I found that the inductance resistance value was too large.
The moment I set GPC_PU_PGC_SW_PUP_REG, the voltage of "VDDA_1P8_01(V6)" dropped by 0.2V in 2uSec.
As a result, VDDA_PHY_1P8 only rose to 0.35V.
When I shorted this inductance, VDDA_PHY_1P8 became 1.8V.

I thought that VDDA_PHY_1P8 would be fine even if the input voltage dropped a little, but I found that this was not the case.

Thank you very much for all your advice.

Best Regards.

[tamotsu]

Hello Zhiming_Liu.

I understand the advice.
I will read the reference manual again and try again.

BEst Regards.

[tamotsu]

Hello Zhiming_Liu.

I finally found out why it wasn't responding.

I made the SABRE circuit's "SW2_1V8" to "VDDA_1P8_01(pin-V6)" the same.

But I found that the inductance resistance value was too large.

The moment I set GPC_PU_PGC_SW_PUP_REG, the voltage of "VDDA_1P8_01(V6)" dropped by 0.2V in 2uSec.

As a result, VDDA_PHY_1P8 only rose to 0.35V.

When I shorted this inductance, VDDA_PHY_1P8 became 1.8V.

I thought that VDDA_PHY_1P8 would be fine even if the input voltage dropped a little, but I found that this was not the case.

Thank you very much for all your advice.

Best Regards.