TDA4VM: PCIE RC BusError on HS

Hi Suman,

The issue was the PCIe driver run normally on SPL boot mode but failed on SBL boot mode. As far as I know, the SBL boot mode already enable the secure boot function.

According to the test result, the issue occur because of the register can't be write. The releated register please refer to above.

TI is an expert in both boot modes, could you help to provide the different between the two boot mode and could you please help to provide some suggestions for debug ? Is there access control for registers in secure boot mode?

When running the SBL boot, have you checked to see that the PCIe module under test  is clocked and enabled?   It could be that the SPL under test was enabling / clocking differently than the SBL under test was.   

The k3conf tool can be used for this purpose:

k3conf dump devices

k3conf dump clocks

Has SBL boot flow been tried on a GP part?

Regards,

kb

Hi KB,

I have dump the GP spl mode and HS sbl mode as following, the GP spl work and HS sbl doesn't work.

gp_dump_devices_clocks.txt

hs_ospi_dump_devices_clocks.txt

It have many different, please help to check.

And then  I also dump the HS sbl mode and the HS spl mode, the HS sbl work and the HS spl doesn't work, as following:

hs_ospi_rc_dump_device_clocks.txt

hs_sd_rc_dump_device_clocks.txt

These two dump logs show that they doesn't have different register of pcie related CLK or DEVICE, please help to double check.

Thanks.

Best Regard,

Ruifeng 

Hi Ruifeng,

Is there a typo in your results above? 

 "I also dump the HS sbl mode and the HS spl mode, the HS sbl work and the HS spl doesn't work". 

Will work under the assumption that PCIe for the HS SBL is not working in both cases above as below table, which means the issue appears to be un-related to HS, and is a delta between SPL  boot flow and SBL boot flow.

-- 1 ---

In looking at the logs for the HS SPL vs SBL, the system firmware (SYSFW / TISCI) being used are different versions.  This is unexpected and must be understood before moving forward.

• SPL:  21.1.1--v2021.01A
• SBL:  21.5.0--v2021.05

-- 2 --

The PCIe modules makes use of the Serdes.  Please look at which Serdes is being used in your setup.  The Serdes configuration differs between SPL / SBL and may need to be adjusted, the QNX BSP should be taking care of this (src/hardware/startup/boards/j721e/evm/hw_init.c).

For the TI SDKs default serdes settings for SDK 8.0 are below:

SPL+Uboot

• SERDES 0/1 used for PCIE

SBL

• SERDES 0/1 shared between PCIEand SGMII (Ethfw on R5)

Regards,

kb

Hi KB,

Sorry for that, it should be the "I also dump the HS sbl mode and the HS spl mode, the HS sbl doesn't work and the HS spl work". 

--- 1 ---

Because the GP used SDK8.2 but HS used SDK8.0 when dump the devices and clocks, so they were different.

And I re-dump the devices and clocks between GP and HS on SBL boot mode, the result shows that all the devices and clocks are the same.

hs_ospi_ep_dump_device_clocks.txt

gp_ospi_ep_dump_device_clocks.txt

--- 2 ---

Tests show that PCIe does not work in HS sbl ospi boot mode, but works fine in GP sbl ospi boot mode. Because of the ifs_qnx.appimage binary and the lateapp1 / lateapp2 are same on this test, so in my understanding, the issue doesn't releated to the SERDES and PLL configuration.

The different binarys between them are the following three secure boot related.

├── can_boot_app_mcu_rtos_mcu1_0_release.appimage

├── sbl_cust_img_mcu1_0_release.tiimage

└── tifs.bin

Another question:

We found the following source code in SPL secure boot mode, the path is "PSDKLA/board-support/u-boot-2021.01+gitAUTOINC+44a87e3ab8-g44a87e3ab8/arch/arm/mach-k3/j721e_init.c ". But doesn't found releated code in the SBL, does it matter to this issue?

Please help to parse this issue continue and supply some suggestions, thanks.

Hi Ruifeng,

Checking with TI team on this topic.

Regards,

kb

Hi Ruifeng,

Recommendation is to add similar code which is being done in the SPL to the SBL bootflow.  

In regards to PCIe specifically, on HS boot firewalls 2560/2561 will be closed by default, which is likely causing the issue being seen.

Regards,

kb