• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 100 subscribers
  • Views 225 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.

SK-AM64B: Queries on Multicore development

Amey P
Intellectual 320 points
Part Number: SK-AM64B

Hello Team

I have following queries regarding multicore development. I am running LED blink example from Linux on R5_0_0 and M4 core.

1. When I run head /sys/class/remoteproc/remoteproc*/name command in Linux, I see that sometimes R5_0_0 core is associated with with remoteproc1 and sometimes with remoteproc0.

So there was one instance where  remoteproc1 was for R5_0_0 and  remoteproc0 was for M4 core. And after restart it got reversed.

So if this number of remoteproc is not fixed for cores then on runtime how can we automate running the cores if we want to start particular core?

If I run echo start > /sys/class/remoteproc/remoteproc1/state command then I won't be sure which core I am running.

How to ensure remoteproc1 will always be say R5_0_0?

2. I was able to run the LED blink example on M4 core without any changes in the linker.cmd file. But for R5 core I had to do changes in linker.cmd file (I had to add section for resource_table).

Why was this change not required for M4 core?

Thanks

Amey

  • 0
    TI__Guru** 100660 points

    Hello Amey,

    remoteprocX is NOT fixed

    Good observation! The mapping of processor core <--> remoteprocX instance is NOT fixed. Instead, it is decided at boot time. That means that any time you reboot the processor, the core associated with remoteproc0, 1, 2, etc can change.

    Ok, so what do I do if I want to interact with a specific core? 

    If you just want to start up the remote core, you have a couple of options.

    The remoteproc driver initializes the remote cores during Linux boot time by default. If that is the behavior you want your product to follow, then you do not even need to interact with the sysfs interface to initialize your remote cores.

    If you DO want to interact with the remote core during runtime through the sysfs interface, then you will need to know which core is which. For example, if you wanted your application to be able to gracefully shutdown a remote core, and load a different firmware binary into the remote core, you would do that through the sysfs interface.

    use the "name" field to figure out which core is which 

    The name WILL always be the same.

    For example, if you want to interact with R5F0_0, have your code check to see which remoteproc instance has the name "78000000.r5f", and then use that remoteprocX instance.

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    Intellectual 320 points

    Thanks Nick. Yeah I want to access the core in runtime to change firmware.

    So you mean through scripts I will have figure our the remoteprocX number and do further steps?

  • 0 in reply to Amey P
    TI__Guru** 100660 points

    Hello Amey,

    Yes, if you are using the sysfs interface to interact with the remote core, I would suggest finding the core by searching for the name first, that's the method I am familiar with. Unfortunately I do not have sample code that I can point you to.

    Regards,

    Nick