TMS320C6678: problem enumerating pcie peripheral

Hello!
Would you mind to elaborate a little what is "can't enumerate"? Initial portion of configuration header should be accessed without troubles assuming link was up. There is minor issue, when LLD returns DevId/VenId swapped, but at least you should see them.

hello
thanks for reply. by "can't enumerate" i mean that output of "lspci -n" won't show our device and dsp stay idle for training process to end. also link-up flag in FPGA in not set.
here is what happens in detail:
1. Xilinx ZCU102 can't enumerate SAMSUNG SSD DISK in first time. we need to restart Xilinx board once for SAMSUNG SSD to get enumerated (view it using lspci -n)
2. PC can enumerate evmc6678 for first time, but after PC restart it won't get enumerate anymore.
3. Xilinx can't enumerate evmc6678 at all.

in this stage we reach to this conclusion:
Xilinx first stage bootloader finish it's enumeration process too fast so neither SAMSUNG SSD nor evmc6678 can't get enumerated. but SAMSUNG SSD has the ability to re-enumearte after Xilinx board reset while evmc6678 can't do that (we conclude this from the fact that PC can't enumerate evmc6678 after restart.)

in all of TI code for PCIE initialization, there was always this pattern (both in IBL code and example in sprabk8.pdf)

(a) lock pll
(b) disable training
(c) write some settings
(d) enable training and wait for training to end.

it seems that whole problem originate from stage (d). in other word, once DSP reach stage (d) if training process was not successful, it will get blocked in a while loop and host reset have no effect in breaking this loop.

now the question is, can't we change initialization process so that dsp remain active and responsible to training process of host?

Hello,
In my imagination, link training is quite low level procedure, ensuring data integrity. If we have no that, other steps are hardly relevant.
The only thing I could suggest is to look at debug registers and try to understand, what state does machinery stall at.