Dear TI team,
one variant of our code that is supposed to run on the R5f core of an AM65x implements a PCIe endpoint.
In this variant we used to call Sciclient_rmIrqSet with a request setup like this, in order to route PCIe interrupts to the R5 core:
req.secondary_host = TISCI_MSG_VALUE_RM_UNUSED_SECONDARY_HOST;
req.src_id = TISCI_DEV_PCIE0; /* gets set to 120 */
req.src_index = irq->src_index; /* gets set to 5 */
/* Set the destination interrupt */
req.valid_params |= TISCI_MSG_VALUE_RM_DST_ID_VALID;
req.valid_params |= TISCI_MSG_VALUE_RM_DST_HOST_IRQ_VALID;
/* Set the destination based on the core */
req.dst_id = get_mcu_id(); /* gets set to 159 */
req.dst_host_irq = irq->host_irq; /* gets set to 194 */
ret = Sciclient_rmIrqSet(&req, &resp, SCICLIENT_SERVICE_WAIT_FOREVER);
This worked just fine with processor SDK 06.01, but fails with processor SDK 06.03. Inside Sciclient_rmIrqSet the return value from Sciclient_service is CSL_PASS, but the TISCI_MSG_FLAG_ACK flag isn't set in the response, causing Sciclient_rmIrqSet to return an error. Later in our code we're mapping UDMA events to the R5f using Sciclient_rmIrqSet, and that works fine, so the communication with the SYSFW appears to be ok. It looks like the SYSFW doesn't like something about this particular request.
I looked into the configuration of the MAIN2MCU_LVL_INTRTR0 at a point when the SBL is still running, and it looks like the PCIe interrupts are already routed to the R5:
0x00A10004 00000040 00000041 00000042 00000043 00000044 00000045 00000046 00000047 0x00A10024 00000048 00000049 0000004A 0000004B 0000004C 0000004D 0000004E 0000004F 0x00A10044 00000050 00000051 00000052 00000053 00000054 00000055 00000056 00000057 0x00A10064 00000058 00000059 0000005A 0000005B 0000005C 0000005D 0000005E 0000005F 0x00A10084 0000001C 0000001D 00000000 00000000 00000000 00000000 00000000 00000000 0x00A100A4 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0x00A100C4 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0x00A100E4 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Main2Mcu Level Inputs 64-95 (0x40-0x5f) correspond to the PCIe interrupts. Inputs 28 and 29 (0x1c-0x1d) correspond to the MMCSD0/1 interrupts.
With the SYSFW from processor SDK 06.01 the Sciclient_rmIrqSet call would succeed, and the MAIN2MCU_LVL_INTRTR0 configuration looked like this:
0x00A10004 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0x00A10024 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0x00A10044 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0x00A10064 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0x00A10084 0000001C 0000001D 00000044 00000000 00000000 00000000 00000000 00000000 0x00A100A4 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0x00A100C4 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0x00A100E4 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
With the SYSFW from processor SDK 06.03 the Sciclient_rmIrqSet fails and the MAIN2MCU_LVL_INTRTR0 configuration is not changed.
Where does the initial configuration of the MAIN2MCU_LVL_INTRTR0 come from? I was suspecting that this might be the result of Sciclient_boardCfgRm() with the board config compiled into the SBL, but it seems that this configuration is already set when the SBL enters its main, i.e. before the SYSFW is initialized.
Was there something changed in the SYSFW that could explain the different behaviour? For example was there a check added that prevents an already routed input to be assigned to another output? Was the previous behaviour of resetting (part) of the configuration intended or was that a bug?
Can I rely on the initial configuration, i.e. is it specified somewhere that the PCIe interrupts are routed via MAIN2MCU_RTR_LVL_MUX_INTR0-31? Can I query the existing configuration?
Regards,
Dominic
