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.

More info about the PRUSS remoteproc "autoload" feature?

I noticed in Documentation/remoteproc.txt (Kernel docs) that the discussion on firmware loading is via an API offered in the library. However, when the remoteproc driver is loaded it is expecting two files or softlinks to be in /lib/firmware (rproc-pru0-fw, rproc-pru1-fw) and it auto-loads the firmware right away.

So I am unsure as to how these two separate loading systems inter-operate..

 - if the rproc-.. files are not there then the remoteproc driver will hang for a period of time as it cannot autoload the firmware ?

 - is the manual loading system now defunct?

 - how does one go about testing PRU code wit the autoloader? how do I unload the PRU code and then load a changed binary for testing?

 - can the auto loader be shut off? (if manual API loading method is still applicable)?

Thanks,

 - Richard

  • Update: I am guessing that pruss_remoteproc is force loading firmware at it's startup? Not sure on that.. according to docs I did find, remoteproc will try to load the rproc-pru<n>-fw files when probe() is invoked.. so pruss_remoteproc may be doing something else...
  • Hi Richard,

    I will ask the PRU experts to help on this.
  • Richard,

    The API discussed in Documentation/remoteproc.txt is a kernel API that is implemented in drivers/remoteproc/remoteproc_core.c. The pruss_remoteproc driver makes use of this API (and the remoteproc_core implementation) to load, run, and stop the PRU cores.

    Lab 4 in our hands-on examples show how to make use of the pruss_remoteproc driver: 

    As you will see in Lab 4, when you insert the pruss_remoteproc.ko module, the two firmwares (that must be located in the /lib/firmware directory) will be loaded into the PRUs and the PRUs will be ran. In order to unload the PRU code and switch the binaries you can remove the pruss_remoteproc module, change the binaries that are found in /lib/firmware and then insert the module again, like this:

    • rmmod -f pruss_remoteproc.ko
    • ... change the rproc-pru0-fw or rproc-pru1-fw binaries in /lib/firmware ...
    • insmod pruss_remoteproc.ko

    I am not familiar with the manual API loading method, can you point me to any resources on that?

    Let me know if you have anymore questions,

    Jason Reeder

  • Thanks for the response. I was trying to use the -f option on rmmod but this gets me a kernel panic and then a reboot. I thought there might be another way...

    I can load the 2 firmware blobs right now.. that works...

    The API I was referring to is in the kernel docs,
    www.kernel.org/.../remoteproc.txt
    and in section 2 (User API) there are the functions;
    int rproc_boot(struct rproc *rproc) <-- start a PRU program
    void rproc_shutdown(struct rproc *rproc) <-- stop a PRU program
    struct rproc *rproc_get_by_phandle(phandle phandle) <-- get the rproc handle from the device tree 'phandle'.
    I am not sure how relevant these API calls are anymore, are they still usable with this auto-loader system?

    Thanks,
    - Richard
  • Richard,

    The kernel panic on pruss_remoteproc module removal was corrected as part of the PRU SWPKG v2.0.0.0 (http://software-dl.ti.com/sitara_linux/esd/PRU-SWPKG/latest/index_FDS.html). Keep in mind that this version of the PRU SWPKG only installs on top of SDK 8.0 or Processor SDK 1.0.0.

    The API you refer to in the kernel docs is a kernel API. The provided kernel drivers (remoteproc_core and pruss_remoteproc) make use of these kernel APIs in order to start and stop a PRU program. So, the 'auto-loader' uses the APIs.

    Jason Reeder