TE0803 PCIe reset

[simon.beaudoin]

HI !

We have a custom carrier board with a TE0803 fit on it. To program the SI5338 clock generator, we went the FSBL route to have it configured early in the boot sequence. The problem I have is that in the first boot, the SSD connected to the PCIe port doesn't get recognized. I have to issue a 'reboot' command, and then it gets recognized and mounted.

The PCI REF_CLK (the one that goes to the PCI connector) is a 100 MHz clock coming directly from a 'always on' oscillator on our carrier, whereas the 100 MHz clock that feeds the PCI MTG is a 100 MHz clock coming from the Si5338 clock generator.

I tried issuing a reset in the FSBL to pull low the PCI reset pin (we chose MIO13) right after the Si5338 gets initialized, but without success.

Having to soft reset the board is kind of annoying, so I'm reaching out for help in case someone has a similar setup.

** Could this problem be resolved by feeding the same Si5338 100MHz clock to both the PS_MGT and the PCI port?

Many thanks!

[simon.beaudoin]

I would like to add the following point :

When I power up the board, lspci command doesn't show the drive.
When I power up the board, issue a 'reboot' command in linux, then lspci shows the drive the next boot.
If I power up the board, interrupt u-boot sequence, issue a 'restart' command in u-boot, then lspci command still don't show anything.

I'm less inclined to think it's related to PCI reset / FSBL related now... Could it be strictly linux related? I don' have enough experience in that field for troubleshoot this

[JH]

Hi,
which carrier did you use?
In case of TEBF0808, can you please update CPLD Firmware and test with our 2018.3 reference design(prebuilt Boot.bin and image.ub included) (changed power sequencing and reset managment, see change history of the CPLD Firmware descirption).
18.3 design has new variant of the modified FSBL, which initialised SI5338 before FSBL initialise GTR. PCIe should work better.

Update instructions: https://wiki.trenz-electronic.de/display/PD/TEBF0808+CPLD+Firmware
Firmware: https://shop.trenz-electronic.de/en/Download/?path=Trenz_Electronic/Modules_and_Module_Carriers/5.2x7.6/5.2x7.6_Carriers/TEBF0808/REV04/Firmware
Description: https://wiki.trenz-electronic.de/display/PD/TEBF0808+CPLD#TEBF0808CPLD-RevisionChanges

Reference Design Description: https://wiki.trenz-electronic.de/display/PD/TE0803+StarterKit
Download: https://shop.trenz-electronic.de/en/Download/?path=Trenz_Electronic/Modules_and_Module_Carriers/5.2x7.6/TE0803/Reference_Design/2018.3/StarterKit

br
John

[simon.beaudoin]

Hi John, thank you for the reply!

We use our custom application carrier, so it doesn't have that CPLD you talked about. I was thinking it could be someting related to SI5338 initialisation order within the FSBL itself,you just confirmed my hypothesis.  I will did into it and give feedback. I really don't think it would make a difference, but right now the M.2 drive is a AHCI Sata controller SSD, not the newer NVMe drives.

Thank you John!

[JH]

Hi,
in this case check our FSBL --> source code is as template for SDK/HSI included into the reference design.
I've shift SI initialisation inside Xilinx PSU initialisation (after MIO and before Serdes). On this place I2C is ready to configured SI5338 and serdes will be initialised after SI CLKs are running. Also reset is done on this step
check "TE_XFsbl_TPSU_MODIFIED" from te_xfsbl_hooks_te0803.c, which will replace original PSU initialisation from Xilinx.

br
John

[simon.beaudoin]

On first glance, my understanding I that you dissected the psu_init into several functions so you that can insert the Si5338 init code within it. Am I right?

If changes to the Zynq IP within vivado block design are still expected, then psu_init.c will change and I will have to to the manipulation of dissecting that function again?

If my understanding is correct, then it is a very clever hack, but at the cost of breaking the automated stuff.

Thanks John

[simon.beaudoin]

*** Oops

Nevermind John, I found my answer.

I had never really dug up into the generated psu_init.c file that much, I thought it was only 20k lines of registers init back to back. I see that it's split into several parts :

Code Select Expand


int
psu_init(void)
{
int status = 1;

status &= psu_mio_init_data();
status &=  psu_peripherals_pre_init_data();
status &=   psu_pll_init_data();
status &=   psu_clock_init_data();
status &=  psu_ddr_init_data();
status &=  psu_ddr_phybringup_data();
status &=  psu_peripherals_init_data();
status &=  init_serdes();
init_peripheral();

status &=  psu_peripherals_powerdwn_data();
status &=    psu_afi_config();
psu_ddr_qos_init_data();

if (status == 0)
return 1;
return 0;
}


I now understand what you did in your  2018.3 FSBl.

I will give feedback of if this corrected our problem when I get it running.

[simon.beaudoin]

Well, turns out that it solved my problem! Our PCIe SSD now gets recognized and mounted on first boot.

Thank you very much for pointing me toward the right direction

Regards