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.

Compiler/AM6548: Not able to load the firmware in R5 Controller

Part Number: AM6548

Tool/software: TI C/C++ Compiler

I am trying to load the modules for remoteproc, due to this R5 firmware is not loading. 

The same code was running on Silicon Rev. 1.0 but not on Silicon Rev 2.0 .

SDK Version : 7.0.1.6 

Error:

[   41.653628] remoteproc remoteproc18: powering up 41000000.r5f
[   41.653795] remoteproc remoteproc19: powering up 41400000.r5f
[   41.659432] remoteproc remoteproc18: Booting fw image am65x-mcu-r5f0_0-fw, size 3836968
[   41.660689] platform 41000000.r5f: mbox_request_channel failed: -517
[   41.665260] remoteproc remoteproc19: Booting fw image am65x-mcu-r5f0_1-fw, size 3753744
[   41.666561] platform 41400000.r5f: mbox_request_channel failed: -517
[   41.673325] remoteproc remoteproc18: can't start rproc 41000000.r5f: -16
[   41.679723] remoteproc remoteproc19: can't start rproc 41400000.r5f: -16

  • We are using our custom hardware with silicon V 2 . we tested the code on IDK Board with silicon V 1.

  • We tried To run the Sample code provided by TI SDK 7.0.1.6 on Silicon V2. We were able to run the PRU and RTU Code which did not have mbox but with the R5F sample code which contains mbox the Board goes to dead state. R5 code contains mbox which is failing. Below is the log for R5 default firmware loading.

    [   10.858235] remoteproc remoteproc0: powering up 41000000.r5f
    [   10.864091] remoteproc remoteproc0: Booting fw image am65x-mcu-r5f0_0-fw, size 83276
    [   10.865582] platform 41000000.r5f: mbox_request_channel failed: -517
    [   10.880740] remoteproc remoteproc0: can't start rproc 41000000.r5f: -16

  • Hi Sarfaraz Shaik,

    You mentioned this is on your custom platform, please provide more details:

    1. have there been any changes done for interrupt mapping, memory map etc?

    2. Did you try loading the r5f images via ccs and check whether they are booting?

    3. When you say TI provided sample, did you run the pre built binary? or rebuilt in your SW?

    Thanks & Regards,

    Sunita.

  • No We have not changed any major mapping in the DTB. Only changes is for the UART and ethernet PIN MUX . we are using ICSSG1 and ICSSG2 Ethernets .

    We did not try loading image using ccs. We are sing the default binaries from TI SDK 7 for the testing. Even on the default sdk binary it crashes. 

    Is the default TI binary tested on SIlicon V2.

  •    This issue is still open by mistake it was marked resolved.

  • Sarfaraz,

    I got some inputs from the IPC team:

    -517 is probe deferral, so I suspect the OMAP Mailbox driver is not installed or probed. A secondary probe deferral happens because ti-sci is not installed yet (Mailboxes used NavSS interrupts, which are in turn managed through ti-sci).

    Make sure ls -l /sys/bus/platform/drivers/omap-mailbox is present (when installed, this will be there) and does show the probed Mailbox clusters.

    Also ls -l /sys/class/mbox should show all the registered mailboxes that a consumer (remoteproc typically) can use.

  • Brad,

    omap-mailbox and ti-sci are marked as [y] in the default config file. We have not changes the default configuration file.

    ls -l /sys/class/mbox/ folder is empty. Below is the list of all modules loaded in the system. Don't know why but on our board we are getting R5F0 and R5F1 as remoteproc 18 and 19 respectively. 

    ~ # lsmod
    Module                  Size  Used by    Not tainted
    xfrm_user             262144  0
    xfrm4_tunnel          262144  0
    tunnel4               262144  1 xfrm4_tunnel
    ipcomp                327680  0
    xfrm_ipcomp           262144  1 ipcomp
    esp4                  327680  0
    xfrm_algo             262144  3 xfrm_user,xfrm_ipcomp,esp4
    rng_core              262144  0
    pci_endpoint_test     262144  0
    ti_k3_r5_remoteproc   327680  0
    pru_rproc             262144  0
    pruss                 327680  1 pru_rproc
    nf_log_ipv4           262144  0
    nf_log_common         262144  1 nf_log_ipv4
    xt_LOG                262144  0
    xt_length             262144  0
    ipt_REJECT            262144  0
    nf_reject_ipv4        262144  1 ipt_REJECT
    xt_conntrack          262144  0
    xt_addrtype           262144  0
    xt_mark               262144  0
    iptable_filter        262144  0
    xt_nat                262144  0
    xt_tcpudp             262144  0
    iptable_nat           262144  0
    nf_nat                327680  2 xt_nat,iptable_nat
    nf_conntrack          327680  3 xt_conntrack,xt_nat,nf_nat
    nf_defrag_ipv4        262144  1 nf_conntrack
    libcrc32c             262144  2 nf_nat,nf_conntrack
    ip_tables             327680  2 iptable_filter,iptable_nat
    x_tables              262144 10 xt_LOG,xt_length,ipt_REJECT,xt_conntrack,xt_addrtype,xt_mark,iptable_filter,xt_nat,xt_tcpudp,ip_tables
    rpmsg_kdrv_switch     262144  0
    rpmsg_pru             262144  0
    virtio_rpmsg_bus      327680  0
    rpmsg_char            262144  0
    irq_pruss_intc        262144  1 pru_rproc
    ipv6                  720896 22 [permanent]
    nf_defrag_ipv6        327680  2 nf_conntrack,ipv6
    g_ether               262144  0
    usb_f_rndis           327680  1 g_ether
    u_ether               327680  2 g_ether,usb_f_rndis
    libcomposite          327680  2 g_ether,usb_f_rndis
    udc_core              262144  3 usb_f_rndis,u_ether,libcomposite
    ftdi_sio              262144  0
    usbserial             327680  1 ftdi_sio
    usbcore               458752  2 ftdi_sio,usbserial
    usb_common            262144  3 libcomposite,udc_core,usbcore
    

  • The issue was with the mail box clusters in dts file . We enabled them and they cores were running well with IPC .

    &mailbox0_cluster0 {

           status = "okay";

            interrupts = <436>;

     &mailbox0_cluster1 {

            status = "okay";

            interrupts = <432>;

    Status should be "okay" for both the mailbox clusters in dts to use mbox IPC communication mechanism.