• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 99 subscribers
  • Views 910 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.

Original question:

AM6548: Routing of PCIe MSI-X interrupts

TDA4VM: Understanding MSI(-X) Interrupts on Register Level

felix_123
Expert 1251 points
Part Number: TDA4VM

Hi TI,

I am trying to undersatand how MSI(-X) Interrupts are working on Register Level in order to mimic this functionality in an RTOS application. As a starting point I am using this setup https://software-dl.ti.com/jacinto7/esd/processor-sdk-linux-jacinto7/07_03_00_05/exports/docs/linux/Foundational_Components/Kernel/Kernel_Drivers/PCIe/PCIe_End_Point.html with two J721E EVMs. I verified that this is working by using the pcitest utility.

My main questions refers to the following entry from the TRM: (Chapter 12.2.3.4.4.5.2)

The PCIe core decodes all MSI and MSI-X messages received from the link and forwards them on the lowpriority AXI master interface. These messages must then be routed to the system interrupt controller by the SoC interconnect (CBASS0).

Q1: Is it possible to route "these messages" via Sciclient_rmIrqSet to another interrupt controller than GIC? How to do this?

Q2: Which Register has to be written to trigger a MSI Interrupt? 

And one more detailed question:

When the pcie link is established using linux, the RC Register PCIE_CORE_ATU_WRAPPER_OB_i_DESC0 reads 0x0080000A. (Without a link it reads 0x00000000). What do these bits mean? The TRM only says "Lowest 32-bits of PCIe Descriptor Register for region N".

Thanks for your help.

Best regards,

Felix

  • 0
    Expert 1251 points

    Hi TI,

    I found out, that register PCIE_CORE_PFn_I_MSI_MSG_LOW_ADDR and PCIE_CORE_PFn_I_MSI_MSG_HI_ADDR (address 0x0D00 0094 and 0x0D00 0098 for PCIe module 0) contain the address, where the MSI Interrupt is expected to be routed to. For the linux case, the content of this register is 0x0100 0400, which corresponds to an GIC address (COMPUTE_CLUSTER0_GIC_TRANSLATER). Unfortunately, the ARM documentation about GIC registers only says, that this is a reserved area (https://developer.arm.com/documentation/ddi0516/e/programmers-model/its-translation-register-summary?lang=en). It would be also great if you could provide more detailed information about the GIC registers. (in specific the GITS_TRANSLATER register)

    The ATU Outbound address for the EP is also set to 0x0100 0400 and I could verify, that the address set in register PCIE_CORE_ATU_WRAPPER_OB_i_ADDR0 corresponds to the address in the RP, where the MSI data is routed to. Using PCIE_CORE_ATU_WRAPPER_OB_i_ADDR0 I can now route the data to any desired address.

    Referring to Question Q1, I want to route this interrupt not to GIC (A72), but to VIM (R5). But how to do that so that VIM knows that this is an interrupt? Or asked in a different way: What is the correct "step-in point" to the interrupt pipeline (Interrupt Aggregator -> Interrupt Router -> Interrupt Controller) so that the interrupt is recognized correctly? As far as I have understood,  the connection from Interrupt Router -> Interrupt Controller is hardwired, so my MSI Interrupt should have at this point already been converted to an electrical signal/pulse. So the logical step in point should be the Interrupt Aggregator I think. Is there any example in the PDK which shows how to use the Interrupt Aggregator in practice? And please correct me, if some of my assumptions are not correct.

    Thanks for your help and best regards,

    Felix