PROCESSOR-SDK-AM57X: PCIe Link Training stuck in DETECT_ACT state

Hi Jack,

If the PCIe driver is working fine during SBL, but in user application the same code is not working, my first suspicion is that some registers are unlocked by default during boot, but locked after the boot sequence is finished to write protect them from user applications.

I see in <AM57 RTOS SDK>/pdk*/packages/ti/board/diag/pcie/src/pcie_test.c's BoardDiag_pcieTest(void) function that there is a CSL_BootCfgUnlockKicker() being called. The content is:

Similarly, could you try unlocking the kicker registers during initialization of PCIe, since I do not see this in the shared code?

Regards,

Takuma

Hi Takuma

Thanks for your kind answer.

They're still unable to figure out the appropriate kick registers. Could you please specify the relevant kick registers to unlock during PICe initialization?

They could find the the RTC Kick Regs only as below.

Thanks.

Regards, 

Jack

The cpu used is AM5728.
CSL_BootCfgUnlockKicker is not AM572x target code.

Hi Seounguk and Jack,

That is a good catch. You are right, this is not getting called for AM572x. However, I am still thinking that this could be related to registers being write protected due to some sort of locking mechanism, whether it is some clock registers or some registers controlling the mode at which the PCIe slots should operate. There are some MMR lock registers like below in the technical reference manual for AM572x.

There is also a function in <AM57 RTOS SDK>/pdk*/packages/ti/board/src/evmAM572x/evmAM572x.c Board_unlockMMR(void) that unlocks all the MMR registers.

Could you try unlocking these registers for driver initialization and relocking them afterwards? I assume that there is some control MMR registers that are being changed in the driver, and since these are unlocked during board initialization the driver can correctly operate. And in user application area, these registers are locked, so if the driver is trying to change some of these registers, it will fail.

Regards,

Takuma

Hi Takuma

Thanks for your kind answer.

MMR unlock is already applied.

Since BOARD_INIT_UNLOCK_MMR is set in Board_init(boardCfg), MMR Unlock is already applied.

//---------------------------------------------------------------------------------------------------------------------------------

[Another question]

After pcie() is called in SBL, the following code is executed.

boardCfg |= BOARD_INIT_PINMUX_CONFIG |
BOARD_INIT_DDR |
BOARD_INIT_DDR_ECC |
BOARD_INIT_UART_STDIO;

Board_init(boardCfg);

/* enable clocks for slave core modules. */
SBL_SlaveCorePrcmEnable();

CSL_a15WbAllDataCache();

if (idkAM572xEntry.entryPoint_MPU_CPU1 != 0)
{
/* Bring the A15 CPU1 core out of reset. */
SBL_MPU_CPU1_BringUp(idkAM572xEntry.entryPoint_MPU_CPU1);
}

if (idkAM572xEntry.entryPoint_DSP1 != 0)
{
/* Release the DSP1 core out of reset */
SBL_DSP1_BringUp(idkAM572xEntry.entryPoint_DSP1);
}

if (idkAM572xEntry.entryPoint_DSP2 != 0)
{
/* Release the DSP2 core out of reset */
SBL_DSP2_BringUp(idkAM572xEntry.entryPoint_DSP2);
}

if (idkAM572xEntry.entryPoint_IPU1_CPU0 != 0)
{
/* Release the IPU1 core out of reset and set the Entry point */
SBL_IPU1_CPU0_BringUp(idkAM572xEntry.entryPoint_IPU1_CPU0);
}

if (idkAM572xEntry.entryPoint_IPU1_CPU1 != 0)
{
SBL_IPU1_CPU1_BringUp(idkAM572xEntry.entryPoint_IPU1_CPU1);
}

if (idkAM572xEntry.entryPoint_IPU2_CPU0 != 0)
{
/* Release the IPU2 core out of reset and set the Entry point */
SBL_IPU2_CPU0_BringUp(idkAM572xEntry.entryPoint_IPU2_CPU0);
}

if (idkAM572xEntry.entryPoint_IPU2_CPU1 != 0)
{
/* Release the IPU2 CPU1 core out of reset and set the Entry point */
SBL_IPU2_CPU1_BringUp(idkAM572xEntry.entryPoint_IPU2_CPU1);
}

After executing this code, I move on to the application. Was there any factor that could affect this code?

Hi Seounguk,

I appreciate the patience from you regarding this issue.

I am thinking that the code in the screenshot is from SBL. And based on the following described behavior:

Jack said:

If the initialization code of the same sequence is executed in the SBL, it works well

and

Jack said:

if you move to the App area, the initialization is not completed.

Along with the fact that these CTRL MMR registers should become locked after SBL completed, my suspicion is that when trying to initialize in the app area, the PCIe driver is trying to change some of these CTRL MMR registers and failing because by the time we get to user application the registers are locked.

My suggestion is before getting into the PCIe driver, have the application unlock these CTRL MMR registers again, and relock them after PCIe initialization is done. Because if my suspicion is correct, unlocking these registers should make the PCIe driver work.

Regards,

Takuma

The register value was checked at the time of APP startup.

Verified that all MMR registers are in unlock state.
In the current implementation code, the MMR register was implemented in a unlock state.

Hi Seounguk,

To close my suspicions on these CTRL MMR registers, could you dump the following registers for the working version where PCIe is set up in SBL and compare with the non-working version where the application is doing initialization?

And as a final experiment, could you explicitly unlock the MMR registers in the application and do the PCIe initialization, in case these lock registers are configured to read back the same value regardless of whether they are locked or unlocked?

Regards,

Takuma

Hi Seounguk,

To give more context to my previous post, these registers should be the ones that are locked/unlocked by CTRL_MODULE_CORE_CTRL_CORE_MMR_LOCK_5, so they should have the same register settings as in the working version of the driver.

And usually there is a need to explicitly unlock these MMR lock registers when trying to make changes to MMR registers from user space, so I think the experiment would be worthwhile.

Regards,

Takuma

Hi Seounguk,

Let me know how the experiment went and whether the issue is still open.

Regards,

Takuma