Start M4 firmware from A7 application

[TArre.1]

Hi!

I am using STM32MP157C-DK2 board to create an application on the screen (using GTK library). My idea is to start coprocessor firmware from the A7 application with the following commands (system commands):

int main (int argc, char **argv)
{
  GtkApplication *app;
 
   system("su root -c 'echo core_communication_new_CM4.elf' >  /sys/class/remoteproc/remoteproc0/firmware");
  system("su root -c 'echo start' > /sys/class/remoteproc/remoteproc0/state");
 
  app = gtk_application_new ("org.gtk.example", G_APPLICATION_FLAGS_NONE);
  g_signal_connect (app, "activate", G_CALLBACK (Window_info), NULL);
  status = g_application_run (G_APPLICATION (app), argc, argv);
  g_object_unref (app);
  return status;
}

With these two system commands, I want to boot the M4 firmware (core_communication_new_CM4.elf). Then, I initialize A7 program (probak_GTK) with the following command:

• su -l weston -c "/usr/local/probak_GTK"

However, when I run the A7 application, I get the following message in the Linux terminal:

Does anyone know how I can boot M4 firmware from A7 application?

Thanks!

[Erwan SZYMANSKI]

Hello @TArre.1​ ,

This issue is mainly due to the fact that a weston profile cannot access to su rights. This is what happens when you call your "system()" function.

But remember, everything is file in Linux ! It means that when you do an echo start > file , you just write the word "start" in the file.

Based on this, try to play with fopen(), fprintf() and fclose() functions to write directly what you want in your different files to launch the copro, instead of using the system() function, which is quite ugly by the way ;)

Kind regards,

Erwan

[TArre.1]

Hi @Erwan SZYMANSKI​ thank you for your reply :grinning_face:

I am trying to use your functions (fopen(), fprintf() and fclose()) with the following code:

	FILE* fd;
 
	// SET FIRMWARE
	g_print("Set firmware\n");
	fd = fopen("/sys/class/remoteproc/remoteproc0/firmware", "w");
	if (fd == NULL)
	{
		g_print("Error opening file\n");
		return -1;
	}
	g_print("Firmaware has been opened\n");
 
	fprintf(fd, "core_communication_new_CM4.elf");
	fclose(fd);

However, I am unable to open the file and get the same error:

I do not know if in weston I can not configure the firmware in the coprocessor or I am doing something wrong.

[Erwan SZYMANSKI]

Hello @TArre.1​,

Sorry for the delay of my answer.

Do you still have your issue ?

Can you try to launch you application like this just to compare ?

> cd /usr/local

> su weston

> su -c './probak_GTK'

Kind regards,

Erwan.

[TArre.1]

Hi @Erwan SZYMANSKI​ 

I have tried starting with your command with the following error:

 

It seems that:

• if you launch with the command su -l weston -c "/usr/local/probak_GTK" , you can display GTK application but you cannot access to rproc and configure M4 firmware.
• If you launch with the command  su -c './probak_GTK' , you can configure M4 firmware but you cannot display GTK application.

So I do not know if there is an option to do both together.

Thanks!

[Erwan SZYMANSKI · Accepted solution]

Hello @TArre.1​ ,

My bad, the test from my side was wrong.

In fact, since DV 4.0, all the graphical part needs to be launched by a user session (which is "weston" in our case). But when you run your program as "weston", it is logical to not have access to root privilege for security reasons.

So I think all will depend about your use case:

• If you just need to launch your M4 firmware anyway at the beginning of your GTK program, I think the better way is to use a script that will be executed as root, and first launch your firmware. Then launch your GTK program as weston user.
• If you need to launch your M4 firmware at a specific moment decided by your GTK application, I think you have to think about an architecture for this. A first one would be to have a second "privileged application" that will communicate with your GTK program to run the firmware. Another possibility is to adjust your M4 firmware to be run before your GTK program (as for my first solution), but waiting some event from the copro communication to do some actions.

I hope that these different lines of thought will help you to go forward.

Kind regards,

Erwan.

[TArre.1]

Hi @Erwan SZYMANSKI

I'll try to start the coprocessor from the beginning as it may work for my application.

Thank you for your explanation.:beaming_face_with_smiling_eyes:

Telmo