• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 2 answers
  • Subscribers 99 subscribers
  • Views 1796 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.

Linux/AM3358: Running PRU remoteproc at boot time

Darren Garnier37
Prodigy 30 points
Part Number: AM3358

Tool/software: Linux

So... I was developing a PRU code with the newish remoteproc / rpmsg framework.  And I really liked how in kernel 4.1.x and 4.4.x that the code would but the PRU up during boot up.. often before much of the rest of the system was fully operational.  However, in recent 4.9.x kernels, the autoboot of the PRUs seems to have disappeared and in general in debian it takes FOREVER for the pruss remoteproc drivers to load and even then they won't autorun.  I can't figure out why this was done.  Or what the workaround might be.  Certainly, remoteproc0 boots the M3 quickly enough.

  • 0
    TI__Guru**** 393215 points
    Debian is not supported by TI. This forum supports only The AM335x Processor SDK: www.ti.com/.../PROCESSOR-SDK-AM335X
  • 0 in reply to Biser Gatchev-XID
    TI__Guru**** 393215 points
    For Debian support on Beaglebone, please ask on www.beagleboard.org
  • 0 in reply to Biser Gatchev-XID
    Prodigy 30 points

    yeah.. the problem isn't what rootfs distro I'm using. I could switch to the Ti SDK and the question would be the same..  The issue is in the kernel driver.  (And I am using the Ti kernel).   The recent changes to rproc_pru took out the ability to autoboot... and its hardwired in, so can't be overridden by the DT.   Answering my own question... the right answer is to patch the driver, put in an autoboot node in the device tree info for it.  

  • 0 in reply to Darren Garnier37
    TI__Genius 10440 points
    Darren,

    The kernel developer wanted to move away from adding custom board-compatible checks and use case related firmware names in the PRU remoteproc driver.

    An example of this is the PRU Ethernet use case that we support on our Industrial Development Kits (IDK) and Industrial Communications Engines (ICE) boards. The 4.1 and 4.4 remoteproc drivers were checking for specific board-compatible strings to match these boards and then loading a specific firmware into the PRUs for those use cases. As of the 4.9 kernel this responsibility has been removed from the PRU remoteproc driver and has been moved into the PRU Ethernet client driver. So, now it is the responsibility of the client driver (drivers/net/ethernet/ti/prueth.c for example) to set the firmware name and then boot the processors.

    Here is the commit message explaining the change as well: git.ti.com/.../

    Instead of patching the PRU remoteproc driver as you mentioned, you could make your own very simple client driver that only sets the firmware name and then boots the PRUs. So, your autoboot node in the device tree could probe this simple driver and could even pass in the firmware name for you to use if you'd like. The prueth.c client driver mentioned above will show how to set the firmware name and boot the PRUs from the kernel driver.

    Jason Reeder
  • 0 in reply to Jason Reeder
    Prodigy 30 points

    Aha.. thank you.  ( I was working on a client driver anyway and expecting it to get loaded by the name in the resource table of the pru firmware... which did seem a little weird to me. )