• State Resolved
  • Locked Locked
  • Replies 22 replies
  • Answers 4 answers
  • Subscribers 100 subscribers
  • Views 1815 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.

AM4376: Linux 5.4 zeus, PRU kernel modules

Gunter Schmer
Genius 14212 points
Part Number: AM4376

Hi, 

at a customer we are using the Yocto "zeus" branch and are building linux-ti-staging recipe to build the Linux 5.4 kernel and modules. 

These modules are

pruss, pru_rproc, Irq_pruss_intc

virtio_rpmsg_bus, rpmsg_pru.

Currently by default the following modules get loaded: pruss, pru_rproc, Irq_pruss_intc

This seems to be ok.

We have a problem with virtio_rpmsg_bus when loading:

Both these modules are dependent, up on manual loading “virtio_rpmsg_bus.ko" – it should automatically insert rpmsg_pru.ko.

 

-rw-r--r--    1 root     root         21048 Sep 20 07:28 virtio_rpmsg_bus.ko

-rw-r--r--    1 root     root         12980 Sep 20 07:28 rpmsg_pru.ko

However in Linux 5.4 with manual insmod of virtio_rpmsg_bus.ko nothing happens, nothing in dmesg.

On previous kernel revisions (e.g. Linux 4.4) the following was the expected behavior:

[151048.229135] ti-pruss 54400000.pruss: unconfigured system_events = 0x00000000000c0000 host_intr = 0x0000000a

[151048.229178]  remoteproc2: stopped remote processor 54438000.pru1

[151077.198204]  remoteproc2: powering up 54438000.pru1

[151077.198867]  remoteproc2: Booting fw image am437x-pru1_1-fw, size 90740

[151077.199173] ti-pruss 54400000.pruss: configured system_events = 0x00000000000c0000 intr_channels = 0x0000000a host_intr = 0x0000000a

[151077.206675]  remoteproc2: remote processor 54438000.pru1 is now up

[151077.207483] virtio_rpmsg_bus virtio0: creating channel rpmsg-pru addr 0x1f

[151077.209306] virtio_rpmsg_bus virtio0: rpmsg host is online

[151077.232176] rpmsg_pru rpmsg0: new rpmsg_pru device: /dev/rpmsg_pru31

Could you provide your feedback?

Has this been tested with the new kernel?

Regards,

--Gunter

  • 0
    Prodigy 180 points

    Also what is the configuration required to automatically insert kernel modules virtio_rpmsg_bus, rpmsg_pru. Right now they both are not loaded automatically during Linux boot.

    Please let us know the configuration

  • 0 in reply to praveen velpuri
    TI__Guru** 100980 points

    Hello Gunter & Praveen,

    What happens when you select your PRU firmware and initialize the PRU using the sysfs interface as per our RemoteProc and RPMsg documentation?

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    TI__Guru** 100980 points

    (I have not run any PRU tests on Linux 5.4 yet, but I would expect it to behave similarly to Linux 4.19).

  • 0 in reply to Nick Saulnier
    Prodigy 180 points

    I do not see any change, even though pru1 state say's running.

    root@am437x:/lib/firmware# echo "am437x-pru1_0-fw" > /sys/class/remoteproc/remoteproc1/firmware
    root@am437x:/lib/firmware#
    root@am437x:/lib/firmware# echo "am437x-pru1_1-fw" > /sys/class/remoteproc/remoteproc1/firmware
    root@am437x:/lib/firmware# echo 'start' > /sys/class/remoteproc/remoteproc1/state
    root@am437x:/lib/firmware# echo 'start' > /sys/class/remoteproc/remoteproc2/state
    -sh: echo: write error: File exists
    root@am437x:/lib/firmware#
    root@am437x:/lib/firmware# cat /sys/class/remoteproc/remoteproc2/state
    offline
    root@am437x:/lib/firmware# cat /sys/class/remoteproc/remoteproc1/state
    running
    root@am437x:/lib/firmware# echo 'start' > /sys/class/remoteproc/remoteproc2/state
    -sh: echo: write error: File exists
    root@am437x:/lib/firmware# rm /sys/class/remoteproc/remoteproc2/state
    rm: can't remove '/sys/class/remoteproc/remoteproc2/state': Operation not permitted
    root@am437x:/lib/firmware# rm -rf /sys/class/remoteproc/remoteproc2/state
    rm: can't remove '/sys/class/remoteproc/remoteproc2/state': Operation not permitted
    root@am437x:/lib/firmware# echo 'start' > /sys/class/remoteproc/remoteproc2/state
    -sh: echo: write error: File exists
    root@am437x:/lib/firmware#

    root@am437x:/lib/firmware# cat /sys/class/remoteproc/remoteproc2/state
    offline
    root@am437x:/lib/firmware# cat /sys/class/remoteproc/remoteproc0/state
    offline
    root@am437x:/lib/firmware# cat /sys/class/remoteproc/remoteproc1/state
    running
    root@a
    root@am437x:/lib/firmware#
    root@am437x:/lib/firmware# lsmod
    Tainted: G
    virtio_rpmsg_bus 20480 0 - Live 0xbf0c5000
    rpmsg_char 16384 0 - Live 0xbf0db000
    gpio_mon 16384 0 - Live 0xbf0c0000 (O)
    nf_conntrack_tftp 16384 0 - Live 0xbf0d0000
    xt_conntrack 16384 2 - Live 0xbf0cb000
    nf_conntrack 102400 2 nf_conntrack_tftp,xt_conntrack, Live 0xbf0a6000
    nf_defrag_ipv6 20480 1 nf_conntrack, Live 0xbf0a0000
    libcrc32c 16384 1 nf_conntrack, Live 0xbf09b000
    nf_defrag_ipv4 16384 1 nf_conntrack, Live 0xbf096000
    xt_multiport 16384 5 - Live 0xbf091000
    xt_tcpudp 16384 7 - Live 0xbf08c000
    ip6table_filter 16384 0 - Live 0xbf087000
    ip6_tables 28672 1 ip6table_filter, Live 0xbf07f000
    iptable_filter 16384 1 - Live 0xbf071000
    ip_tables 28672 1 iptable_filter, Live 0xbf077000
    x_tables 32768 7 xt_conntrack,xt_multiport,xt_tcpudp,ip6table_filter,ip6_tables,iptable_filter,ip_tables, Live 0xbf060000
    pru_rproc 24576 1 - Live 0xbf06a000
    irq_pruss_intc 16384 2 pru_rproc, Live 0xbf051000
    omap_des 20480 0 - Live 0xbf05a000
    omap_aes_driver 24576 0 - Live 0xbf04a000
    omap_crypto 16384 2 omap_des,omap_aes_driver, Live 0xbf045000
    omap_sham 32768 0 - Live 0xbf038000
    pruss 16384 1 pru_rproc, Live 0xbf02f000
    crypto_engine 16384 2 omap_des,omap_aes_driver, Live 0xbf027000
    libdes 28672 1 omap_des, Live 0xbf01d000
    ti_emif_sram 16384 0 - Live 0xbf018000
    libaes 16384 1 omap_aes_driver, Live 0xbf013000
    dwc3_omap 16384 0 - Live 0xbf00e000
    rtc_omap 20480 1 - Live 0xbf008000
    omap_wdt 16384 1 - Live 0xbf000000
    root@am437x:/lib/firmware# lsmod | grep rpmsg
    virtio_rpmsg_bus 20480 0 - Live 0xbf0c5000
    rpmsg_char 16384 0 - Live 0xbf0db000

  • 0 in reply to praveen velpuri
    Prodigy 180 points

    dmesg error 

    [141273.323120] remoteproc remoteproc1: powering up 54434000.pru
    [141273.349530] remoteproc remoteproc1: Booting fw image am437x-pru1_1-fw, size 91908
    [141273.349841] pru-rproc 54434000.pru: Allocated carveout doesn't fit device address request
    [141273.349911] pru-rproc 54434000.pru: Allocated carveout doesn't fit device address request
    [141273.350089] pru-rproc 54434000.pru: configured system_events[63-0] = 00000000,000c0000
    [141273.350097] pru-rproc 54434000.pru: configured intr_channels = 0x0000000a host_intr = 0x0000000a
    [141273.352126] virtio_rpmsg_bus virtio0: rpmsg host is online
    [141273.352246] remoteproc1#vdev0buffer: registered virtio0 (type 7)
    [141273.352255] remoteproc remoteproc1: remote processor 54434000.pru is now up
    [141278.271608] remoteproc remoteproc2: powering up 54438000.pru
    [141278.272401] remoteproc remoteproc2: Booting fw image am437x-pru1_1-fw, size 91908
    [141278.273722] pru-rproc 54438000.pru: Allocated carveout doesn't fit device address request
    [141278.273898] pru-rproc 54438000.pru: Allocated carveout doesn't fit device address request
    [141278.274218] pru-rproc 54438000.pru: event 18 (req. channel 3) already assigned to channel 3
    [141278.274240] pru-rproc 54438000.pru: failed to configure pruss intc -17
    [141278.274258] remoteproc remoteproc2: Failed to process post-loading resources: -17
    [141278.274486] remoteproc remoteproc2: Boot failed: -17
    [141309.299190] remoteproc remoteproc2: powering up 54438000.pru
    [141309.299910] remoteproc remoteproc2: Booting fw image am437x-pru1_1-fw, size 91908
    [141309.301137] pru-rproc 54438000.pru: Allocated carveout doesn't fit device address request
    [141309.301300] pru-rproc 54438000.pru: Allocated carveout doesn't fit device address request
    [141309.301620] pru-rproc 54438000.pru: event 18 (req. channel 3) already assigned to channel 3
    [141309.301640] pru-rproc 54438000.pru: failed to configure pruss intc -17
    [141309.301658] remoteproc remoteproc2: Failed to process post-loading resources: -17
    [141309.301888] remoteproc remoteproc2: Boot failed: -17
    [141327.147310] remoteproc remoteproc2: powering up 54438000.pru
    [141327.148035] remoteproc remoteproc2: Booting fw image am437x-pru1_1-fw, size 91908
    [141327.149333] pru-rproc 54438000.pru: Allocated carveout doesn't fit device address request
    [141327.149607] pru-rproc 54438000.pru: Allocated carveout doesn't fit device address request
    [141327.149929] pru-rproc 54438000.pru: event 18 (req. channel 3) already assigned to channel 3
    [141327.149950] pru-rproc 54438000.pru: failed to configure pruss intc -17
    [141327.149968] remoteproc remoteproc2: Failed to process post-loading resources: -17
    [141327.150193] remoteproc remoteproc2: Boot failed: -17
    root@ocs-am437x:/lib/firmware#

  • 0 in reply to praveen velpuri
    Prodigy 180 points

    Another observation from 4.4 is that, insmod of virtio_rpmsg_bus.ko is not automatically loading rpmsg_pru.ko driver.

    root@ocs-am437x:/lib/modules/5.4.28-MS_OCS_RM_101.1.18.35-g6f3bf13d53/kernel/drivers/rpmsg# insmod virtio_rpmsg_bus.ko
    root@ocs-am437x:/lib/modules/5.4.28-MS_OCS_RM_101.1.18.35-g6f3bf13d53/kernel/drivers/rpmsg# lsmod
    Tainted: G
    virtio_rpmsg_bus 20480 0 - Live 0xbf0c1000
    gpio_mon 16384 0 - Live 0xbf0bc000 (O)
    nf_conntrack_tftp 16384 0 - Live 0xbf0cc000
    xt_conntrack 16384 2 - Live 0xbf0c7000
    nf_conntrack 102400 2 nf_conntrack_tftp,xt_conntrack, Live 0xbf0a2000
    nf_defrag_ipv6 20480 1 nf_conntrack, Live 0xbf09c000
    libcrc32c 16384 1 nf_conntrack, Live 0xbf097000
    nf_defrag_ipv4 16384 1 nf_conntrack, Live 0xbf092000
    xt_multiport 16384 5 - Live 0xbf08d000
    xt_tcpudp 16384 7 - Live 0xbf088000
    ip6table_filter 16384 0 - Live 0xbf083000
    ip6_tables 28672 1 ip6table_filter, Live 0xbf07b000
    iptable_filter 16384 1 - Live 0xbf050000
    ip_tables 28672 1 iptable_filter, Live 0xbf073000
    x_tables 32768 7 xt_conntrack,xt_multiport,xt_tcpudp,ip6table_filter,ip6_tables,iptable_filter,ip_tables, Live 0xbf05f000
    pru_rproc 24576 0 - Live 0xbf06c000
    irq_pruss_intc 16384 1 pru_rproc, Live 0xbf04b000
    omap_aes_driver 24576 0 - Live 0xbf058000
    omap_des 20480 0 - Live 0xbf040000
    omap_crypto 16384 2 omap_aes_driver,omap_des, Live 0xbf03b000
    pruss 16384 1 pru_rproc, Live 0xbf046000
    crypto_engine 16384 2 omap_aes_driver,omap_des, Live 0xbf036000
    libdes 28672 1 omap_des, Live 0xbf02c000
    libaes 16384 1 omap_aes_driver, Live 0xbf025000
    ti_emif_sram 16384 0 - Live 0xbf020000
    omap_sham 32768 0 - Live 0xbf013000
    dwc3_omap 16384 0 - Live 0xbf00e000
    rtc_omap 20480 1 - Live 0xbf008000
    omap_wdt 16384 1 - Live 0xbf000000
    root@ocs-am437x:/lib/modules/5.4.28-MS_OCS_RM_101.1.18.35-g6f3bf13d53/kernel/drivers/rpmsg#oot@ocs-am437x:/lib/modules/5.4.28-MS_OCS_RM_101.1.18.35-g6f3bf13d53/kernel/drivers/rpmsg#

    root@ocs-am437x:/lib/modules/5.4.28-MS_OCS_RM_101.1.18.35-g6f3bf13d53/kernel/drivers/rpmsg#
    root@ocs-am437x:/lib/modules/5.4.28-MS_OCS_RM_101.1.18.35-g6f3bf13d53/kernel/drivers/rpmsg# lsmod | grep pru
    pru_rproc 24576 0 - Live 0xbf06c000
    irq_pruss_intc 16384 1 pru_rproc, Live 0xbf04b000
    pruss 16384 1 pru_rproc, Live 0xbf046000
    root@ocs-am437x:/lib/modules/5.4.28-MS_OCS_RM_101.1.18.35-g6f3bf13d53/kernel/drivers/rpmsg# lsmod | grep rpmsg
    virtio_rpmsg_bus 20480 0 - Live 0xbf0c1000
    root@ocs-am437x:/lib/modules/5.4.28-MS_OCS_RM_101.1.18.35-g6f3bf13d53/kernel/drivers/rpmsg#

  • 0 in reply to praveen velpuri
    Prodigy 180 points

    I have restarted the board, this time both pru1 and pru2, both running but I don't see any rpmsg character driver /dev.

    I am not sure what is the use of remoteproc0 here ?

    root@ocs-am437x:~# echo 'start' > /sys/class/remoteproc/remoteproc1/state
    root@ocs-am437x:~#
    root@ocs-am437x:~#
    root@ocs-am437x:~# cat /sys/class/remoteproc/remoteproc1/state
    running
    root@ocs-am437x:~# cat /sys/class/remoteproc/remoteproc2/state
    offline
    root@ocs-am437x:~#
    root@ocs-am437x:~#
    root@ocs-am437x:~# echo 'start' > /sys/class/remoteproc/remoteproc2/state
    root@ocs-am437x:~#
    root@ocs-am437x:~# cat /sys/class/remoteproc/remoteproc2/state
    running
    root@ocs-am437x:~#

    DMESG LOG:

    [27099.957654] remoteproc remoteproc1: powering up 54434000.pru
    [27099.987327] remoteproc remoteproc1: Booting fw image am437x-pru1_0-fw, size 114924
    [27099.987419] remoteproc remoteproc1: remote processor 54434000.pru is now up
    [27149.264337] remoteproc remoteproc2: powering up 54438000.pru
    [27149.287944] remoteproc remoteproc2: Booting fw image am437x-pru1_1-fw, size 91908
    [27149.288480] pru-rproc 54438000.pru: Allocated carveout doesn't fit device address request
    [27149.288633] pru-rproc 54438000.pru: Allocated carveout doesn't fit device address request
    [27149.288958] pru-rproc 54438000.pru: configured system_events[63-0] = 00000000,000c0000
    [27149.288980] pru-rproc 54438000.pru: configured intr_channels = 0x0000000a host_intr = 0x0000000a
    [27149.292603] virtio_rpmsg_bus virtio0: rpmsg host is online
    [27149.292819] remoteproc2#vdev0buffer: registered virtio0 (type 7)
    [27149.292841] remoteproc remoteproc2: remote processor 54438000.pru is now up

    Device ls command output

    root@ocs-am437x:/dev# ls -lrt r
    ram0 ram10 ram12 ram14 ram2 ram4 ram6 ram8 random rtc
    ram1 ram11 ram13 ram15 ram3 ram5 ram7 ram9 rfkill rtc0

  • 0 in reply to praveen velpuri
    TI__Guru** 100980 points

    Hello Praveen,

    Several notes:

    1) the RemoteProc driver has changed pretty significantly between 2016 (Linux 4.4) and 2020 (Linux 5.4). So do not expect the behavior to be exactly the same. I would expect that virtio_rpmsg_bus.ko does not need to be insmodded - it should be loaded by the driver when it sees that the PRU firmware it is loading uses RPMsg.

    Note that RemoteProc is what Linux uses to initialize any "remote processor". So depending on the Sitara device that you are using, remoteprocX might be pru cores, the m3 core, DSP cores, etc.

    2) remoteproc0, remoteproc1, etc. are not deterministic - they are assigned at runtime. So let's start by making sure that you are using the PRU cores you think you are using. Here is an example I just ran on AM437x Linux Processor SDK 6.3 (Linux 4.19):

    root@am437x-evm:~# grep -Isr pru /sys/kernel/debug/remoteproc/
/sys/kernel/debug/remoteproc/remoteproc4/name:54478000.pru
/sys/kernel/debug/remoteproc/remoteproc3/name:54474000.pru
/sys/kernel/debug/remoteproc/remoteproc2/name:54438000.pru
/sys/kernel/debug/remoteproc/remoteproc1/name:54434000.pru

    By looking at the AM437x memory map in the Technical Reference Manual (TRM), we know that the ARM sees PRU_ICSS1 at 0x5440_0000. If we go to the PRU chapter of the TRM, section "Global Memory Map", we see that the ARM sees PRU_ICSS1_PRU0 IRAM at offset 0x3_4000, PRU_ICSS1_PRU1 IRAM at offset 0x3_8000, PRU_ICSS0_PRU0 IRAM at offset 0x7_4000, and PRU_ICSS0_PRU1 IRAM at offset 0x7_8000.

    So on my board right now, remoteproc1 = ICSS1_pru0, remoteproc2 = ICSS1_pru1, remoteproc3 = ICSS0_pru0, remoteproc4 = ICSS0_pru1.

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    Prodigy 180 points

    Hi Nick,

    Thanks

    1.  How and when rpmsg_pru.ko driver get's loaded, what configuration required to auto load module during boot. How is it behaving with EVM board ?
    2. Do you want me insmod rpmsg_pru.ko every time i execute test ?

    3. root@ocs-am437x:~# grep -Isr pru /sys/kernel/debug/remoteproc/
      /sys/kernel/debug/remoteproc/remoteproc2/name:54438000.pru
      /sys/kernel/debug/remoteproc/remoteproc1/name:54434000.pru
      root@ocs-am437x:~#
      root@ocs-am437x:~# cat /sys/class/remoteproc/remoteproc2/state
      offline
      root@ocs-am437x:~# cat /sys/class/remoteproc/remoteproc1/state
      offline
      root@ocs-am437x:~# ls -lrt /lib/firmware/
      drwxr-xr-x 2 root root 229 Sep 20 07:29 pru
      lrwxrwxrwx 1 root root 29 Sep 20 07:29 am437x-pru1_1-fw -> /lib/firmware/pru/pru_1_1.out
      lrwxrwxrwx 1 root root 29 Sep 20 07:29 am437x-pru1_0-fw -> /lib/firmware/pru/pru_1_0.out
      lrwxrwxrwx 1 root root 49 Sep 20 07:29 am437x-pru0_1-fw -> /lib/firmware/pru/PRU_RPMsg_Echo_Interrupt0_1.out
      lrwxrwxrwx 1 root root 49 Sep 20 07:29 am437x-pru0_0-fw -> /lib/firmware/pru/PRU_RPMsg_Echo_Interrupt0_0.out
      root@ocs-am437x:~#
      root@ocs-am437x:~# echo "am437x-pru1_1-fw" > /sys/class/remoteproc/remoteproc2/firmware
      root@ocs-am437x:~# echo 'start' > /sys/class/remoteproc/remoteproc2/state

      [ 549.736912] remoteproc remoteproc2: powering up 54438000.pru
      [ 549.759054] remoteproc remoteproc2: Booting fw image am437x-pru1_1-fw, size 91908
      [ 549.759398] pru-rproc 54438000.pru: Allocated carveout doesn't fit device address request
      [ 549.759484] pru-rproc 54438000.pru: Allocated carveout doesn't fit device address request
      [ 549.759675] pru-rproc 54438000.pru: configured system_events[63-0] = 00000000,000c0000
      [ 549.759685] pru-rproc 54438000.pru: configured intr_channels = 0x0000000a host_intr = 0x0000000a
      [ 549.761562] remoteproc2#vdev0buffer: registered virtio0 (type 7)
      [ 549.761580] remoteproc remoteproc2: remote processor 54438000.pru is now up
      [ 549.775094] virtio_rpmsg_bus virtio0: rpmsg host is online

    4.  That's correct PRU_ICSS 54400000,PRU0 0x34000 and  PRU1 38000. I confirm from my device tree. 
    5. Please note that our board enabled only for  remoteproc2 = ICSS1_pru1

  • 0 in reply to praveen velpuri
    TI__Guru** 100980 points

    Hello Praveen,

    Please reference the RPMsg Quick Start Guide. If you are enabling RPMsg in the kernel, I do not think you would need to insmod rpmsg.

    Auto-loading PRU firmware on boot is a separate subject. Let's keep this thread focused on getting PRU and RPMsg working. You can create a new thread if you want to discuss auto-loading PRU firmware.

    Please try to get TI's example RPMsg_Echo_Interrupt working first. Once you get a known good state, then you can start working on your custom PRU firmware.

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    Prodigy 180 points

    Ok, let's focus  on rpmsg driver communication problem with PRU 

    As per the RPMSG notes, i had tried and shared logs in my earlier thread. After inserting module rpmsg_pru.ko, i do not see any character device listed dev with name /dev/rpmsg_pruxx,

    1.  We are using latest yocto linux-ti-staging 5.4 lsk branch
    2. I was able to insert manually lsmod rpmsg_pru.ko, pru had loaded with firmware.
    3. How ever i do not see character device rpmsg under dev.

    Please let me know what is the reason for not seeing /dev/rpmsg_pruxx  chacter device, is it working from your EVM set up ?

    Log

    1. root@ocs-am437x:~# grep -Isr pru /sys/kernel/debug/remoteproc/
      /sys/kernel/debug/remoteproc/remoteproc2/name:54438000.pru
      /sys/kernel/debug/remoteproc/remoteproc1/name:54434000.pru
      root@ocs-am437x:~#
      root@ocs-am437x:~# cat /sys/class/remoteproc/remoteproc2/state
      offline
      root@ocs-am437x:~# cat /sys/class/remoteproc/remoteproc1/state
      offline
      root@ocs-am437x:~# ls -lrt /lib/firmware/
      drwxr-xr-x 2 root root 229 Sep 20 07:29 pru
      lrwxrwxrwx 1 root root 29 Sep 20 07:29 am437x-pru1_1-fw -> /lib/firmware/pru/pru_1_1.out
      lrwxrwxrwx 1 root root 29 Sep 20 07:29 am437x-pru1_0-fw -> /lib/firmware/pru/pru_1_0.out
      lrwxrwxrwx 1 root root 49 Sep 20 07:29 am437x-pru0_1-fw -> /lib/firmware/pru/PRU_RPMsg_Echo_Interrupt0_1.out
      lrwxrwxrwx 1 root root 49 Sep 20 07:29 am437x-pru0_0-fw -> /lib/firmware/pru/PRU_RPMsg_Echo_Interrupt0_0.out
      root@ocs-am437x:~#
      root@ocs-am437x:~# echo "am437x-pru1_1-fw" > /sys/class/remoteproc/remoteproc2/firmware
      root@ocs-am437x:~# echo 'start' > /sys/class/remoteproc/remoteproc2/state

      [ 549.736912] remoteproc remoteproc2: powering up 54438000.pru
      [ 549.759054] remoteproc remoteproc2: Booting fw image am437x-pru1_1-fw, size 91908
      [ 549.759398] pru-rproc 54438000.pru: Allocated carveout doesn't fit device address request
      [ 549.759484] pru-rproc 54438000.pru: Allocated carveout doesn't fit device address request
      [ 549.759675] pru-rproc 54438000.pru: configured system_events[63-0] = 00000000,000c0000
      [ 549.759685] pru-rproc 54438000.pru: configured intr_channels = 0x0000000a host_intr = 0x0000000a
      [ 549.761562] remoteproc2#vdev0buffer: registered virtio0 (type 7)
      [ 549.761580] remoteproc remoteproc2: remote processor 54438000.pru is now up
      [ 549.775094] virtio_rpmsg_bus virtio0: rpmsg host is online

  • 0 in reply to praveen velpuri
    TI__Guru** 100980 points

    Hello Praveen,

    Please take a step back. Do not use insmod. Do not use pru_1_1.out. Just follow the steps in the RPMsg quick start guide. Load the prebuilt firmwares PRU_RPMsg_Echo_Interrupt1_1.out and PRU_RPMsg_Echo_Interrupt1_1.out. I am not running tests on Linux 5.4 right now, so it is up to you to get a known good state.

    Once you get the steps in the quick start guide working, then you can start trying one new thing at a time until you have your entire setup working.

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    Prodigy 180 points

    Hello Nick,

    Gunter from TI was able to reproduce the same issue on a EVM board with out customer PRU libraries.

    It is important to you try on your board and confirm if the /dev/rpmsg_pruxx driver is working.

    What is the procedure to expedite this case, we have blocked more than a week on this issue.

    I will try my end today

  • 0 in reply to praveen velpuri
    Prodigy 180 points

    The issue is reproducible even with /lib/firmware/pru/PRU_RPMsg_Echo_Interrupt0_0.out and  /lib/firmware/pru/PRU_RPMsg_Echo_Interrupt0_1.out.

    I had also provided debug point earlier on linux 4.4, if I do manual insmod of rpmsg_pru.ko, the /dev/rpmsg_pruxx character device is created although there is a transition code churn from 4.4 to 5.4, i don't expect behavior to change unless if you provide what changes made in 5.4 in design change.

    root@ocs-am437x:/lib/firmware# ls -lrt

    drwxr-xr-x 2 root root 229 Sep 20 07:29 pru
    lrwxrwxrwx 1 root root 29 Sep 20 07:29 am437x-pru1_1-fw -> /lib/firmware/pru/pru_1_1.out
    lrwxrwxrwx 1 root root 29 Sep 20 07:29 am437x-pru1_0-fw -> /lib/firmware/pru/pru_1_0.out
    lrwxrwxrwx 1 root root 49 Sep 20 07:29 am437x-pru0_1-fw -> /lib/firmware/pru/PRU_RPMsg_Echo_Interrupt0_1.out
    lrwxrwxrwx 1 root root 49 Sep 20 07:29 am437x-pru0_0-fw -> /lib/firmware/pru/PRU_RPMsg_Echo_Interrupt0_0.out
    root@ocs-am437x:/lib/firmware#
    root@ocs-am437x:/lib/firmware# echo 'stop' > /sys/class/remoteproc/remoteproc1/state
    -sh: echo: write error: Invalid argument
    root@ocs-am437x:/lib/firmware# echo 'stop' > /sys/class/remoteproc/remoteproc2/state
    -sh: echo: write error: Invalid argument
    root@ocs-am437x:/lib/firmware# cat /sys/class/remoteproc/remoteproc1/state
    offline
    root@ocs-am437x:/lib/firmware# cat /sys/class/remoteproc/remoteproc2/state
    offline
    root@ocs-am437x:/lib/firmware# echo 'am437x-pru0_0-fw' > /sys/class/remoteproc/remoteproc1/firmware
    root@ocs-am437x:/lib/firmware# echo 'am437x-pru0_1-fw' > /sys/class/remoteproc/remoteproc2/firmware
    root@ocs-am437x:/lib/firmware# echo 'start' > /sys/class/remoteproc/remoteproc1/state
    root@ocs-am437x:/lib/firmware# echo 'start' > /sys/class/remoteproc/remoteproc2/state
    root@ocs-am437x:/lib/firmware# cat /sys/class/remoteproc/remoteproc1/state
    running
    root@ocs-am437x:/lib/firmware# cat /sys/class/remoteproc/remoteproc2/state
    running
    root@ocs-am437x:/lib/firmware# ls /dev/ | grep pru

    dmesg log:

    [60896.081577] remoteproc remoteproc1: powering up 54434000.pru
    [60896.104148] remoteproc remoteproc1: Booting fw image am437x-pru0_0-fw, size 81028
    [60896.105397] pru-rproc 54434000.pru: configured system_events[63-0] = 00000000,00030000
    [60896.105410] pru-rproc 54434000.pru: configured intr_channels = 0x00000005 host_intr = 0x00000005
    [60896.107881] remoteproc1#vdev0buffer: registered virtio0 (type 7)
    [60896.107899] remoteproc remoteproc1: remote processor 54434000.pru is now up
    [60896.121171] virtio_rpmsg_bus virtio0: rpmsg host is online
    [60904.449377] remoteproc remoteproc2: powering up 54438000.pru
    [60904.466649] remoteproc remoteproc2: Booting fw image am437x-pru0_1-fw, size 81028
    [60904.467603] pru-rproc 54438000.pru: configured system_events[63-0] = 00000000,000c0000
    [60904.467619] pru-rproc 54438000.pru: configured intr_channels = 0x0000000a host_intr = 0x0000000a
    [60904.469998] virtio_rpmsg_bus virtio1: rpmsg host is online
    [60904.470139] remoteproc2#vdev0buffer: registered virtio1 (type 7)
    [60904.470153] remoteproc remoteproc2: remote processor 54438000.pru is now up

  • 0 in reply to praveen velpuri
    TI__Guru** 111605 points

    Hi Gunter, Praveen,

    Linux 4.4 to Linux 5.4 is a big jump, and there have been lot of changes in the remoteproc and rpmsg subsystems. And so the behavior is quite different between the two kernels. There is no issue as such with 5.4 kernel, except that the users would have to start the PRUs to get the desired behavior.

    The main differences that impact the previously seen behavior is the decoupling of virtio device handling in remoteproc core, and a feature called "auto-boot" for remoteprocs. The remoteproc subsystem also gained a sysfs interface that can be used to start/stop remoteprocs, and change firmware name. We also have a means to configure PRU firmwares from dts or let a PRU client driver set a desired firmware name using an API. 

    The 4.4 PRU remoteproc driver and boot flow is restrictive in that it had to encapsulate all the different firmware names, and to decide which ones to boot using a module parameter. This has since been fixed, and will now allows a user to use various interfaces to control them.

    Coming to the functional difference, the PRU remoteproc driver is configured with "auto-boot" disabled, meaning PRU cores are not loaded and booted upon the driver probe.. You would have to start the PRU cores either from userspace using the sysfs interfaces or by an API invocation from a corresponding PRU consumer driver (like PRU Ethernet or PRU Soft UART etc). There are checks in place to prevent userspace to use sysfs interface when a kernel PRU client driver has booted the core. This allows the user to run different PRU applications. 

    So, on 5.4, you can read the remoteproc 'state' and default 'firmwares' and the name of remoteproc

    cat /sys/class/remoteproc/remoteproc*/name

    cat /sys/class/remoteproc/remoteproc*/state

    cat /sys/class/remoteproc/remoteproc*/firmware

    From userspace, you can start or stop by using 'state' sysfs file or change the firmware name that the driver will boot using 'firmware' file (firmware still has to be in the default firmware directory like /lib/firmware).

    echo start > /sys/class/remoteproc/remoteproc1/state

    If using the RPMsg_Echo_Interrupt firmware images, the loading/booting process will first create the virtio device (and lets udev load virtio_rpmsg_bus), and the published rpmsg devices from the PRU firmware which then causes the udev to load the pru_rpmsg driver and create the /dev/rpmsg_pruX devices.

    Also, FWIW, the official OE branches to use with 5.4 kernels is dunfell, and not zeus. zeus was only an intermediary branch.

    regards

    Suman

  • 0 in reply to Suman Anna
    TI__Guru** 111605 points

    Please also ensure that your firmware resource tables are updated to use FW_RSC_ADDR_ANY for the vring da.

    See

    https://git.ti.com/gitweb?p=pru-software-support-package/pru-software-support-package.git;a=commitdiff;h=bc772adc18ca03c80e904aa8d2b17a9edca828b0

    I missed seeing the messages on Page 1 of this thread, but the following traces indicate this failure. These confirm that your firmwares' resource tables do not have this change:

    [141273.349841] pru-rproc 54434000.pru: Allocated carveout doesn't fit device address request
    [141273.349911] pru-rproc 54434000.pru: Allocated carveout doesn't fit device address request

  • 0 in reply to Suman Anna
    TI__Genius 14212 points

    Hi Suman,

    thanks for all your feedback, and specifics on the remoteproc sysfs interface. In our testing we are using this interface, as currently the remoteproc is not autoloading the firmware, so we are doing this manually.

    Let me summarize where we stand now, here in a parallel test on the AM437x EVM:

    On bootup the remote proc makes the PRU cores available

    root@am437x-evm:~# uname -a
    Linux am437x-evm 5.4.58-gd1b11ffdf0 #2 PREEMPT Wed Sep 23 17:20:20 PDT 2020 armv7l GNU/Linux

    root@am437x-evm:~# dmesg |grep remoteproc
    [ 7.052357] remoteproc remoteproc0: wkup_m3 is available
    [ 8.420864] remoteproc remoteproc0: powering up wkup_m3
    [ 8.516011] remoteproc remoteproc0: Booting fw image am335x-pm-firmware.elf, size 243196
    [ 8.684432] remoteproc remoteproc0: remote processor wkup_m3 is now up
    [ 19.603741] remoteproc remoteproc1: 54434000.pru is available
    [ 19.923638] remoteproc remoteproc2: 54438000.pru is available
    [ 20.074704] remoteproc remoteproc3: 54474000.pru is available
    [ 20.258109] remoteproc remoteproc4: 54478000.pru is available

    Then we are manually loading the firmware, here is just an example a firmware

    root@am437x-evm:~# cat /sys/class/remoteproc/remoteproc1/name
    54434000.pru
    root@am437x-evm:~# ls /lib/firmware/ti-pruss/
    am437x-pru0-prueth-fw.elf am437x-pru0-pruprp-fw.elf am437x-pru1-pruhsr-fw.elf
    am437x-pru0-pruhsr-fw.elf am437x-pru1-prueth-fw.elf am437x-pru1-pruprp-fw.elf
    root@am437x-evm:~#
    root@am437x-evm:~# echo 'ti-pruss/am437x-pru0-prueth-fw.elf' > /sys/class/remoteproc/remoteproc1/firmware
    root@am437x-evm:~# echo 'start' > /sys/class/remoteproc/remoteproc1/state
    [ 392.658369] remoteproc remoteproc1: powering up 54434000.pru
    [ 392.670777] remoteproc remoteproc1: Booting fw image ti-pruss/am437x-pru0-prueth-fw.elf, size 7544
    [ 392.680776] pru-rproc 54434000.pru: configured system_events[63-0] = 00000600,04500080
    [ 392.692085] pru-rproc 54434000.pru: configured intr_channels = 0x000000d5 host_intr = 0x00000155
    [ 392.702275] remoteproc remoteproc1: remote processor 54434000.pru is now up

    Now your points are interesting:

    "If using the RPMsg_Echo_Interrupt firmware images, the loading/booting process will first create the virtio device (and lets udev load virtio_rpmsg_bus), and the published rpmsg devices from the PRU firmware which then causes the udev to load the pru_rpmsg driver and create the /dev/rpmsg_pruX devices."

    root@am437x-evm:~# ls /lib/modules/5.4.58-gd1b11ffdf0/kernel/drivers/rpmsg
    rpmsg_char.ko rpmsg_pru.ko virtio_rpmsg_bus.ko

    Note we are doing this manually now ...

    Are you saying to first load virtio_rpmsg_bus.ko? What dmesg should we expect here on success?

    Then load the rpmsg_pru.ko?

    If we do that, there is nothing added in dmesg, see here

    root@am437x-evm:~# insmod /lib/modules/5.4.58-gd1b11ffdf0/kernel/drivers/rpmsg/virtio_rpmsg_bus.ko
    root@am437x-evm:~# dmesg |tail
    [ 24.872340] cpsw 4a100000.ethernet: initializing cpsw version 1.15 (0)
    [ 24.984613] Micrel KSZ9031 Gigabit PHY 4a101000.mdio:04: attached PHY driver [Micrel KSZ9031 Gigabit PHY] (mii_bus
    :phy_addr=4a101000.mdio:04, irq=POLL)
    [ 29.209939] cpsw 4a100000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
    [ 29.217819] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
    [ 31.848547] vmmcwl_fixed: disabling
    [ 392.658369] remoteproc remoteproc1: powering up 54434000.pru
    [ 392.670777] remoteproc remoteproc1: Booting fw image ti-pruss/am437x-pru0-prueth-fw.elf, size 7544
    [ 392.680776] pru-rproc 54434000.pru: configured system_events[63-0] = 00000600,04500080
    [ 392.692085] pru-rproc 54434000.pru: configured intr_channels = 0x000000d5 host_intr = 0x00000155
    [ 392.702275] remoteproc remoteproc1: remote processor 54434000.pru is now up
    root@am437x-evm:~#
    root@am437x-evm:~# insmod /lib/modules/5.4.58-gd1b11ffdf0/kernel/drivers/rpmsg/rpmsg_pru.ko
    root@am437x-evm:~# dmesg |tail
    [ 24.872340] cpsw 4a100000.ethernet: initializing cpsw version 1.15 (0)
    [ 24.984613] Micrel KSZ9031 Gigabit PHY 4a101000.mdio:04: attached PHY driver [Micrel KSZ9031 Gigabit PHY] (mii_bus
    :phy_addr=4a101000.mdio:04, irq=POLL)
    [ 29.209939] cpsw 4a100000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
    [ 29.217819] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
    [ 31.848547] vmmcwl_fixed: disabling
    [ 392.658369] remoteproc remoteproc1: powering up 54434000.pru
    [ 392.670777] remoteproc remoteproc1: Booting fw image ti-pruss/am437x-pru0-prueth-fw.elf, size 7544
    [ 392.680776] pru-rproc 54434000.pru: configured system_events[63-0] = 00000600,04500080
    [ 392.692085] pru-rproc 54434000.pru: configured intr_channels = 0x000000d5 host_intr = 0x00000155
    [ 392.702275] remoteproc remoteproc1: remote processor 54434000.pru is now up

    Is this the right process? What could be missing? We are trying to get life out of those kernel modules.

    Regards,

    --Gunter

  • 0 in reply to Gunter Schmer
    TI__Guru** 111605 points

    Hi Gunther,

    The PRU Ethernet firmwares are specifically for PRU Ethernet usecases, so you can't use them to verify rpmsg-pru functionality. Do whatever you were doing without changing the default firmware. And everything should work.

    Here is the log from my run on a AM437x IDK.

    root@am437x-evm:~# uname -a
    Linux am437x-evm 5.4.40-g66cf445b76 #1 PREEMPT Wed Jun 3 19:42:25 UTC 2020 armv7l GNU/Linux
    root@am437x-evm:~# dmesg | grep remoteproc
    [ 12.514980] remoteproc remoteproc0: wkup_m3 is available
    [ 14.626303] remoteproc remoteproc0: powering up wkup_m3
    [ 14.815325] remoteproc remoteproc0: Booting fw image am335x-pm-firmware.elf, size 243232
    [ 14.996568] remoteproc remoteproc0: remote processor wkup_m3 is now up
    [ 24.473416] remoteproc remoteproc1: 54434000.pru is available
    [ 24.852820] remoteproc remoteproc2: 54438000.pru is available
    [ 25.222266] remoteproc remoteproc3: 54474000.pru is available
    [ 25.542213] remoteproc remoteproc4: 54478000.pru is available
    root@am437x-evm:~#
    root@am437x-evm:~# cat /sys/class/remoteproc/remoteproc*/name
    wkup_m3
    54434000.pru
    54438000.pru
    54474000.pru
    54478000.pru
    root@am437x-evm:~# lsmod | grep pru
    prueth 40960 0
    pru_rproc 24576 1 prueth
    irq_pruss_intc 16384 1 pru_rproc
    pruss 16384 2 pru_rproc,prueth
    root@am437x-evm:~# lsmod | grep rpmsg
    root@am437x-evm:~#
    root@am437x-evm:~# cat /sys/class/remoteproc/remoteproc*/state
    running
    offline
    offline
    offline
    offline
    root@am437x-evm:~# cat /sys/class/remoteproc/remoteproc*/firmware
    am335x-pm-firmware.elf
    am437x-pru1_0-fw
    am437x-pru1_1-fw
    am437x-pru0_0-fw
    am437x-pru0_1-fw
    root@am437x-evm:~#
    root@am437x-evm:~# ls -l /lib/firmware/
    -rw-r--r-- 1 1000 1000 2046 May 31 2020 LICENCE.iwlwifi_firmware
    -rw-r--r-- 1 1000 1000 73 May 31 03:48 am335x-bone-scale-data.bin
    -rw-r--r-- 1 1000 1000 17 May 31 03:48 am335x-evm-scale-data.bin
    -rw-r--r-- 1 1000 1000 243232 May 31 03:48 am335x-pm-firmware.elf
    lrwxrwxrwx 1 1000 1000 49 Jun 4 2020 am437x-pru0_0-fw -> /lib/firmware/pru/PRU_RPMsg_Echo_Interrupt0_0.out
    lrwxrwxrwx 1 1000 1000 49 Jun 4 2020 am437x-pru0_1-fw -> /lib/firmware/pru/PRU_RPMsg_Echo_Interrupt0_1.out
    lrwxrwxrwx 1 1000 1000 49 Jun 4 2020 am437x-pru1_0-fw -> /lib/firmware/pru/PRU_RPMsg_Echo_Interrupt1_0.out
    lrwxrwxrwx 1 1000 1000 49 Jun 4 2020 am437x-pru1_1-fw -> /lib/firmware/pru/PRU_RPMsg_Echo_Interrupt1_1.out
    -rw-r--r-- 1 1000 1000 41 May 31 03:48 am43x-evm-scale-data.bin
    -rw-r--r-- 1 1000 1000 918268 May 31 2020 iwlwifi-3160-17.ucode
    -rw-r--r-- 1 1000 1000 1745176 May 31 2020 iwlwifi-8000C-13.ucode
    -rw-r--r-- 1 1000 1000 2351636 May 31 2020 iwlwifi-8000C-16.ucode
    -rw-r--r-- 1 1000 1000 2394060 May 31 2020 iwlwifi-8000C-21.ucode
    -rw-r--r-- 1 1000 1000 2120860 May 31 2020 iwlwifi-8000C-22.ucode
    -rw-r--r-- 1 1000 1000 2227284 May 31 2020 iwlwifi-8000C-27.ucode
    -rw-r--r-- 1 1000 1000 2310116 May 31 2020 iwlwifi-8000C-31.ucode
    -rw-r--r-- 1 1000 1000 2448976 May 31 2020 iwlwifi-8000C-34.ucode
    -rw-r--r-- 1 1000 1000 2401356 May 31 2020 iwlwifi-8000C-36.ucode
    -rw-r--r-- 1 1000 1000 2389968 May 31 2020 iwlwifi-8265-21.ucode
    -rw-r--r-- 1 1000 1000 1811984 May 31 2020 iwlwifi-8265-22.ucode
    -rw-r--r-- 1 1000 1000 2234528 May 31 2020 iwlwifi-8265-27.ucode
    -rw-r--r-- 1 1000 1000 2307104 May 31 2020 iwlwifi-8265-31.ucode
    -rw-r--r-- 1 1000 1000 2440780 May 31 2020 iwlwifi-8265-34.ucode
    -rw-r--r-- 1 1000 1000 2414592 May 31 2020 iwlwifi-8265-36.ucode
    drwxr-xr-x 2 1000 1000 4096 Jun 4 2020 pru
    -rw-r--r-- 1 1000 1000 3764 May 31 2020 regulatory.db
    -rw-r--r-- 1 1000 1000 1182 May 31 2020 regulatory.db.p7s
    drwxr-xr-x 2 1000 1000 4096 Jun 4 2020 ti-connectivity
    drwxr-xr-x 2 1000 1000 4096 Jun 3 2020 ti-pruss
    root@am437x-evm:~# ls -l /lib/firmware/ti-pruss/
    -rw-r--r-- 1 1000 1000 7796 Jun 3 2020 am437x-pru0-prueth-fw.elf
    -rw-r--r-- 1 1000 1000 7712 Jun 3 2020 am437x-pru1-prueth-fw.elf
    root@am437x-evm:~#
    root@am437x-evm:~# echo start > /sys/class/remoteproc/remoteproc1/state
    [ 274.230292] remoteproc remoteproc1: powering up 54434000.pru
    [ 274.252167] remoteproc remoteproc1: Booting fw image am437x-pru1_0-fw, size 83716
    [ 274.260372] pru-rproc 54434000.pru: configured system_events[63-0] = 00000000,00030000
    [ 274.268339] pru-rproc 54434000.pru: configured intr_channels = 0x00000005 host_intr = 0x00000005
    [ 274.282772] remoteproc1#vdev0buffer: registered virtio0 (type 7)
    [ 274.289350] remoteproc remoteproc1: remote processor 54434000.pru is now up
    root@am437x-evm:~# [ 274.329477] virtio_rpmsg_bus virtio0: creating channel rpmsg-pru addr 0x20
    [ 274.338355] virtio_rpmsg_bus virtio0: rpmsg host is online
    [ 274.398331] rpmsg_pru virtio0.rpmsg-pru.-1.32: new rpmsg_pru device: /dev/rpmsg_pru32

    root@am437x-evm:~# lsmod | grep rpmsg
    rpmsg_pru 16384 0
    virtio_rpmsg_bus 20480 0
    root@am437x-evm:~#
    root@am437x-evm:~# echo start > /sys/class/remoteproc/remoteproc2/state
    [ 285.730281] remoteproc remoteproc2: powering up 54438000.pru
    [ 285.752645] remoteproc remoteproc2: Booting fw image am437x-pru1_1-fw, size 83716
    [ 285.761126] pru-rproc 54438000.pru: configured system_events[63-0] = 00000000,000c0000
    [ 285.769089] pru-rproc 54438000.pru: configured intr_channels = 0x0000000a host_intr = 0x0000000a
    [ 285.784814] virtio_rpmsg_bus virtio1: creating channel rpmsg-pru addr 0x21
    [ 285.792300] rpmsg_pru virtio1.rpmsg-pru.-1.33: new rpmsg_pru device: /dev/rpmsg_pru33
    [ 285.800355] virtio_rpmsg_bus virtio1: rpmsg host is online
    [ 285.820399] remoteproc2#vdev0buffer: registered virtio1 (type 7)
    [ 285.826541] remoteproc remoteproc2: remote processor 54438000.pru is now up
    root@am437x-evm:~#
    root@am437x-evm:~# echo start > /sys/class/remoteproc/remoteproc3/state
    [ 295.960225] remoteproc remoteproc3: powering up 54474000.pru
    [ 295.981593] remoteproc remoteproc3: Booting fw image am437x-pru0_0-fw, size 82628
    [ 295.991690] pru-rproc 54474000.pru: configured system_events[63-0] = 00000000,00030000
    [ 295.999824] pru-rproc 54474000.pru: configured intr_channels = 0x00000005 host_intr = 0x00000005
    [ 296.014351] virtio_rpmsg_bus virtio2: creating channel rpmsg-pru addr 0x1e
    [ 296.021791] rpmsg_pru virtio2.rpmsg-pru.-1.30: new rpmsg_pru device: /dev/rpmsg_pru30
    [ 296.029861] virtio_rpmsg_bus virtio2: rpmsg host is online
    [ 296.050871] remoteproc3#vdev0buffer: registered virtio2 (type 7)
    [ 296.057014] remoteproc remoteproc3: remote processor 54474000.pru is now up
    root@am437x-evm:~#
    root@am437x-evm:~# echo start > /sys/class/remoteproc/remoteproc4/state
    [ 302.400243] remoteproc remoteproc4: powering up 54478000.pru
    [ 302.423022] remoteproc remoteproc4: Booting fw image am437x-pru0_1-fw, size 82628
    [ 302.431516] pru-rproc 54478000.pru: configured system_events[63-0] = 00000000,000c0000
    [ 302.439482] pru-rproc 54478000.pru: configured intr_channels = 0x0000000a host_intr = 0x0000000a
    [ 302.454408] virtio_rpmsg_bus virtio3: creating channel rpmsg-pru addr 0x1f
    [ 302.462004] rpmsg_pru virtio3.rpmsg-pru.-1.31: new rpmsg_pru device: /dev/rpmsg_pru31
    [ 302.475163] virtio_rpmsg_bus virtio3: rpmsg host is online
    [ 302.490499] remoteproc4#vdev0buffer: registered virtio3 (type 7)
    [ 302.496641] remoteproc remoteproc4: remote processor 54478000.pru is now up
    root@am437x-evm:~#
    root@am437x-evm:~# ls -l /dev/rpmsg*
    crw------- 1 root root 240, 2 May 31 04:21 /dev/rpmsg_pru30
    crw------- 1 root root 240, 3 May 31 04:21 /dev/rpmsg_pru31
    crw------- 1 root root 240, 0 May 31 04:21 /dev/rpmsg_pru32
    crw------- 1 root root 240, 1 May 31 04:21 /dev/rpmsg_pru33
    root@am437x-evm:~#
    root@am437x-evm:~# ls -l /sys/bus/rpmsg/devices
    lrwxrwxrwx 1 root root 0 May 31 04:21 virtio0.rpmsg-pru.-1.32 -> ../../../devices/platform/44000000.ocp/54426000.target-module/54400000.pruss/54434000.pru/remoteproc/remoteproc1/remoteproc1#v2
    lrwxrwxrwx 1 root root 0 May 31 04:21 virtio1.rpmsg-pru.-1.33 -> ../../../devices/platform/44000000.ocp/54426000.target-module/54400000.pruss/54438000.pru/remoteproc/remoteproc2/remoteproc2#v3
    lrwxrwxrwx 1 root root 0 May 31 04:21 virtio2.rpmsg-pru.-1.30 -> ../../../devices/platform/44000000.ocp/54426000.target-module/54440000.pruss/54474000.pru/remoteproc/remoteproc3/remoteproc3#v0
    lrwxrwxrwx 1 root root 0 May 31 04:21 virtio3.rpmsg-pru.-1.31 -> ../../../devices/platform/44000000.ocp/54426000.target-module/54440000.pruss/54478000.pru/remoteproc/remoteproc4/remoteproc4#v1

    root@am437x-evm:~# cat /sys/class/remoteproc/remoteproc*/state
    running
    running
    running
    running
    running
    root@am437x-evm:~#

  • 0 in reply to Suman Anna
    TI__Guru** 111605 points

    Hi Gunter,

    Regarding your questions, 

    "Are you saying to first load virtio_rpmsg_bus.ko? What dmesg should we expect here on success? Then load the rpmsg_pru.ko?"

    Nope, these need not be loaded manually.

    udev loads the modules automatically when the match devices were created. This is how all the platform drivers get loaded as well. DT creates devices, and the udev rules load the corresponding modules.

    [ 274.282772] remoteproc1#vdev0buffer: registered virtio0 (type 7) -> This creates the virtio0 device, udev recognizes this and loads the corresponding module virtio-rpmsg-bus.

     [ 274.329477] virtio_rpmsg_bus virtio0: creating channel rpmsg-pru addr 0x20 -> This similarly autoloads the rpmsg_pru module.

    regards

    Suman

  • 0 in reply to Suman Anna
    TI__Genius 14212 points

    Hi Suman,

    Thanks for the log above!

    I can see now the behavior and the rpmsg_pru is loading.

    root@am437x-evm:/lib/firmware# echo 'start' >/sys/class/remoteproc/remoteproc1/state
    [ 456.057048] remoteproc remoteproc1: powering up 54434000.pru
    [ 456.075807] remoteproc remoteproc1: Booting fw image am437x-pru1_0-fw, size 83340
    [ 456.084169] pru-rproc 54434000.pru: configured system_events[63-0] = 00000000,00030000
    [ 456.095779] pru-rproc 54434000.pru: configured intr_channels = 0x00000005 host_intr = 0x00000005
    [ 456.110108] remoteproc1#vdev0buffer: registered virtio0 (type 7)
    [ 456.123798] remoteproc remoteproc1: remote processor 54434000.pru is now up
    root@am437x-evm:/lib/firmware# [ 456.138851] virtio_rpmsg_bus virtio0: creating channel rpmsg-pru addr 0x20
    [ 456.147772] virtio_rpmsg_bus virtio0: rpmsg host is online
    [ 456.193532] GHS--- entering rpmsg_pru_probe ...
    [ 456.198951] GHS--- new rpmsg_pru device: /dev/rpmsg_pru32
    [ 456.198967] rpmsg_pru virtio0.rpmsg-pru.-1.32: new rpmsg_pru device: /dev/rpmsg_pru32

    (the two GHS--- are my own printk for testing, so you can disregard)ls

    root@am437x-evm:/lib/firmware# ls /dev/rpmsg_pru32
    /dev/rpmsg_pru32

    We will check this with the customer and then can probably close the issue.

    Regards,

    --Gunter

  • 0 in reply to Gunter Schmer
    TI__Guru** 100980 points

    Edited Sept 25 2020:

    For future readers, the PRU_RPMsg_Echo_Interrupt firmwares that should be used when testing on Linux 5.4 are attached. TI's first Linux SDK release of Linux 5.4 for AM437x will ship with PRU Software Support Package (PSSP) v5.7. The attached firmwares were built with PSSP v5.6. They will still work just fine with Linux 5.4.

    These firmwares can be built from the PRU Software Support Package (PSSP) under examples/am437x. The PSSP can be found in your Linux SDK under example-applications/pru-icss-x.x.x or at the PSSP git repo.

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/PRU_5F00_RPMsg_5F00_Echo_5F00_Interrupt0_5F00_0.out

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/PRU_5F00_RPMsg_5F00_Echo_5F00_Interrupt0_5F00_1.out

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/PRU_5F00_RPMsg_5F00_Echo_5F00_Interrupt1_5F00_0.out

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/PRU_5F00_RPMsg_5F00_Echo_5F00_Interrupt1_5F00_1.out

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    TI__Guru** 100980 points

    For future readers: the RPMsg driver was not working because the resource table for the PRU firmware that was generated to work with Linux 4.4 needed to get updated to work properly with Linux 5.4. At the time of this post, PSSP v5.7 is the version with the correct resource table templates to work with Linux 5.4.

    The discussion is continued in post Linux 5.4 How to Auto-Load PRU Firmware.

    Regards,

    Nick