PROCESSOR-SDK-AM64X: GPIO1 interrupt routing to R5_0 running under linux

I'm getting the errors given in the earlier e2e ticket [1] :

[ 4.397029] davinci_gpio 601000.gpio: IRQ index 2 not found
[ 4.397052] davinci_gpio 601000.gpio: error -ENXIO: IRQ not populated

 I'm trying to remove any knowledge of GPIO1 from the linux side, by adding this to my device tree:

&main_gpio1 {
status = "reserved";
};

[1] e2e.ti.com/.../processor-sdk-am64x-gpio1-device-fails-to-initialize-with-error-irq-index-2-not-found

Hello Bruno,

Introduction

You are starting in the right direction. The resource management (RM) configurations in Linux SDK and MCU+ SDK are different. So when CCS loads R5F firmware with SBL NULL, it configures the system to route main domain GPIO interrupts to R5F0. However, when Linux initializes the processor with the SPL boot process described in the Linux SDK docs here (https://software-dl.ti.com/processor-sdk-linux/esd/AM64X/08_05_00_21/exports/docs/linux/Foundational_Components/U-Boot/UG-General-Info.html ), it does NOT route main domain GPIO interrupts to R5F0.

So at a basic level, you need to:

1) modify the resource management settings to route some interrupts to R5F0 using k3-respart-tool
(basically, follow this document: https://software-dl.ti.com/processor-sdk-linux/esd/AM64X/08_05_00_21/exports/docs/linux/How_to_Guides/Host/K3_Resource_Partitioning_Tool.html ). However, don't bother running the setup script, it does not do anything. Instead, click on the folder icon on the far right side of the "Software Product" field, and navigate to the k3-respart-tool folder.

2) Rebuild uboot to include the new resource management files. Reference the Uboot user's guide above.

Answering your specific question: what do all those "hosts" mean? 

The hosts are defined in the TISCI documentation here: https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/am64x/hosts.html

But the definitions aren't super helpful. In general, I assume you would want to use the "non secure" contexts. However, I'm not sure the difference between (for example) context 1 and context 3.

I have assigned your thread to another team member to take a closer look at exactly what each context means (e.g., is context 1 & 2 for core 0, context 3 & 4 for core 1 within the R5F subsystem? Can a single core operate in multiple contexts? If so, how does a core switch between contexts? etc).

Regards,

Nick

Hello Bruno, 

Bruno Bittner1 said:

I then use this example code in a FreeRTOS application which gets loaded from linux.  In this case I don't get interrupts, I instead get an error return from  Sciclient_rmIrqSet() of -1.   I verified that linux doesn't have any GPIO1 settings in the device tree. 

We have created an FAQ about your issue, and I hope this can be helpful in rectifying it.

Please let me know if you need any further assistance.

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1198105/faq-am64x-how-to-run-mcu-sdk-gpio_input_interrupt-example-for-r5fss0-0-with-linux-running-on-a53

Regards,

S.Anil.

Anil,

2 questions for you:

1) The FAQ you linked only documents booting Linux from the MCU+ SBL, not Bruno's current boot mode of booting Linux with SPL. Prashant recently discovered that SBL_EMMC_LINUX has a bug where the SBL code (NOT Linux RemoteProc) needs to be the one to initialize the remote core. If SBL_EMMC_LINUX is used and the SBL is not given the remote core binaries, then SBL tries and fails to initialize the remote cores, puts the remote cores into a bad state, and then Linux is unable to initialize the remote cores with the RemoteProc driver later in the boot process.

Does SBL_OSPI_LINUX have the same bug?

2) The FAQ seems to imply that TISCI_HOST_ID_MAIN_0_R5_1 means R5FSS0-0, and TISCI_HOST_ID_MAIN_0_R5_3 means R5FSS0-1. Is that correct?

Thanks,

Nick

Actually, Prashant confirmed that SBL_OSPI_LINUX has the same behavior as SBL_EMMC_LINUX.

Bruno,

Please take a look at the FAQ. If you are comfortable with switching to an SBL boot mode and using the SBL to initialize the remote cores instead of Linux, follow the FAQ steps (note that Linux RPMsg is able to work with a remote core initialized before Linux boots, as long as the remote core is still enabled in the Linux devicetree. Before Linux tries to initialize a remote core, it checks to see if the core is already running. If the core is running, then Linux just enables RPMsg by writing to the remote core's resource table, then continues the Linux boot process).

If you want to investigate modifying the resource manager configs for the SPL boot, let us know and I will work with you on that.

Regards,

Nick

Hi Nick,  I've read over the FAQ.  I would prefer to stay with the SPL boot.  I've already started on this path.  It may not be clear in my original post, I've been working with k3-respart-tool of ti-processor-sdk-linux-rt-am64xx-evm-08.02.00.23, generating a new sysfw.itb with my board configuration, and building tiboot3.bin with this.

I understand the  general concept of resource management in the context of GPIO INT routing.  You've helped me understand the different host types.  And SBL==mcu+ boot, SPL==linux boot.

Here is a diff of the rm-cfg.c that I' currently using.  I will change to remove host HOST_ID_MAIN_0_R5_0.

diff -Naur mine/rm-cfg.c orig/rm-cfg.c 
--- mine/rm-cfg.c	2023-02-09 23:56:10.736814949 +0100
+++ orig/rm-cfg.c	2023-01-04 17:40:15.000000000 +0100
@@ -173,31 +173,24 @@
 		/* Main GPIO Interrupt Router */
 		{
 			.start_resource = 0,
-			.num_resource = 8,
+			.num_resource = 12,
 			.type = RESASG_UTYPE (AM64X_DEV_MAIN_GPIOMUX_INTROUTER0,
 					RESASG_SUBTYPE_IR_OUTPUT),
 			.host_id = HOST_ID_A53_2,
 		},
 		{
-			.start_resource = 8,
-			.num_resource = 4,
-			.type = RESASG_UTYPE (AM64X_DEV_MAIN_GPIOMUX_INTROUTER0,
-					RESASG_SUBTYPE_IR_OUTPUT),
-			.host_id = HOST_ID_MAIN_0_R5_0,
-		},
-		{
-			.start_resource = 8,
-			.num_resource = 4,
+			.start_resource = 12,
+			.num_resource = 2,
 			.type = RESASG_UTYPE (AM64X_DEV_MAIN_GPIOMUX_INTROUTER0,
 					RESASG_SUBTYPE_IR_OUTPUT),
-			.host_id = HOST_ID_MAIN_0_R5_1,
+			.host_id = HOST_ID_MAIN_1_R5_1,
 		},
 		{
-			.start_resource = 12,
-			.num_resource = 4,
+			.start_resource = 14,
+			.num_resource = 2,
 			.type = RESASG_UTYPE (AM64X_DEV_MAIN_GPIOMUX_INTROUTER0,
 					RESASG_SUBTYPE_IR_OUTPUT),
-			.host_id = HOST_ID_MAIN_0_R5_3,
+			.host_id = HOST_ID_MAIN_1_R5_3,
 		},
 		/* MCU GPIO Interrupt Router */
 		{

Oops, the diff is reversed of what I have, ie.  change + to -, and vice versa.

Hello Bruno,

Great, glad that it is working for you! Thanks for responding back with what you had trouble with, and how you resolved the issue.

1) Just FYI for you and future readers, the k3-resource-partition tool that is packaged in SDKs 8.3 - 8.5 is broken. We fixed it to be working again in the upcoming SDK 8.6.

2) Changing the resource allocation is something where we're trying to add a bunch of documentation over the next couple months to make the process less painful (starting with e2e FAQs, then migrating the information to more "official" documentation). Let us know if you have any additional feedback about stuff that was particularly confusing, or any other feedback on how we could make this easier.

Regards,

Nick

Hi Nick,

One thing I would like to comment about is the increased use of sysconfig in general.  Specifically, k3-respart-tool recommends using sysconfig.  I often have issues with compatibility of .syscfg files with different of sysconfig versions.  Another issue is detailed documentation of what some of the selections in sysconfig do, there is "too much magic".  I would like to see detailed documentation of the .syscfg file contents/syntax/semantics such that I could make a valid sysconfig file,  not that I necessarily want to.  I want to be able to check what the tool is  doing for me.  Or know why the .syscfg file is incompatible with the version of sysconfig, and how to fix it.

Thanks for the feedback Bruno.

Yeah, SysConfig is intended to abstract away the details of the configuration files so that people don't need to worry about figuring out how to write the .sysconfig files manually, but I can see how that also makes it harder if you do want to go into the .sysconfig files and manually make changes or double-check settings. I'll need to think a bit more about potential action items or documentation.

I have filed an internal ticket for our team to discuss more about your SysConfig version incompatibility challenges, and what we want that to look like going forwards. I'll also drive some discussions about how (and where) we want to document all those SysConfig settings, because you're right, there is a good amount of stuff that is not obvious just from looking at it within the tool.

If you have any other questions, please feel free to create a new e2e thread!

Regards,

Nick