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.

AM5728: PRU_0_ICSS2, PRU reload fails.

Part Number: AM5728

Hello,

I'm following GOOSE application note for implementing goose protocol ( https://www.ti.com/lit/ug/tidubo1/tidubo1.pdf ). Unfortunately since it's using outdated SDK, we have to upgrade it. Currently we're stuck with PRU reloading. 

PRU firmware that boots with the AM5728 works perfectly fine for us to communicate to Linux cores. Since we want to use IPU to control the network traffic, we have to rewrite the PRU memory (according to PRU tutorials). Only the last ethernet port is working, others are (due to hardware rework needed) unavailable.

//PRUICSS_pruDisable(pru2_0IcssHandle, ICSS_EMAC_PORT_1-1);
PRUICSS_pruDisable(pru2_0IcssHandle, ICSS_EMAC_PORT_2-1);

if (pgVersion >= 2) {
    //ret1 = PRUICSS_pruWriteMemory(pru2_0IcssHandle,
    //                              PRU_ICSS_IRAM(0),
    //                              0,
    //                              (uint32_t *)PRU0_FIRMWARE_NAME,
    //                              sizeof(PRU0_FIRMWARE_NAME));
    ret2 = PRUICSS_pruWriteMemory(pru2_0IcssHandle,
                                  PRU_ICSS_IRAM(1),
                                  0,
                                  (uint32_t *)PRU1_FIRMWARE_NAME,
                                  sizeof(PRU1_FIRMWARE_NAME));
    if ((ret1 != 0) && (ret2 != 0)) {
        firmwareLoad_done = TRUE;
    }
}

if( firmwareLoad_done)
{
    //PRUICSS_pruEnable(pru2_0IcssHandle, ICSS_EMAC_PORT_1-1);
    PRUICSS_pruEnable(pru2_0IcssHandle, ICSS_EMAC_PORT_2-1);
}

while (!(((ICSS_EmacObject*)emachandle->object)->linkStatus[0] |
         ((ICSS_EmacObject*)emachandle1->object)->linkStatus[0]));

the code breaks on PRUICSS_pruWriteMemory(). If we don't write anything to PRU memory, and just disable, then enable it, everything works as before (I.E. we can communicate with Linux, but IPU is still unresponsive). I checked the hex that is being written in PRU memory, and it is indeed correctly written from an array to PRU memory starting with address 0x0.

When IPU writes to PRU memory, Linux issues kernel panic and xmit timeout:

[ 6199.035368] ------------[ cut here ]------------
[ 6199.035406] WARNING: CPU: 0 PID: 0 at /mnt/sdb1/zlucic/opt/PHYTEC_BSPs/yocto_ti/build/arago-tmp-external-linaro-toolchain/work-shared/am572x-pcm-057-41300111i/kernel-source/net/sched/sch_generic.c:316 dev_watchdog+0x258/0x25c
[ 6199.035416] NETDEV WATCHDOG: eth3 (prueth): transmit queue 0 timed out
[ 6199.035423] Modules linked in: rpmsg_proto cmemk(O) bc_example(O) dwc3 ecb cbc sha512_generic sha512_arm xfrm_user xfrm4_tunnel prueth pru_rproc pruss pruss_intc ipcomp xfrm_ipcomp sha256_generic esp4 hmac ah4 md5 debugss_kmodule(O) sha1_generic sha1_arm_neon af_key pvrsrvkm(O) sha1_arm xfrm_algo omap_aes_driver pruss_soc_bus omap_sham omap_des omap_rng des_generic rng_core crypto_engine dwc3_omap extcon_palmas extcon_core omap_remoteproc virtio_rpmsg_bus rpmsg_core remoteproc virtio virtio_ring sch_fq_codel uio_module_drv(O) uio gdbserverproxy(O) cryptodev(O) [last unloaded: cmemk]
[ 6199.035598] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W O 4.9.41-g61a65e1-BSP-Yocto-TISDK-AM57xx-PD18.2.0 #95
[ 6199.035603] Hardware name: Generic DRA74X (Flattened Device Tree)
[ 6199.035607] Backtrace:
[ 6199.035629] [<c020b300>] (dump_backtrace) from [<c020b5bc>] (show_stack+0x18/0x1c)
[ 6199.035637] r7:00000009 r6:60000113 r5:00000000 r4:c102f6d0
[ 6199.035649] [<c020b5a4>] (show_stack) from [<c04c03c8>] (dump_stack+0x8c/0xa0)
[ 6199.035663] [<c04c033c>] (dump_stack) from [<c022ca20>] (__warn+0xec/0x104)
[ 6199.035669] r7:00000009 r6:c0c168e4 r5:00000000 r4:c1001d40
[ 6199.035680] [<c022c934>] (__warn) from [<c022ca78>] (warn_slowpath_fmt+0x40/0x48)
[ 6199.035688] r9:ffffffff r8:c1002d00 r7:eddeda94 r6:ed9ddd00 r5:edded800 r4:c0c168a8
[ 6199.035699] [<c022ca3c>] (warn_slowpath_fmt) from [<c073c6a4>] (dev_watchdog+0x258/0x25c)
[ 6199.035704] r3:edded800 r2:c0c168a8
[ 6199.035708] r4:00000000
[ 6199.035720] [<c073c44c>] (dev_watchdog) from [<c028dab4>] (call_timer_fn.constprop.3+0x30/0xa0)
[ 6199.035728] r10:40000001 r9:edded800 r8:c073c44c r7:00000000 r6:c073c44c r5:00000101
[ 6199.035732] r4:ffffe000
[ 6199.035741] [<c028da84>] (call_timer_fn.constprop.3) from [<c028dbc4>] (expire_timers+0xa0/0xac)
[ 6199.035747] r6:00000200 r5:c1001df4 r4:eed52400
[ 6199.035756] [<c028db24>] (expire_timers) from [<c028dc68>] (run_timer_softirq+0x98/0x184)
[ 6199.035763] r9:00000001 r8:c1002080 r7:eed52400 r6:c1002d00 r5:c1001df0 r4:00000002
[ 6199.035773] [<c028dbd0>] (run_timer_softirq) from [<c0231304>] (__do_softirq+0xf8/0x234)
[ 6199.035779] r7:00000101 r6:c1000000 r5:c1002084 r4:00000000
[ 6199.035786] [<c023120c>] (__do_softirq) from [<c0231780>] (irq_exit+0xe0/0x148)
[ 6199.035793] r10:c0e54e38 r9:c1000000 r8:ee808000 r7:00000000 r6:00000000 r5:00000013
[ 6199.035797] r4:c0e54d40
[ 6199.035808] [<c02316a0>] (irq_exit) from [<c027b6cc>] (__handle_domain_irq+0x68/0xbc)
[ 6199.035818] [<c027b664>] (__handle_domain_irq) from [<c0201500>] (gic_handle_irq+0x40/0x7c)
[ 6199.035825] r9:c1000000 r8:fa213000 r7:fa212000 r6:c1001ef0 r5:fa21200c r4:c1003418
[ 6199.035833] [<c02014c0>] (gic_handle_irq) from [<c020c0f8>] (__irq_svc+0x58/0x8c)
[ 6199.035839] Exception stack(0xc1001ef0 to 0xc1001f38)
[ 6199.035845] 1ee0: 00000001 00000000 fe600000 00000000
[ 6199.035852] 1f00: c1000000 c1003034 00000001 c100309c 00000000 00000000 c0e54e38 c1001f4c
[ 6199.035857] 1f20: c1001f2c c1001f40 c021f760 c0208774 60000013 ffffffff
[ 6199.035864] r9:c1000000 r8:00000000 r7:c1001f24 r6:ffffffff r5:60000013 r4:c0208774
[ 6199.035876] [<c020874c>] (arch_cpu_idle) from [<c0858c6c>] (default_idle_call+0x28/0x34)
[ 6199.035887] [<c0858c44>] (default_idle_call) from [<c026cc7c>] (cpu_startup_entry+0x120/0x1f4)
[ 6199.035898] [<c026cb5c>] (cpu_startup_entry) from [<c0853f4c>] (rest_init+0x8c/0x90)
[ 6199.035902] r7:ffffffff
[ 6199.035914] [<c0853ec0>] (rest_init) from [<c0e00d74>] (start_kernel+0x3d4/0x3e0)
[ 6199.035919] r5:00000000 r4:c1053040
[ 6199.035927] [<c0e009a0>] (start_kernel) from [<80008090>] (0x80008090)
[ 6199.035935] ---[ end trace cf1afe63f894386c ]---

[ 6199.035948] prueth pruss2_eth eth3: xmit timeout

If we try to boot PRU with different firmware ( pdk_am57xx_1_0_12\packages\ti\drv\icss_emac\firmware\icss_dualemac\bin\am572x\ipu1_0\REV2 ), dmesg just logs this error:

[ 18.053009] remoteproc remoteproc3: powering up 4b2b8000.pru1
[ 18.056719] remoteproc remoteproc3: No loadable segments
[ 18.062074] prueth pruss2_eth eth3: failed to boot PRU1: -22

Currently I don't even know in what direction to look. I tried with bin from newer pdk 1.0.17), tried the NDK example and it breaks at PRU write memory as well, tried most of solutions I found on these forums that are somewhat related to this problematic

  • I hexdumped am57xx-pru0-prueth-fw.elf and am57xx-pru1-prueth-fw.elf, and tried to write that hexdumped array in PRU memory. after enabling PRU cores, everything works as it did before (can only communicate with Linux via SSH) with new error shown with dmesg:

    [ 3876.015128] omap_l3_noc 44000000.ocp: L3 application error: target 5 mod:1 (unclearable)
    [ 3876.023308] omap_l3_noc 44000000.ocp: L3 debug error: target 5 mod:1 (unclearable)

    it still fails the link status check and gets stuck in infinite loop:

    while (!(((ICSS_EmacObject*)emachandle->object)->linkStatus[0] |
             ((ICSS_EmacObject*)emachandle1->object)->linkStatus[0]));