• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 99 subscribers
  • Views 386 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

AM5706: PCie configuration after reset

Joseph Ott
Prodigy 110 points
Part Number: AM5706


We have a PCIe endpoint card based on the AM5706. Things are working fine except for a card reboot after a flash update.  In this case the host downloads new SW which is then written to flash.

So far all works except that after the SW has been written to flash the there is a processor cold reset to reboot the card and load the new SW.

The PCIe link is up but the configuration registers such as the BARs have been reset. The host can no longer see the local memory that was mapped to the PCIe bus.

Is there a method that can be run on the AM5706 that would result in the host reprogramming the configuration registers?

Joe 

  • 0
    TI__Guru 52873 points

    Hi Joe,

    I am not quite sure if I understand the situation and question well enough, so I would like to ask some clarification questions, and make some naive suggestions I can currently make.

    1. AM5706 is an EP connected with some sort of host RC like a PC. And for normal operations things are working fine, correct? And the issue happens when the firmware on the AM5706 is updated from RC-side and we do a full cold reset - let me know if that understanding is correct, and based on this understanding, I have a few questions:
      1. After the firmware update, if we do a full system reset (aka, we reset both RC and EP), then does everything start working fine?
      2. Without a firmware update, if we only just initiate the cold reset on the card with no new SW, then do we see the issue of the BAR registers being reset?
      3. Above two are mainly to narrow down whether the issue is with the firmware, or if the issue is for cold resetting just the EP while the RC is not reset
    2. Is the question for how AM5706 can notify RC to reprogram the configuration registers? If yes, we have an interrupt example in pci-epf-test demo here: https://software-dl.ti.com/processor-sdk-linux/esd/AM57X/08_02_01_00/exports/docs/linux/Foundational_Components/Kernel/Kernel_Drivers/PCIe/PCIe_End_Point.html. Assuming we just want to signal to RC to take action, I think raising an interrupt can work.

    Regards,

    Takuma

  • 0 in reply to Takuma Fujiwara
    Prodigy 110 points

    Takuma,

    Thanks for your response, here are my answers

    1a - Yes. If a full system reset is done after a firmware update then things work as expected.

    1b - yes. If the card does a cold reset then the same thing happens with the BAR registers

    1c The issue is with a cold reset of the EP while the RC is not reset.

    This issue arose since the desire is not to reset the system after a firmware update. 

    We can try a MSI after reboot, but I am not sure that would resolve the issue. During the firmware update the host is querying local memory on the EP looking for certain values to indicate a restart. After the reset the host is just reading 0xFFFF due to the BAR registers being reset. Will an MSI work if the configuration registers have been reset.  Will this MSI cause the RC to re-write the configuration registers?  

  • 0 in reply to Joseph Ott
    TI__Guru 52873 points

    Hi Joe,

    Thanks for the clarification, and understood that the issue is when doing a cold reset, BAR registers are cleared on EP-side. MSI might not work in this case, because looking through the code it looks like BAR is expected to be set up already before an interrupt is raised, so I think we can scratch that idea out for now.

    I think in general, the RC should be configuring the BAR registers during enumeration of the EP device. If the link is coming up, meaning negotiation for PCIe generation speed and writing to capability registers is happening, it sounds peculiar that BAR registers are not being reinitialized in the process as well.

    Could you check on the RC-side what the difference is between a full system reset vs just the EP being reset? My suspicion is that there is some piece of code that runs only once for probing the PCIe bus during boot on the RC-side that does not get ran the second time doing the BAR initialization.

    If there are boot logs where everything is functional, as well as logs from when issuing the cold reset to EP, my suggestions would be to find the difference between the two to see if there are some missing logs. Then, identify the block of code that is not running, and force the RC to run the code during enumeration or the PCIe device, or when attempting to query local memory on the EP.

    Regards,

    Takuma

  • 0 in reply to Takuma Fujiwara
    Prodigy 110 points

    Takuma

    Thanks for you response.

    We are looking at the Host side to see what enumeration process is and if it can be triggered again once the EP has gone through a cold reset.  My hope with this post was to see if there was anything the EP could do to cause the RC to reprogram the configuration registers.

    Joe

  • 0 in reply to Joseph Ott
    TI__Guru 52873 points

    Hi Joe,

    Understood. I do not think there is a good way for EP to initiate a BAR reset on the RC-side before BAR is set up. Since host RC does most of the configuration and keeps track of BARs, I think it makes sense to check there first.

    However, please keep us posted on whether you are able to root cause what the issue could be.

    Regards,

    Takuma

  • 0 in reply to Takuma Fujiwara
    Prodigy 110 points

    Takuma

    Thanks for help, much appreciated.

    We will continue our investigation on the host side and let you know.

    Joe