This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

PROCESSOR-SDK-AM65X: PCIe, USB, SerDes configuration requires half Sciclient/SYSFW and half direct register writes

Part Number: PROCESSOR-SDK-AM65X
Other Parts Discussed in Thread: AM6548

Dear TI team,

we're using one of the AM6548 PCIe ports as an endpoint and one of the USB controllers in USB2.0 only mode (i.e no SerDes) in an application running TI-RTOS with processor SDK 07.01. Our application tries to configure most things via Sciclient/SYSFW, but some settings can't be performed via the Sciclient, or at least we couldn't figure out how. Manually programming works (for now), but we've seen other cases where direct register access was disabled via firewalls eventually (MAIN2MCU interrupt router).

The device type in CTRLMMR_PCIE0_CTRL (RC/EP) can't be configured via Sciclient.

For the SerDes configuration we use Sciclient/SYSFW to configure the reference clock (CTRLMMR_SERDES0_REFCLK_SEL) but we couldn't find a way to configure the lane usage (PCIe/USB/SGMII) and the clock chaining in CTRLMMR_SERDES0_CTRL using Sciclient.

For now we're able to work around these issues, but since there's no description of changes with each PDK version we're spending quite a lot of time trying to figure out why part of our code suddenly fails when a new version is released. This includes issues with SBL or maybe SYSFW having enabled wites via KICK/LOCK registers in previous versions, and the same registers suddenly ignoring writes when a new version disables writes (as it should, of course). Ideally I think all this device wide configuration should be performed via Sciclient.

  • Did we miss some Sciclient calls that allow us to configure the required functionality?
  • Are there plans to add these functions to Sciclient, and if yes, when can we expect these functions?

Regards,

Dominic

  • Dominic, 

    The way you configured PCIe and SERDES matches to our sample code:

         pdk_am65xx_07_01_00_55\packages\ti\drv\pcie\example\sample\am65xx\src\pcie_sample_board.c

    if you look at the code under am65xx_idk macro, which matches to your use case, you can see that:

    • SERDES clock chaining is done by direct register programming.
    • SERDES mux is done by direct register programming
    • sciclient calls are made to configure REFCLK_SEL

    Also the PCIE role setting is done via directly register programming. So you may need to add KICK code in your program to be sure the CTLMMR block you touch is kick unlocked before writing to solve the issue for future releases. 

    I am not aware of any plans to add these to sysfw, as they are specific to the PCIE resource though we may argue SERDES mux is questionable. 

    Also note that the controller shall be set to EP before the controller is brought out of reset. I assume you are already doing so. 

    regards

    jian