AM62A3: Interrup GPIO configuration for GPIO_37/R18

Hi 

Thanks for your query.

I have taken your inputs and working on it. Please allow some time to revert back.

Regards,

Tushar

Looking at this a bit more, as I am on the DM core, which is running Sciserver, I don't think the DM core should be calling Sciclient APIs - these I think are meant for the non-dm cores to talk to the DM core to ask for a remap.

Do you know the APIs the DM core should be using to remap interrupts? 

Hi TI team,

can you provide an update on the specific question of the DM core running the required version of the Sciclient API to map the GPIO pin to the DM core interrupt?

This is an urgent issue and is blocking the customer.

Regards,

--Gunter

Hello Gunter,

Thanks for your patience.

Can you please check that the TISCI_DEV_MAIN_GPIOMUX_INTROUTER0 resource is allocated to the WKUP_R5F core in the sciclient_defaultBoardcfg_rm.c file?

I have checked that the file does not have the TISCI_DEV_MAIN_GPIOMUX_INTROUTER0 resource allocated to the WKUP_R5F core by default.

Please refer below screenshot.

Please add the below lines in your sciclient_defaultBoardcfg_rm.c file if not already added.

{
    .num_resource = 16,
    .type = TISCI_RESASG_UTYPE (TISCI_DEV_MAIN_GPIOMUX_INTROUTER0, TISCI_RESASG_SUBTYPE_IR_OUTPUT),
    .start_resource = 0,
    .host_id = TISCI_HOST_ID_MAIN_0_R5_1,
},

After adding the above changes you will need to rebuild the board config. Please run below command from the root directory of SDK.

gmake -s -C tools/sysfw/boardcfg/ SOC=am62ax

After building the board config, rebuild the SBL and the example project.

Once the above steps are finished successfully, flash the EVM again with the updated images. The example should now work as expected.

Regards,

Tushar

Hi,

I tried your above, but the results are the same as before. Here is my steps:

1. I added above line to my sciclient_defaultbaordcfg_rm.c:

Note - is this a typo? is .host_id supposed to be TISCI_HOST_ID_MAIN_0_R5_0 or TISCI_HOST_ID_MAIN_0_R5_1?

2. I rebuilt the board config and this ran successfully - make -s -C tools/sysfw/boardcfg/ SOC=am62ax

3. I rebuilt the mcu sdk

4. I have my code like this (see below "code" section)

5. I rebuilt my DM core image (make vision_apps)

6. I took the output image of step 4, and generated a new tispl.bin

7. I flashed the new tispl.bin onto the SoC

The results are the same - running following API still results in failure - Sciclient_rmIrqSet(&sci_irq_req, &sci_irq_res, SystemP_WAIT_FOREVER); and my IRQ callback is not being called

Futhermore, is Sciclient_rmIrqSet the right API to be using? Or should i be using something else (i.e Sciclient_ProcessRmMessage())?

Code:

struct tisci_msg_rm_irq_set_req sci_irq_req;
struct tisci_msg_rm_irq_set_resp sci_irq_res;

sci_irq_req.valid_params = 0U;
sci_irq_req.valid_params |= TISCI_MSG_VALUE_RM_DST_ID_VALID;
sci_irq_req.valid_params |= TISCI_MSG_VALUE_RM_DST_HOST_IRQ_VALID;
sci_irq_req.global_event = 0U;
sci_irq_req.src_id = TISCI_DEV_MAIN_GPIOMUX_INTROUTER0;
sci_irq_req.src_index = CSLR_MAIN_GPIOMUX_INTROUTER0_IN_GPIO0_GPIO_37;
sci_irq_req.dst_id = TISCI_DEV_MAIN_GPIOMUX_INTROUTER0;
sci_irq_req.dst_host_irq = 12;                                                                //Use 12, which maps to interrupt 44
sci_irq_req.ia_id = 0U;
sci_irq_req.vint = 0U;
sci_irq_req.vint_status_bit_index = 0U;
sci_irq_req.secondary_host = TISCI_MSG_VALUE_RM_UNUSED_SECONDARY_HOST;

retVal = Sciclient_rmIrqSet(&sci_irq_req, &sci_irq_res, SystemP_WAIT_FOREVER);
if(0 != retVal)
{
    DebugP_log("Error: Sciclient event config failed!\r\n");                      <----- This log is still printed, indicating sciclient failure
}

//Setup GPIO

bank_num = GPIO_GET_BANK_INDEX(37);

GPIO_setDirMode(CSL_GPIO0_BASE, 37, GPIO_DIRECTION_INPUT);
GPIO_setTrigType(CSL_GPIO0_BASE, 37, GPIO_TRIG_TYPE_RISE_EDGE);
GPIO_bankIntrEnable(CSL_GPIO0_BASE, 37);

//Setup HWiP

HwiP_Params_init(&hwi_params);
hwi_params.intNum = CSLR_WKUP_R5FSS0_CORE0_INTR_MAIN_GPIOMUX_INTROUTER0_OUTP_12;   ///This is chosen due to above interrupt mapping
hwi_params.eventId = HWIP_INVALID_EVENT_ID; //Not used for AM62A
hwi_params.priority = 3;
hwi_params.isFIQ = 0; //interrupt is ISR
hwi_params.isPulse = 1; //pulse interrupt
hwi_params.callback = &irq_callback;
hwi_params.args = NULL;

HwiP_construct(hwi_object, &hwi_params);

Hi,

Yue Hu said:

Note - is this a typo? is .host_id supposed to be TISCI_HOST_ID_MAIN_0_R5_0 or TISCI_HOST_ID_MAIN_0_R5_1?

The host id for WKUP_R5F is TISCI_HOST_ID_MAIN_0_R5_1. Please refer https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/am62ax/hosts.html for more info.

Yue Hu said:

Futhermore, is Sciclient_rmIrqSet the right API to be using?

Can you please try above steps with Sciclient_rmIrqSetRaw() API instead of Sciclient_rmIrqSet() API and update the result?

Please ensure that all the files are rebuilded correctly.

Regards,

Tushar

Thanks, with these updates, however, I am still getting Sciclient_rmIrqSetRaw() returning a non-zero error code

Steps:

1. Update sciclient_defaultBoardCfg_rm.c - added line 141-145

2. Ran make -s -C tools/sysfw/boardcfg/ SOC=am62ax in root of MCU SDK (runs fine)

3. in sdk_builder, ran following to rebuild SDK

make mcu_plus_sdk_clean

make mcu_plus_sdk

4. updated code to as follows:

sci_irq_req.valid_params = 0U;
sci_irq_req.valid_params |= TISCI_MSG_VALUE_RM_DST_ID_VALID;
sci_irq_req.valid_params |= TISCI_MSG_VALUE_RM_DST_HOST_IRQ_VALID;
sci_irq_req.global_event = 0U;
sci_irq_req.src_id = TISCI_DEV_MAIN_GPIOMUX_INTROUTER0;
sci_irq_req.src_index = CSLR_MAIN_GPIOMUX_INTROUTER0_IN_GPIO0_GPIO_37;
sci_irq_req.dst_id = TISCI_DEV_MAIN_GPIOMUX_INTROUTER0;
sci_irq_req.dst_host_irq = 12;
sci_irq_req.ia_id = 0U;
sci_irq_req.vint = 0U;
sci_irq_req.vint_status_bit_index = 0U;
sci_irq_req.secondary_host = TISCI_MSG_VALUE_RM_UNUSED_SECONDARY_HOST;
ret_val = Sciclient_rmIrqSetRaw(&sci_irq_req, &sci_irq_res, SystemP_WAIT_FOREVER);

5. Build the DM firmware image via:

make vision_apps_clean

make vision_apps

6. Load in the new DM firmware output into the prebuilds folder

7. Rebuild tispl.bin (no changes except the DM core firmware image is updated

8. Flash tispl.bin onto board and reboot.

When I do this, rmIrqSetRaw still returns a non-zero error, and I do not see my IRQ callback being hit

Hi,

I can see you are rebuilding the tispl.bin binary. Are you not using SBL boot flow? (i.e SBL NULL binary or other SBL binary)

Are you using SPL flow to boot the EVM? (i.e. Linux to initialize the EVM)

Regards,

Tushar

Hi, we are not using the EVM here, we are on our own custom hardware. 

I have already flashed the tiboot3.bin.raw and u-boot.img.raw

To update the DM core, I am simply building the DM core image, then rebuildling the tispl.bin to update to the new "prebuilt" dm image, then loading the tispl.bin only

One more question on the sciclient() APIs.

This code is running on the DM core itself. I don't see Sciclient_init() ever called. Do i need to call this? Are the init() or other APIs i should call prior to using Sciclient_rmIrqSetRaw()?

Does sciclient() APIs work on the DM core? As the DM core runs sciserver, and handles other cores sciclient calls? The examples are for the main A5 core, the C7 DSP, and the MCU R5, but not for the DM core.

Hello Yue Hu,

Just to double-check: are you booting with the SPL boot flow, or the SBL boot flow?
Refer to https://dev.ti.com/tirex/explore/node?node=A__AZnGm6MPlXHB0zpbZBivKw__AM62A-ACADEMY__WeZ9SsL__LATEST

To clarify Tushar's remark above, you can boot Linux on the A53s with either the SBL or the SPL boot flow, but the SPL boot flow is the default setting for our out-of-the-box Linux SDK.

The reason we are asking is that the resource partitioning is configured in different files if you are using SPL boot flow than if you are using SBL boot flow. Tushar was discussing the files for resource partitioning with SBL boot flow above. 

Information on modifying resource allocation for SPL boot flow

I'll attach information here in case you are using SPL boot. Feel free to ignore otherwise.

You'll want to use the K3 Resource Partition tool to modify the default resource allocations in the Linux SDK (I assume you are using SDK 9.2?). Information on using K3 Resource Partition tool is here: 

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1308689/faq-how-to-use-k3-resource-partitioning-tool-with-processor-sdk-v9-0-or-v9-1

Note that if you are using SDK 9.0 & 9.1, you CANNOT use the version of the K3 Resource Partition tool that is packaged in the Linux SDK. You HAVE to use the version I packaged in the FAQ.

It looks like I haven't written steps to build the resource partitioning into the SPL boot files for SDK 9.x - let us know if that is needed. In the meantime, this in-progress FAQ has information on how I've updated the binman file to build updated DM firmware into the SPL in the past. I'm not sure how it interacts with AM62Ax firmware builder, but perhaps it will be helpful for you: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1317407/faq-am625-how-do-i-modify-the-ddr-memory-footprint-of-the-dm-r5f/5008067#5008067

Regards,

Nick

Hi Nick, Tushar

Let me double check on this and get back to you with a team member, but I believe we are using SBL boot flow.

In the meantime, if I we're to assume resource allocation was done properly, is the code (calling Sciclient_rmIrqSetRaw()) the right thing to do? Do i need to call any additional APIs (like sciclient_init())?

Does it make sense to be calling sciclient APIs on the DM core, which is running sciserver? Or should we call something direct as we are already on the DM core and don't need to IPC to the DM core in the first place?

Looking around a bit more, i tried running a simple test just to see if sciclient would work and I used and ran this piece of code:

This code also fails in the sciclient_service() function call. So it seems like sciclient() itself is not working?

What I also tried to trace the sciclient/sciserver code itself, and noticed that its writing to the rm driver via this function: Sciclient_ProcessRmMessage

So I also tried replacing the Sciclient_rmIrqSetRaw() with Sciclient_ProcessRmMessage():

struct tisci_msg_rm_irq_set_req sci_irq_req = {0};

sci_irq_req.hdr.type = TISCI_MSG_RM_IRQ_SET;
sci_irq_req.hdr.flags = TISCI_MSG_FLAG_AOP;

//Map Interrupt
sci_irq_req.valid_params = 0U;
sci_irq_req.valid_params |= TISCI_MSG_VALUE_RM_DST_ID_VALID;
sci_irq_req.valid_params |= TISCI_MSG_VALUE_RM_DST_HOST_IRQ_VALID;
sci_irq_req.global_event = 0U;
sci_irq_req.src_id = TISCI_DEV_MAIN_GPIOMUX_INTROUTER0;
sci_irq_req.src_index = CSLR_MAIN_GPIOMUX_INTROUTER0_IN_GPIO0_GPIO_37;
sci_irq_req.dst_id = TISCI_DEV_MAIN_GPIOMUX_INTROUTER0;
sci_irq_req.dst_host_irq = 12;
sci_irq_req.ia_id = 0U;
sci_irq_req.vint = 0U;
sci_irq_req.vint_status_bit_index = 0U;
sci_irq_req.secondary_host = TISCI_MSG_VALUE_RM_UNUSED_SECONDARY_HOST;

ret_val = Sciclient_ProcessRmMessage(&sci_irq_req);
if(ret_val == CSL_PASS)
{
     DebugP_log("interrupt mapping Successful!\r\n");
}
else
{
     DebugP_log("interrupt mapping Failed! \r\n");
}

What is interesting with this code snippet is that Sciclient_ProcessRmMessage returns CSL_PASS (no errors). However, i still do not see my IRQ callback getting called here

Hi Nick, Tushar

Let me double check on this and get back to you with a team member, but I believe we are using SBL boot flow.

In the meantime, if I we're to assume resource allocation was done properly, is the code (calling Sciclient_rmIrqSetRaw()) the right thing to do? Do i need to call any additional APIs (like sciclient_init())?

Does it make sense to be calling sciclient APIs on the DM core, which is running sciserver? Or should we call something direct as we are already on the DM core and don't need to IPC to the DM core in the first place?

Looking around a bit more, i tried running a simple test just to see if sciclient would work and I used and ran this piece of code:

This code also fails in the sciclient_service() function call. So it seems like sciclient() itself is not working?

What I also tried to trace the sciclient/sciserver code itself, and noticed that its writing to the rm driver via this function: Sciclient_ProcessRmMessage

So I also tried replacing the Sciclient_rmIrqSetRaw() with Sciclient_ProcessRmMessage():

struct tisci_msg_rm_irq_set_req sci_irq_req = {0};

sci_irq_req.hdr.type = TISCI_MSG_RM_IRQ_SET;
sci_irq_req.hdr.flags = TISCI_MSG_FLAG_AOP;

//Map Interrupt
sci_irq_req.valid_params = 0U;
sci_irq_req.valid_params |= TISCI_MSG_VALUE_RM_DST_ID_VALID;
sci_irq_req.valid_params |= TISCI_MSG_VALUE_RM_DST_HOST_IRQ_VALID;
sci_irq_req.global_event = 0U;
sci_irq_req.src_id = TISCI_DEV_MAIN_GPIOMUX_INTROUTER0;
sci_irq_req.src_index = CSLR_MAIN_GPIOMUX_INTROUTER0_IN_GPIO0_GPIO_37;
sci_irq_req.dst_id = TISCI_DEV_MAIN_GPIOMUX_INTROUTER0;
sci_irq_req.dst_host_irq = 12;
sci_irq_req.ia_id = 0U;
sci_irq_req.vint = 0U;
sci_irq_req.vint_status_bit_index = 0U;
sci_irq_req.secondary_host = TISCI_MSG_VALUE_RM_UNUSED_SECONDARY_HOST;

ret_val = Sciclient_ProcessRmMessage(&sci_irq_req);
if(ret_val == CSL_PASS)
{
     DebugP_log("interrupt mapping Successful!\r\n");
}
else
{
     DebugP_log("interrupt mapping Failed! \r\n");
}

What is interesting with this code snippet is that Sciclient_ProcessRmMessage returns CSL_PASS (no errors). However, i still do not see my IRQ callback getting called here

Hi Nick,

We are actually using SPL, you are right. Sorry

I tried following your steps. I downloaded the k3 tool, and was able to set up the R5_1 to have 8 MAIN_GPIO_interrupt_router count (and in turn set the same value in A53_2 to 8 as well):

I then took the output rm-cfg.yaml and replaced ours with it: ti-u-boot/board/ti/am62ax/rm-cfg.yaml

I then rebuilt, and flashed tiboot3.bin, tispl.bin and u-boot.img. However, I still am running into the same issue. I am not sure I have set up the k3 tool right, besides changing that 1 parameter, is there anything else i need to change?

Also, it only sets a number. How do I know which INTROUTER can be used now? The .dest_host_irq, is it 0-7, 7-15, or any as long as I don't do it more than 8 times?

Note that I reverted the changed in sciclient_default_boardcfg.

Hm actually it does now work, but only for a few seconds. It looks like once main core comes up, it clobbers the mapping, and remapped it again, and i lose the IRQ. I am using line 12: CSLR_WKUP_R5FSS0_CORE0_INTR_MAIN_GPIOMUX_INTROUTER0_OUTP_12

Is this ok with the above mapping changes?

What I can do as a temporary check is to have a handshake where main core boots, and then I remap it after, and see if that works

Hi Yue,

Yue Hu said:

Also, it only sets a number. How do I know which INTROUTER can be used now? The .dest_host_irq, is it 0-7, 7-15, or any as long as I don't do it more than 8 times?

Can you please try running the below command and share the logs?

k3conf dump rm 3

The above command will tell which cores has MAIN_GPIOMUX resource allocated and the numbers also. Please refer below screenshot.

In the above screenshot, the resource MAIN_GPIOMUX is used by A53 and M4F core only. 

For A53 -> 0 to 15 (inclusive)

For MCU_R5F  -> 34 to 35 (inclusive)

Regards,

Tushar

Hello Yue,

Yue Hu said:

I then rebuilt, and flashed tiboot3.bin, tispl.bin and u-boot.img. However, I still am running into the same issue. I am not sure I have set up the k3 tool right, besides changing that 1 parameter, is there anything else i need to change?

I have tried the SPL flow and after changing the resources in rm-cfg.yaml file, I am able to run the example.

Below is the rm-cfg.yaml changes that I had done.

-
    start_resource: 0
    num_resource: 16
    type: 192
    host_id: 36
    reserved: 0

Please refer below screenshot.

Once the rm-cfg.yaml is changed, I rebuilt the u-boot and replaced the older tiboot3.bin, tispl.bin and u-boot.img with the newer binaries.

Meanwhile, I have not checked the interrupt functionality but the sciclient_rmIrqSetRaw API is returning successfully.

Please check that the resources are allocated properly to WKUP_R5F. Use the above provided command to check the resource allocation.

I am using MCU+SDK v09.02.00.38 and Processor SDK v 09.02.00.05.

Regards,

Tushar